What are the main pros and cons between Nostr and Pubky under the hood?
Discussion
What is pubky?
lol, brand new, still in beta. It’s basically a P2P protocol for “home servers” (just think relays) and then personal “domains” (think keys). Similar in concept to Nostr, except the record of users is placed in the DHT, so it’s insanely censorship resistant and if you ever want anyone to find you or your content, nobody can take down your DNS record because it’s stored through the BitTorrent network.
So there are solid censorship resistant benefits to pubky, but the server model is more traditional, where you don’t really have control, you are just using their server space. You don’t sign every message like you do in #Nostr. Great for UX because you don’t have to keep keys online, but a trade off on trust because each “relay” has the ability to arbitrarily change your messages (like Twitter or any other server).
So my take on Pubky v Nostr nostr:nprofile1qqsw4v882mfjhq9u63j08kzyhqzqxqc8tgf740p4nxnk9jdv02u37ncxzszx8:
the trust relationship is worse in Pubky in some regards because all activity isn’t signed by the user, decentralization makes the likelihood of abuse slightly higher, but the UX of just having to “sign in” and it works as expected and you can use as many clients and servers as you like, plus run your own at home is a solid benefit, and the censorship resistance of the DHT is probably best you can get.
Honestly I think they can be used in tandem where each is optimized for a particular piece of the puzzle. Delays and DHT domains could be used with Nostr. It’s a matter of the right tool for the right job. Curious how each will be used in the long run. Watching both closely
"You don’t sign every message"
Wait... really? 🤦🏻♂️
Yeah you just authenticate your user/device. This is basically how every traditional system works, and that’s why you don’t need some crazy sub key system or have to run around pasting your social private keys into every browser or app you want to try out which is crazy dangerous.
They both have very obvious trade offs and I’m not inclined to make a confident claim as to which is better. They both have pains.
Subkey systems don't have to be crazy, they can work the same way as SSO. Nostr hasn't adopted one because people aren't especially concerned about it. https://github.com/nostr-protocol/nips/pull/1450
I think it’s a mistake to not tackle that. Too often the UX gets sacrificed because everyone thinks that being tech literate is normal. A working subkey system that’s hidden from the user needs to be adopted, imo.
It’s very much like when I go to some “easy to use software” tool and then the first step is open up a terminal window and type some command… the vast audience that instantly checks out at the step is not appreciated.
The UX for a multi key system needs to be a simple key app, like an OTP app or authenticator (which itself is out of the ordinary for most but I think easy enough that it can work), then you go to any client that automatically creates a key, you copy or scan the QR to sign for it, and then that client is associated and treated as your account. Profile information and contacts are synced across npubs.
Then that client shows up in their key app, and at any point they can select it and “delete” it, which signs a new message saying it’s expired, deleted, compromised or whatever and it gets removed from your main npub association.
It would be even better if the main npub is actually shown in place of the client one, after they have been associated. 🤔
I don’t know but that feels like something that’s really important both for security, UX, and so that joining a new client is a very simple, in-band process. Maybe I’m wrong, but if nobody else builds it I might break down and do it, then annoy every client for not supporting it.
Much discussion went into this topic, and the conclusion has been so far that the interoperability of nostr apps would be seriously threatened by such a move.
We have nip46 bunkers and now with #Frostr I really think the subkey hell can and will be avoided.
Bunkers are okay, but complicate the system. Do you have a link on how FROST deals with lost keys?
I'm still surprised that people consider the separation of identity and authorization unnecessary. Combining them might be a core Bitcoiner philosophy though
Bunkers are great for power users but terrible UX for the average person.
I don’t know enough about frost to know if or how it solves the problem.
And interoperability would be purely a problem of adoption would it not? That seems like a bad reason to make a decision at this stage. “Soft forks” only get harder and this is an important one. The “damage” of not being integrated is simply creating a new key for a specific client or service., but that other services would still see as belonging to you if they support it.
In other words the problem would be isolated to clients that don’t support it would not not?
Can recommend latest [TGFN](https://thank-god-for-nostr.simplecast.com/episodes/frostr-wBOrP0Te) episode on Frostr.
It achieves the following:
- You can chop your nsec into shards (shamir secrets). These can generate valid signatures with an arbitrary threshold you configured initially
- You have your nsec (or just the shards of it) in cold storage and can distribute shards to bunkers, even custodians with high uptime in a safe way (eg 2 of 3, one at a custodian, one hot in your bunker and one only used when rotating)
- You can rotate the setup to a new set of shards. However, all setups remain valid (possible problem but not if you don't leak your cold storage nsec or threshold of shards). You cannot rotate your nsec though.
This achieves a kind of key rotation without nsec rotation, and still needs bunkers.
A subkey system would simplify the bunker problem but at the huge cost of transmitting, storing and coordinating a bunch of data on nostr for all events for just the subkey-related stuff.
The coordination part is the nastiest: Nostr is distributed so there is no guarantee of consistency. Therefore I wonder how you want to solve the problem of
"Am I really, really sure that I validated this event against the absolute latest state of this user's keys?
Was this event really signed before that old key has been deprecated?"
Nostr is designed so that no relay needs to be an absolute source of truth. The events themselves, signed by the pubkeys are. Self authentication. But what do we do when this assumption is broken? It all falls apart. You cannot have absolute consistency on nostr.
...and subkeys would not simplify the master key leak either.
It keeps sounding like Relays are the elements that could use a #pubky most. #noobthoughts
Can't we just use the keys interchangeably with pubky protocol?
I don’t see why you wouldn’t be able to add both connection methods into a client and reach relays over the DHT. Or just use the pubky domains as a way to know how to reach the relay, and then the relay can bounce around to as many servers or locations as they like and the client will still find them without any needed update from the user.
> use the pubky domains as a way to know how to reach the relay
Yes :110percent: what I'm thinking.
I'm just also :110percent: the guy to be naive about that idea working as well as I think it would.
This is a great answer!
Also, I learned that the two protocols could be made compatible but sadly they use different cryptographic curves (pubky: ed25519 vs nostr: secp256k1) which makes this kinda problematic.
John actually said you could create a Nostr key from a Pubky pretty easily during the demo. I specifically asked and he seemed to think it wouldn’t be hard, but I’m not sure exactly their relationship or how you’d go about it
Then I might be wrong about this.
I think the compatibility would help in a hard-core censorship scenario. If all bootstrap relays like purplepag.es or damus are methodically censored on the dns level, there is no starting point to discover users relay lists.
In this case some trustworthy pubkeys could just run a homeserver relay and the pubky protocol essentially allows to access those in such a scenario.
Also, anyone could run their own personal relays in a censorship-resistant way. Say you are Alex Jones or on some high-level blacklist, you would run your stuff on pubky, so you have a censorship-resistant pointer to your relays.
The one is a nice censorship resistant global place and the other just a pub in New York, no?
Pubky, not Pubkey.
Pubky is a key-based platform.
Sorry, thought so but couldn't resist. 😄
I've a tab open, but it's still in private beta. I've no answer to your question, so hopefully someone else can explain.
Simplicity. Pubky tries to solve the indexing problem of where to find people's data from the web of servers out there. Nostr just deffers that to a NIP.
What is the indexing problem?
Finding which server has which event is a massive computer science problem. Nostr solves it by using relay hints of where things could be. Pubky uses a DHT protocol underneath.
"defers that to a NIP" as in "leaves it to the client devs to figure out". We don't have consistent standards and your feed looks different on different clients. Some find stuff others don't find.
It emulates real life, honestly. And that gives it an edge by being aligned with nature rather than opposed to it, trying to make global state a thing.
I see it the other way around; a global state will always want to emerge from these kinds of networks, and trying to fight the emergence of that global state is like trying to fight nature itself.
Nostr already has a de-facto global state as a result of private parties crawling and indexing the full network. Not a perfect global state of course, but close enough, and one that enables faster loading, advanced search, accurate follower counts, and much more.
I'd estimate that over 80% of Nostr revenue—as in what could be claimed as income on a corporate tax return—is going to parties that are crawling and indexing the whole network. The parties that are not indexing the whole network are fighting for the remaining 20%.
Slowly the fruits of these indexing efforts, being so tasty, will work their way into all clients, and the fruit juice will seep everywhere, and from that point forward calling Nostr a network with "no global state" will be merely lip service to a glorified past.
This always happens. As if nature demands it. Well *human* nature anyway.
Nostr is a lot simpler, being just a specification of some data structure and message format, which let anyone write infrastructure for it. Pubky is still in development, but has a stricter client-server model with public keys.
How can it be more strict than "This is a client and this is server wich we call relay."?
Whereas Nostr started off completely open ended, the pubky team has developed the complete infrastructure for their network in advance.
The strictness of the system is based on how much third party code you are required to run for it to work. And I'm sure it would be a huge endeavor to write alternative implementations of pubky once it's released. As opposed to Nostr where you just give the whole network the finger and write something from scratch.
Same principle as bitcoin, you own your key you own your coins, here you own your keys you own your ID/speech.
I meant comparing Nostr vs Pubky, that other key-based protocol that John Carvahlo and others are developing.
never heard of it, there is always some new protocol out there 😉
Just looked into it a bit. It seems they expect everyone to run a home server.
I don't know a whole lot yet but off the bat it would seem to me that the server model of pubky would be more centralized than nostrs relays.
I'm on nostr because nostr had a cool wiki when I joined
Fiatjaf then ruined nostr's wikis with asciidoc, but does pubky have a good decentralized wiki?
Is Digit on pubky? She's not here so that would give pubky the advantage
Without Digit, and without the wiki that brought me here, the biggest difference is probably that nostr has me on it 🤙
awww, who's a good girl, who's a good girl!? c'mere buddy! aww you're such a good doggie. you're such a good doggie. do you want some rubs and scratches? *hugs* *rubs* *scratches*
i don't know anything about pubky except that they didn't build on nostr, so im not interested.
i know this isn't helpful. i just love doggies. someone much smarter than derek will most likely answer.
*hugs* *rubs* *scratches*
Arguments on the side of pubky were covered pretty well in this podcast. Most was above my head so the main takeaway was that John wasn’t getting his ideas implemented into nostr so he made his own version. https://fountain.fm/episode/Kgb7t2A5BEFN9yjtklty
Pubky allows you to prove "what's yours" based on the homeserver you control (tied to your ID). This gets around the problem of events forever out there that are signed by you but that didn't in fact come from you, which can happen on nostr if you expose your nsec, leave your laptop around, etc.
I kind of like how I can just delete or edit any post of mine in Pubky anytime. It makes me the real authority on my data.
People have been arguing about IP law lately, and I think this is a good primitive to discuss any remotely rational alternative to the current system.
If I am the authority on my data, it means that any version of it that is copied can be strictly identified as such. You could even establish provenance in deep ways with tagging, social graph, and some sort of signing/stamping or structured data trie or such.
We can add versioning, tree-based data structures, and even per-event signing like Nostr if we want, but for now, it feels nice being in control, even when I am trusting a homeserver.
I wonder if per-event signing like Nostr might even be a net negative? Homeserver as source of truth sounds balanced for me—events flying around the indexer or however that works I think maybe I'd rather not be signed, that gives plausible deniability when needed and plausible deniability can be very useful. On the flip slide, if someone is suspicious and does want to verify an indexed event of mine then just have a look at my homeserver, not so hard.
We did not include signing all data for a reason. It doesn't actually fix anything.
Some of the problems people quote to justify signing everything are only theoretical problems (you never hear about trusted servers mutating data really,, despite it being possible). And all of the problems signing introduces are ignored.
If you want attestation or proofs there are better ways to do it either incidentally or inherently with tree structures.
I'd rather have a mirror/watchtower than a bunch of floating signed messages inconsistently available across relays.
Yeah I'm open to that argument. Confidence is a lowest common denominator; if you're confident data is being signed but not not confident it's being made locatable and available then stands to reason you're not confident overall and would still need some fallback anyway.
That's a soft definition of "proof", and it makes censoring one person as easy as pwning their home server or messing with their ISP
I dunno what to tell you, that's just flat-out factually wrong. Read all the articles in this blog, you'll soon figure out why what you said results from a fundamental misunderstanding of how things *actually* work.
I'm happy to engage with arguments, but "go read all these things" is some else's homework.
If the definition of "what you have said" is the contents of a computer, then:
- Your ISP can remove you from the network
- Anyone else's ISP can remove you from their network
- Your server dying will remove you from the network
- Malware or a hack can arbitrarily change what you have "said"
There is no censorship resistance in this
its still a bunch of promises, yet
the main idea is to allow a DNS similar indexing capable of indexing every single pukey that will exist which is totally feasible (similar to DNS) these indexes allow users to reach the content of a particular user, although we have this functionality here in a simpler nprofile link that refers to the read/write relays behind the scenes
https://github.com/nostr-protocol/nips/blob/611b6351863e128f470576586f0e2b9a75f19039/19.md
but from my POV what seems as the big promise of Pukey is that through this all of this indexing stuff they might allow for a weighted graph relationships between users, posts and interactions (Semantic Social Graph as - they call it https://docs.pubky.org/Explore/Concepts/Semantic-Social-Graph ) which is cool and considered the best approach to data in social-media due to the dynamically infinite possibilities for curated personalized experience as its used by facebook (all meta apps)
but as i said that's still a promise
This may have failed the golden retriever test.
The DNS capabilities you mention are already open-sourced and live. You can check out the PKDNS, MAINLINE and PKARR repos at github.com/pubky
The Nexus Indexer is also open-sourced and running live.
The only thing private is a new app we are building, which we will open-source in June.
Definitely will
Pubky is only key-based in the sense that they use a DHT to map keys to home servers. But data isn't signed, which means in order to be sovereign you have to run your own home server. Even then, aggregators/proxies become trusted intermediaries. Nostr actually puts keys at the center of the protocol.
See my nostr:nprofile1qqsdluwc0qu62t3el7nxl93387gmppe56jkvm88vcuwh3lpw4fcevwsc4as3x episode with nostr:nprofile1qqsfxrxw7y3h9hf0zczhelz57rdajse4mz63kn38xu3kkqx2kuv0ekgtx70ra for more details:
> in order to be sovereign you have to run your own home server.
How could one be sovereign otherwise? If all one's notes are stored on relays that someone else runs, is one sovereign? if all one's photos and videos are stored in someone else's AWS account, is one sovereign?
If you sign your data it becomes self-authenticating. True, you'll never have 100% certainty that your data won't be removed unless you self-host, but you can replicate your content across multiple more or less trusted hosts, who would all have to deplatform you at once for it to be effective. You can also keep a back up and re-upload it to a new host at any time. This is good enough for most people, and the option of self-hosting is always open to people who feel they have a higher risk of deplatforming.
They could still perform a man in the middle attack, re-signing all of your notes with a new public key.
But then they would be signed by a different key
I’m thinking more on reverse lines. If your home server is your source of truth then you are in control of that truth as it evolves. With nostr you hand over your truth, signed, to live forever outside your control, unchanged from the moment you sent it away. You become a prisoner of time in a way, a prisoner of a moment.
Yes, not having reliable delete is a trade off. But that's just reality, there is no way to revoke information once it's shared. Screenshots usually suffice for any use case for which retaining someone else's signed notes would be useful.
Looks really cool. I don't have much time to look into it, but the moment it enters public beta, I'm going to make a second account there.
con - if you are even mildly critical of pubky protocol, their whole staff -- who moonlight as nostr reply guys -- will swarm you with sanctimonious explanatioooons until they feel like they've shut you down or patted themselves on the back enough to move on without having heard a word you said
con - their CEO thinks he is the most principled and benevolent leader there ever was 🚩🚩🚩
Under the hood, they are two decentralized, anti fragile social protocols, with different architectures, promoted by two influential bitcoiners. nostr:nprofile1qqsgydql3q4ka27d9wnlrmus4tvkrnc8ftc4h8h5fgyln54gl0a7dgspxdmhxue69uhkuamr9ec8y6tdv9kzumn9wshkz7tkdfkx26tvd4urqctvxa4ryur3wsergut9vsch5dmp8peszrthwden5te0dehhxtnvdakqtxjx6r (#Nostr) and @paoloardoino (#Pubkey). Although #Nostr has a head start, #pubkey, once live, will be the most decentralized, from the start, due to its baseline P2P protocol. The most interesting topic to follow, in this space!!!