What is pubky?
Discussion
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.
