-
@ Vitor Pamplona
2025-03-01 17:44:13
Vertically integrated specifications win.
Instead of thinking of NIPs as “horizontally integrated” lego pieces where given kinds are specified based on their functionality with the goal of being usable in as many types of clients as possible, we should create NIPs that model a given type of application with all the requirements of that application listed in the NIP itself.
Take our Blog kind for instance. It’s essentially an extended version of a Kind 1 (twitter) post but with support for Markdown. In theory, we could have just re-used kind 1s. But we didn’t. We created a whole new spec just for it. Now picture a new client specifically designed to write and display Scientific papers. It’s essentially a “Blog” king, but its Markdown support requires the addition of Latex Equations. Should we modify the Blog post kind and force all Blogging platforms to deal with and maintain the code complexity of rendering latex equations? Or should we just add a new NIP just for scientific publications? If we want to keep Nostr simple, new NIP it is.
Now picture a dev that wants to offer a Blog platform for scientists. It’s not a Scientific Paper platform, but it is also not a regular Blog post client. Should we create a new NIP with a new kind? I say yes. Because with separate NIPs each blogging client and each scientific paper client can decide to support the other kind variations in their own timeline, if their brand and user experience allows them to support it at all.
That breaks the way we Nostr:
1. User expectations that all blogs/papers are the same stuff and must be seen in every client is wrong. Some users even say that by not supporting certain kinds, devs are failing interoperability and thus "destroying Nostr". Some users want to see the exact same "feed" in all clients. This is not a good expectation to have. Blog post apps should not be expected to render scientific papers and vice versa, even though they are functionally very close to each other.
2. The NIP repo’s rule that there should be “no more than one way of doing the same thing”, which is a good rule that seeks to increate interoperability, is wrong. Sometimes applications need a different way of doing the same thing. Like the scientific paper need, it’s fundamental to their own existence but it is just another way of doing the same thing from a technical perspective.
While I understand that most devs like specs designed for “horizontal integration” because they simplify their work (write once, run everywhere), it’s become more and more evident that Nostr’s simplicity can only be sustained with vertically-integrated specifications, and devs that support multiple similar kinds at the same time need to duplicate their work to support the required variations of each NIP.
This will generate many more kind numbers than initially expected. And that's is just fine.