Care to explain what you mean by “fragile”? It is cryptographically sound.
I agree that the delivery protocol could be more efficient, but use of JSON is a tradeoff that provides good extensibility and easier parsing (many well seasoned libraries exist in almost every language).
Not a cryptography / data format thing. Although CBOR is just as widely supported as JSON and that would have been a better choice there, but that's not really the issue, but the whole approach to identity.
Identities are global and shared across devices. Naturally, if your keys are lost/compromised your identity is lost/compromised.
So the solution they have to this is that your real root identity delegates signing to other identities (generated local to a device) by publishing a note indicating a list of keys allowed to sign on its behalf, and presumably you keep your root identity on a trusted device (like maybe a crypto hardware wallet or a threshold multisig).
But this just reduces the problem and worsens the UX. Your identity still gets lost/compromised if the root is.
There's also an issue with how identity updates themselves work. Since these delegates are really signing for the single root, they need to be synchronized to work properly. There was a common bug (which might still happen) where if you set up your identity on a new device, the app might broadcast an identity update with an incomplete view of your identity and it resets your follows and post history. Since your identity data might be influenced based on every note you've ever sent, and message delivery is unreliable, it's hard to properly sync and reconstruct sent note history. This comes out of a fundamental design issue, where you have multiple "writers" writing to the same state. CRDTs could have helped with this, but it's too late to do that.
This sucks! It forces users to think about key management and has catastrophic failure modes. It's really hard to re-establishment trust after key compromise because there's no notion of identity that lives longer than any one key.
Matrix is not a comparable kind of protocol, but its identity management story is a lot better. Each device has a local key that never leaves the device, and when you add a new device you cross-sign it from another device you have. Homeservers maintain a list of identities tied to a user, and other people can decide to trust the device cross-signing or manually verify each of them. This can be built in a fully decentralized context (which Nostr is not, for what it's worth).
Isn’t this just an implementation/UX issue? Ideally the root key should live somewhere secure (offline) and delegate keys live on connected devices. As the ecosystem matures I would expect this to become easier. A hardware wallet means the risk of key loss would become negligible.
I think CRDTs are great, but Nostr has always presented itself as a potentially lossy medium, purposefully. Unlike SSB and Matrix where state synchronization became a complex bottleneck, Nostr is more IRC-like. Relay owners may have to delete individual posts due to legal reasons, or identities may selectively publish different posts to different relays. The devs didn’t see this as a problem since full state synchronization is heavy and requires long term retention of data. I agree that it’s not perfect, the tradeoffs make it harder to reconstruct a full history for a given identity if you’re trying to reach way back in time. But for new content it works really well, and I think this is why they chose this approach. If you publish to a lot of relays, your message will get through to the people who want to see it, although the process is messy.
Yes, but it's a fundamentally unsolvable one due to how the ecosystem has chosen to settle on it. Even blockchain wallets are experimenting with social recovery and hijacking SSO systems because traditional key management is too hard for the average user to do correctly. Users barely want to do key management for that! Much less to look at cat pictures.
> I agree that it’s not perfect, the tradeoffs make it harder to reconstruct a full history for a given identity if you’re trying to reach way back in time.
This is just not how users expect systems like this to operate. If it was purely a low-level async messaging protocol (where retention matters less) that'd be more okay, but it's trying to be used as a general purpose social platform.
And this is why I've concluded that the Nostr ecosystem is just deeply unserious about its philosophy of design and it's fundamental architectural flaws. It's super common to see responses that have the form of "here's why it's actually good that this sucks". I thought it was clever when I first discovered it, but it seems like they're very happy to be stuck with half-broken functionality because it feels fun and janky like IRC and they're all used to the bitcoin ecosystem where they can just blame the user for messing up.
It may be that Nostr just isn’t for you. The tradeoffs involved come with costs and benefits, and that mix tends to appeal to two primary groups right now, crypto people and free speech maximalists. (And also quite a few Japanese people, for some reason.) Similarly, the Fediverse has its own limitations and tradeoffs, which appeal to a different set of groups. Both have a healthy number of users and seem to be developing well.
I think that this kind of fragmentation is becoming more common. Not everyone wants to be on a platform with the rest of humanity anymore. And not everyone shares the same design goals for protocols to replace those platforms.
The relay architecture is too limited so it encourages centralization through sticky defaults in user clients. UX noticeably improves when users have to query and publish to a smaller overall set of trackers. There's no structure to the protocol to encourage naturally spreading the load around.
This also means that it gets increasingly more expensive to run a relay as time goes on, making those parties have more sway over the network and giving the ability to selectively remove content.
So that's why I argue it's not fully decentralized, like BitTorrent. BitTorrent does have trackers, but they're only an accelerator over DHT/PEX. Peers can't manipulate content since you independently verify it. There would have to be some kind of in-protocol message exchange directly between participants, bypassing relays, when they were able to reach each other.
