ManiMe on Nostr: I tried to spark discussion around a “simpler” and more “decentralized” ...

I tried to spark discussion around a “simpler” and more “decentralized” solution a while back .. to solve the same problem of “kind bloat” by clients and relays.

quoting
note1e4x…9wdg

the following article is a repost from my recent issue #864 posted in the NIPs repository

Nostr is a protocol for events. Sending user generated content to a relay should be one kind of event (a kind 1 event) regardless of the structure of the content being sent. Different “types” of user generated content (EG: microblog-post, microblog-poll, encrypted-dm, blog-article, photoblog-post, calendar-event, exchange-question, exchange-answer, ect…) should not require different event kinds. Content type definitions (describing structured content with supported and required tags) should be maintained freely by implementers, not controlled by protocol. By opening up (decentralizing) the architecture for typed content, a potential source of NIP bloat will be “nipped” and the creativity of nostr designers and developers will be released to organically evolve novel solutions for real world content needs.

The protocol for clients and relays to define and communicate about typed content (including supported and required tags for each type) should be a new NIP (see below for draft). New content types may also be defined by individual NIPs, but these (both existing and proposed NIPs) should only prescribe the “minimal” structure and processing (of supported and required tags) needed for compliance. In the wild, content type implementations should be defined and updated “ad hoc” between clients and relays.

==Free the “other stuff”!==

Use Case Example

• Client “NotX” implements three content types : microblog-post, encrypted-dm, and microblog-poll.
• The first is a stock NIP implementation. The second is a NIP content type with an added location tag. The last one is a custom content type being tested by the client.
• These content types are defined locally by the client. Their kind and description provide the basis for easily identifying the client’s IRL use case.
• Each content type definition also includes a list of supported and required tags EG: The microblog-poll content type has poll-topic, poll-options, and close-date as required tags, and publish-date as a supported tag.
• These content type definitions also describe the data expected and other properties for each tag.
• Upon WSS connection (during the “handshake” phase) the client sends it’s list of supported content types to the relay for comparison to it’s “local master” list of supported types. Any discrepancies in the list of tags for a given content type are either accepted (as updates) or rejected by the relay.
• Relays dictate for themselves which content types (and which tags for each type) they will accept from a given client.
• The connected relay A has been updated to work with the location tag for encrypted-dm content type, (it’s a common NIP mod these days) and will accept kind 1 events for this type.
• Relay A rejects the novel microblog-poll content type, but logs the client request for future updates.
• The client connects to Relay B (who’s operator is working closely with the client developer) to support the novel content type. Relay B has been updated already, and will accept Kind 1 events for the microblog-poll content type.

NIP Draft : Kind 1 User Generated Content Type

A NIP proposal (PR) will be forthcoming, depending on the discussions in this issue. Here are some possible highlights of what such a NIP would specify:

User Generated Content

User generated content refers to personally authored text or media content (sent as event data) which human users wish to “publish” to relays for consumption by other human users.

User generated content does NOT include:

• events describing an action (EG: boost, like, vote, edit, or delete) that a user may take on already published content.
• event data for user profile content
• event data for reward or payment systems (EG: badges created or awarded, or zaps made to users or events).
• event data that defines or configures a “grouping” of other users or events (EG: “lists”, or “communities”).
• event data intended for consumption by an external API (EG: DVMs, ai bots, IOT, ect…)
• event data that simply “adds function” to existing event kinds (EG: event encryption or replaceability).

NIPs Prescribing User Generated Content Types

NIPs should define new user generated content types as a kind 1 event (rather than a new event kind). Each content type will have a type and description that clearly illustrates its use case or intended “style” of app. NIPs will also suggest the minimal tags (content structure) and processing rules required for implementations to be NIP compliant.

In addition NIPs may propose a new tag (and rules for processing it) that may be added to any (or a specific) content type. (For example: “gift wrap” encryption and “replaceable event” may become tags for events, rather than event kinds themselves).

Supported Content Types via Handshake

Client implementers will send a list of supported content types as part of a “handshake” document when web socket is first connected.

Format for content type list:

{...
 “content”:<array[object]>,
 ...
 }

Format for defining a supported content type :

{
“kind” : 1,
“type”:<string>,
“description”:<string>,
“tags”:<array[array]>,
“legacy_kind”:<number>
}

Format for supported tags in a content type definition:

[<tag_id>,<default_value>,<data_type>,<is_required>]

Kind 1 Content Typed Events

All user generated content should be a kind 1 “content typed” event. The content type will be communicated via the c tag (as opposed to a new event kind number). Structured content will be conveyed using standard tags in the event object, as defined in the handshake document for this content type.

{
  "id": <event_id>,
  "pubkey": <user_pubkey>,
  "created_at": <event_timestamp>,
  "kind": 1,
  "tags": [
    [“c”, <content_type>],
    [<tag>,<tag_value>],
    ...
  ],
  "content": <note_content>,
  "sig": <event_sig>
}

Update Path for Implementers

For backwards compatibility with legacy clients and relays, implementers should deprecate but not remove legacy “event kind content” event handling. As the implementation code is updated to support “content typed events”, the “supported types” list in the “handshake” document will reference the legacy_kind kind number that the legacy client or relay will be expecting. Using the info, implementors can send the event in the legacy “event kind content” format as needed. (If nostr supports log output via event tags, this can be used as well to inform of possible updates.)

Related NIPs & Issues

These NIPs will Need Updating

(to redefine prescribed event kinds as Kind 1 content types, freeing clients and relays to update them as needed “in the wild” )

NIP-4 : Encrypted Direct Message NIP-18 : Reposts NIP-23 : Long form Content NIP-28 : Kind-42 : Channel Message NIP-52 : calendar events NIP-72 : community post NIP-99 : classified listing

These NIPs play well with content typed events

(by defining tags for events rather than new event kinds.)

NIP-14 : Subject Tags in Text Events NIP-32 : Labeling NIP-36 : Sensitive Content NIP-48 : Proxy Tags NIP-72 : community post

These PRs will need tweaking :

#848 using multiple independent kinds for community scoped events 814 Internet on things on nostr (nip 107) #817 IOT sensors and intent #811 decentralized web hosting #787 draft of nip-34 : decentralized wikis

These Issues will be closer to resolving:

#162 Decentralizing the NIPs registry. #394 add content-type tag for encrypted direct messages. #520 Different nostr: schemes for different types of apps/nips #583 nip-23 used for private journals

Conclusion

This architecture of “customizable content types” is not new. The best CMSs for over a decade have relied on this to allow website administrators to create new types of content (“pages”) with custom elements (“fields”) to suit their business needs. Indeed, some go even further and abstract other “entities” (not limited to user generated content) to use this modular “field-able” architecture.

Nostr can take this modular content architecture to the next level, by embedding it into a protocol for ANY developer, rather than a single code base for some. By defining a “means” of communicating content between clients and relays, rather than the structure of what “should be” communicated, nostr NIPs can become the open and long lasting protocol needed for decentralized social media.