Nostr Web Client

> Layered protocol (separate core from applications)

What do you mean by this? How would it work?

That is an organisational comment, as to how the protocol definition (the NIPs) are organised (or not organised). Nostr NIPs have no structure in terms of which NIPs apply to everybody (it is not just 1 anymore) at the base protocol, and what is an application riding on top of nostr. It isn't clear without reading or being around that NIP-10, NIP-18, NIP-22(?), NIP-11, NIP-09, NIP-51, NIP-59, and more... these are all kind of core facilities that applications can use. But NIPs 54 (wiki), C7 (chats) 64 (chess), 35 (torrents), etc, these are all applications that ride on top of a core.

IMHO the NIPs repo should just register application kinds so that applications don't clobber each other with their kinds, but not be defining all these applications. There could be a sister repo that aggregates lots of nostr app specs, it wouldn't have to be pushed out to separate owners.

Reply to this note

Please Login to reply.

Discussion

fiatjaf 1y ago

I see. I thought you were talking about a way to disentangle all the relay-picking quibbles from the development such that it could be all isolated in a simple library. It would be great if such a thing was possible but I can't imagine it. Every app developer today needs to keep relays in mind to some extent and I don't see how that could be different. In fact ideally users have to also.

fiatjaf 1y ago

If it's just an organizational comment then we can do that today, but I'm not really seeing what you're describing so I don't know.

My first reaction is that changing the way we organize stuff will not make it less messy, we will just move the mess around in different shapes.

What I really think is missing is a good documentation page that distills the knowledge required for writing Nostr apps. It would have to be something that doesn't follow the NIPs closely, but just lays a meaningful story on top of them and other real-world experience.