The user experience must be at the heart of all Nostr customer thinking.
Discussion
It’s really hard because you’re constantly connecting to a bunch of relays and trying to sort the data. All of the burden is on the client.
I welcome any designer to try it for themselves. Go to lovable.dev, feed it NDK, and try to get a basic feed client going. Try to get the latest notes and all their reactions to display correctly and make sure you don’t run out while scrolling - then come back and tell me how easy it was 😂
Client server architecture is way easier to work with. You have one user making an auth request to one server and all their data is retrieved that way.
It does lend some credence to the ATProto team's take. Basically their take at the start was:
- Network-wide cacheing is basically inevitable to preserve the user experience at scale
- Scaled cacheing architecture is expensive and hard
- If the protocol doesn't handle it, clients will handle it themselves
- Because it's expensive and hard, only a one ore two clients will truly go all in on it, other clients will see this and just give up
- Users will flock to the one or two clients
- Other clients wither and fade
So they decided to make the network-wide cache basically a commodity that *all* clients have access to and thus remove the incentive for each client to invest in building the same thing as everyone else (and to a lesser quality level). I think there is some logic there, it does remove duplication of expense and might help ensure a more level UX playing field among clients (though need to wait for first batch of ATProto clients to mature to see if this bears out).
I think Nostr's general architecture is still the way forward but it's worth digesting these takes.
Some logic … but still super centralizing
What they’re going for seems to be poly-centric as opposed to decentralised. So instead of switching from Relay A to Relay B you switch from Alphabet 1 to Alphabet 2 (but both alphabets are still A-Z).