Oddbean new post about login | logout First of all, Pkarr was shared with Nostr folks especially Fiatjaf from day one, the reaction was always either Nostr doesn't need it or we can't change the Identity now it is too late. Secondly if you are willing to make a breaking change like Pkarr as the root identity, then might as well reconsider other unfortunate parts of Nostr that are bundled with the discovery layer for no reason, most importantly why would we use websockets and Nostr events as base API instead of HTTP verbs, headers, and semantics? just because Nostr made that bad decision? Why not build a datastore like WebDav and then advertise that event (PUT/DELETE) on Nostr relays? Well, pubky core only engages with Pkarr and data stores. And it doesn't tackle discovery so Nostr can be that for Pubky or not. But note that Pubky didn't take away anything from Nostr, anymore than Blossom takes away from Nostr, if anything wr just decided to use the tried and tested tech of web servers.
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.
> 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.
nostr:nprofile1qqsfxrxw7y3h9hf0zczhelz57rdajse4mz63kn38xu3kkqx2kuv0ekgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmzd96xxmmfdejhytnnda3kjctvqyvhwumn8ghj7erpwd5zumt0vd4kjmn809hh2tnrdaksrej4w0 Any plans for a browser extension? It would be perfect if, e.g. Brave browser, embed this functionality into the browser itself. Brave is pioneering several initiatives like that (decentralized web).
Not from me personally... the problem is we have limited resources and we try to focus on tools that can land in as many people's hand as smoothly as possible. A browser extension is high risk low reward, because people who install extensions are very few. I would rather build a web page that acts as a browser in a browser. And then lobby Brave and Chromium to support Pkarr natively one day.
Oh sorry, didn't see this yet: nostr:nevent1qvzqqqqqqypzpycvemcjxuka9utq2l8u2ncdhk2rxhvt2x6wyumjx6cqe2m33lxeqqst4qrf03vjaj04f0zws8dd73axn3mx225h0wvcuahuhd2q54a8mps9fr0yw