Not just money, but certain design choices too, like lexicons.
Lexicons I think are pretty critical for a decentralised protocol to not get all messy. Ironically ATProto, currently the far more centralised protocol, has them well defined, and Nostr, currently the far more decentralised one, does not.
Nostr has Kinds and NIPS and all, which are collaborative and good, but are definitely a little more loose around the waist in comparison.
Yeah, that happens when there is no main authority who folks look to as having the final word. 😂
Rules, not rulers is harder to build, but also harder to topple.
I'd argue ATProto lexicons are more decentralised than Nostr NIPS. If you zoom out it's a different story—but just zooming in to that one specific aspect then that's how it seems.
Nostr can do truly decentralized, but it's specialty is arguably distributed. So, overlapping pools of centralization, that npubs can travel through, or hop over.
Yeah I think that's a pretty good summary. Wouldn't want to attempt a diagram though.
We're diagramming it. 😁 Or, rather, visualizing it and making it navigable.
Thank you for sharing this info. It really helps me understand Nostr from the dev's perspective and be more patient with any tech issues considering the challenging decentralized objective.
It seems like it's worth the tradeoff?
From reading that article, Lexicons just sound like various note kinds, which are defined in the NIPS.
For instance, a kind 1 post is just a short text note and most clients can display kind 1 notes fine. They may make choices about how they render certain text within a kind 1. For instance, an image URL contained in a kind 1 is often rendered as the image itself. Same thing with video URLs. But a client could just render the URL text and make it clickable to open the media in a separate tab.
Meanwhile, there are also specific media kinds, too. Such as Kind 20 for images, kind 21 for videos, and kind 22 for short-form portrait videos.
You can find the definitions of all of these kinds and what they can, should, and must contain in the NIPs repo here:
https://github.com/nostr-protocol/nips
Most of them are pretty well defined. You will find that some clients don't always follow these definitions, though...
Sort of but Kinds here can be pretty loose. Lexicons on ATproto can get very tight. Like taking Nostr Kinds and putting them in a Hollywood spy movie where the technician looks at the monitor and says "enhance". You've got schemas, and then sub-schemas, and even sub-sub-schemas.
It would be like Nostr having a developer-defined sub-schema for embedding, say, javascript charts in Kind1 posts. So ATporoto lexicons are living things. Kinds here tend to get locked down a little early (like we just hit "save and publish"), and if you a client wants to go down certain alleyways then either it's up to the client to just go down those alleyways and see, or there would be a need for a new Kind.
It's not so much about centralisation since ATproto lexicon development is pretty decentralised (arguably more so than Nostr). It's more about the way they're perceived.
