Oh, didn't realize you're Carvalho himself. Nice to meet you! As I say below, I've followed your work for a long time, well before I got into the space. Now I have to re-write my note to speak in 2nd instead of 3rd person 😅

On your critiques of nostr:

> Scalability/incentive challenges that result in only a few centralized relays, lacks key-delegation and identity-based routing, inviting censorship and data loss.

I agree on key management, but the rest of it is either wrong or has to be justified a lot more. A "challenge" does not "result" in anything. And there is identity-based routing in NIP 65 and other places.

PKARR sounds great, but again, why not bring it to nostr rather than pump your own brand? I'd love to see someone solve that problem on nostr.

I also have a problem with your thesis that DHTs "ensure scalability". P2P DHTs are pretty well understood to not scale. Hub-based DHTs can scale, but that's basically nostr's topology. You even say "the network scales seamlessly, supporting millions of nodes globally". Don't we need billions? Unless you're talking about shared homeservers, but, again — that's the same topology as nostr.

You claim that pubky is "not just another app or platform; it’s a paradigm shift".  I'd argue that the paradigm shift happened as early as scuttlebutt, other protocols are just attempts to improve on their work, pubky being no exception. The attempt to claim all this stuff for your own brand is kind of sketchy.

We would have loved to have you over here on nostr for the last two yearse pushing forward web of trust, content curation, decentralized algorithms, identity-based routing, etc. These are things nostr developers have been working on for years now. They're just all still nascent because everyone has their own project to take care of. Nostr has a high level of redundant work happening compared to bluesky, pubky, etc. Which has its challenges, but I see it as a good thing.

I'm hard on pubky not because I'm a nostr-only robot, but because I closely followed your work for quite a while prior to getting into nostr development. I installed the wallet, read the slashtags docs, etc. So this isn't just a confirmation-bias opinion. I'd love to see all the effort that is going into pubky go into building on nostr. Unless you think nostr isn't salvageable? But apart from the DHT implementation, it seems to me like all pubky's good ideas could be retrofitted onto nostr. 

 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. 

 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. 

 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. 

 Pkarr was suggested to Nostr people probably a year ago or so. We have been working on our vision for the web since before Nostr existed, and we created Pubky to be what we think is the best design. So why should we retrofit it to Nostr conventions and make it worse again? Why should we be spending 2 years lobbying people to do make fundamental changes they do not want ro make? You see this all thru a lens of Nostr but it just isnt our world really. Its like asking us to make it more like Mastodon or Hypercore, no, we made it this way in purpose and we have great reasons for it.

Regarding DHT scale, it used for dns records, and it is very fast and larger than any other decentralized network, so it is weird to be casting doubt from beneath its shadow, no? Yes, all networks hit scaling challenges, but this is why we designed Pubky to put the user in control, to allow for central service in a safer way.

Why do you think we are claiming something prior to our own brand? We literally list every single alternative in the post as well as explain exactly what we do differently and how we use Mainline. 

We are just another group of people with our own ideas about how to fix the web, we dont really owe nostr anything, but we are happy to engage with interested users and devs. It is what it is. 

 > Pkarr was suggested to Nostr people probably a year ago or so. 

Can you link to a conversation? I don't see anything on the nips repo. I can imagine why nostr devs would be resistant. But my point is that you don't have to ask for permission to build on nostr, you could just do it, then say "hey, look how well this works".

It's also fair that if you've had all this in the works since before nostr then you could say the same about us having NIH syndrome. But it's at least interesting that the momentum went with nostr, not slashtags. Maybe that's down to Jack Dorsey, but I think there's more to it than that. That's all on the social level, but you should at least ask why people are building on nostr and not discount it.

My point about DHTs is just limited to p2p networks. DNS doesn't really require that scale, and it seems like pubky also allows for shared network infrastructure, so it may be irrelevant. Nostr relays are really just ad-hoc DHTs, so it's more about how they're used than the technology itself. 

 tons of private conversations with Fiatjaf, and I showed it to Strfry maintainer in private too, and wrote about it here for a year and

https://primal.net/e/note18q4yrj5m2ekvkceq7qn3zqrsxf2w6uq0az2rp867hvz4p5r74wxsa2xchl 

 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. 

 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. 

 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.