Embed Notice

@3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d The reason for NIP-26 is to retrofit Nostr into a previously centralized system. Even ActivityPub servers are centralized compared to Nostr.

This is good for Nostr because it expands the userbase. The most valuable asset of a social network is the userbase, so each expansion increases its viability due to network effects. Part of the Nostr strategy SHOULD be getting legacy platforms (with a lot of users) to adopt the protocol.

But if we store user’s private key on our server, it’s lose-lose. First of, WE don’t want that liability. A leaked private key is way worse than a leaked password because if that happens, we can’t regain control over the account. From the user’s perspective, they can’t trust a key that ever touched our server. But we WANT them to be able to migrate out. We want the best of both worlds: to give users the full freedoms of the Nostr protocol, AND all the conveniences of centralized platforms.

I think ultimately it IS possible to offer high convenience on the Nostr protocol by building fancy relays, or making clients connect to special “aggregator” servers. Also, by offering hardware wallets and giving users flexible key schemes like NIP-41. But this is part of the new world, not part of the old one, and there is no simple path to bring those large existing centralized communities to Nostr.

The problem NIP-26 solves is that it let’s us store a “private key” but limits damage from a leak. The user generates their own key and only submits a delegation string to us every ~30 days. If a breach happens, the damage is limited to ~30 days. Users can control and configure this depending on their desired level of security. Most importantly, it lets us retrofit Nostr into our system. It’s not perfectly elegant. But it’s a matter of whether you want to focus more on the new world, or try to bring the old world along with us. Personally is see great value in that.