Oddbean

Cool, well I think that's fair. Key management is a hard problem. If nostr can't solve it (somehow), then I agree, I don't think it'll succeed. Obviously I think we still have a chance to solve it without throwing away all our work so far, but I don't know enough about how PKARR works so I'll have to read up. I do think though that pubky is about as complementary to nostr as mastodon is. They can be bridged, but that's not a long-term solution, one network will have to win out (meanwhile blossom is pretty much orthogonal to both).

well imagine if you decided to put Nostr events on blossom, or better yet on S3-like object store.. that is what Pubky homeservers are, http servers with simple API (PUT,GET,DELETE + cursor pagination) that you can sign in yo with your ed25519 key once and then have a session with the homeserver as long as you can keep it, giving us plenty of room to secure that rarely used root key. the problem here is, you can't use that ed25519 key and homeserver as the root of identity and still call it Nostr. If you can still call it Nostr, then so be it we are Nostr I guess.

Right, we basically have the same thing with bunkers. "Sign in" to your nip 46 signer once, then authorize sessions with the bunker. One nice thing about this is that the signer and data storage are decoupled, which means you're not limited to the "homeserver" paradigm, giving you lots of options for special-purpose relays (inbox, outbox, DM privacy, topic-based, community relays, trending relays, etc). Twitter has tons of interesting caching mechanisms that allow for content to reach across the network quickly. Home server designs (as I understand them) don't actually work very well for that kind of thing.

This is value judgment though, we are betting that users want a relationship with ONE hosting provider that promises them data integrity, strong consistency, etc.. all what you an I expect from a data store. But, note two things here: 1. Unlike nswcbunkers, we don't give the homeserver our root keys, and we expect apps to know that we delegated to that Homeserver from Pkarr (like DNS), in Nostr prominent devs killed any attempt to have key delegation, we are not going to play nice with that. 2. Nothing preventing you from taking SOME of the data on the homeserver and cache them around as you wish with higher layers, and if that requires that the data is signed, we plan to get to that, but at least the straightforward usecase of just... you know follow a URL to the authority server is covered. 3. Nothing prevents us from having special service types including mirrors of the data, or literally Email address.. whatever you can put on DNS works. we are just making this new service type because it covers so much of what web2 does for as little complexity as possible. and the least mental load on users.

I‘m just one step into the #pkarr & #pubky rabbit hole and i‘m already very impressed by what you guys built. The whole concept of DNS over Mainline DHT … dude … this is some serious business.

> users want a relationship with ONE hosting provider That's a valid starting point. Nostr ultimately incentivizes users to have **their own** relay (+ blossom server) too. It's the most cost effective way to solve for privacy, speed, bandwidth, limiting read-access to publications, etc... Plus, in the case where relays are a keypair, it's probably the simplest way to handle key delegation, rotation, etc... too.

Yes but then the websocket API and Nostr events are nothing but deliberately giving up on the rich history of HTTP apis just because people don't think clearly and bundle data storage, finding that data storage, and global sync in the same universal API. This is just waste. We knew how to build client-server apis before nostr, and JSON over websocket is clearly inferior and limiting compared to HTTP verbs, headers and semantics.