Subnostr

For now I would leave the current event kind number specs as it is. It's more flexible that using NIPs for every possible content-type. But I can imagine there will be NIPs around specific content-types which will extend NIP-01 in the future.

Now all the content-type related stuff can be handled by all Nostr clients and map them to the related event kinds. This could be a very interesting mapping to work out (a visual presentation of kind numbers with content-types).

Reply to this note

Please Login to reply.

Discussion

ManiMe 1y ago

Thanks. While this article is rough and lacking many specifics… what it does propose is that a single NIP could be designed for clients and relays to structure their own “content types”, without needing additional NIPs and “kinds” to be explicitly defined in the “centralized” repository. It’s not perfect, or even near a complete spec, but it does aim to “increase” the flexibility and freedom for developers. (ICYMI)