Add Pubky Integration

[melvincarvalho]

Propose an integration with the Pubky protocol, which has just launched.

There are many ways to do it, but the simplest that will work is to integrate with NIP-24

 "pubky":  "96617cf250515332a051cb751b61ca2a320b1787216ba52a54379f488ae10ba2"

Clients already use and respect this. One line just needs to be added to the NIP text for a full integration.

Implementors can go ahead and implement this today. As deployments grow, the NIPs can reflect what is in use.

About pubky - Links taken from their official room

Some Pubky links to get started!

Blog post overview:

• https://x.com/BitcoinErrorLog/status/1850442303921590754

• AI Deep Dive Podcast - https://x.com/BitcoinErrorLog/status/1850067213442511107

• https://pubky.org - all about the code

• https://pubky.app - all about the app

• https://synonym.to - all about the team

• https://pubky.org/#demos - Pubky Demo Week, a new demo each day!

• https://github.com/pubky

[vitorpamplona]

What would the extra metadata field do?

It feels like if we had to use something like pubky, it would be to avoid using relay URLs with domain names and just connect to the relay's own key instead. So, I don't know what the extra NIP-24 field would be doing.

[melvincarvalho]

I have implemented pubky in noskey which will allow you to generate a pubky from your nostr privkey

noskey -p <privkey>

Should work.

Note: the pubky value is without any URI prefix as that is implied from the json key.

It should not be possible to start putting pubky values into nostr profiles and beginning to use pubkey apps

[melvincarvalho]

Showing what the UX could look like, mastodon have had this feature for a long time.

It should be farily easy to copy.

[melvincarvalho]

It has also been integrated into nslookup. The Ben is running a no-tracking DNS server.

This is a big deal because it allows every npub to have a censorship-resistant domain, no more takedowns, no gatekeepers, and your data is stored across a resilient, battle-tested, massive network of nodes.

$ nslookup -type=txt  _npub.8xssyidksmiup9og9k47s41hy7zt71r74fm6zhoc3cuxj9qr7ray 66.78.40.76

Server:		66.78.40.76
Address:	66.78.40.76#53

Non-authoritative answer:
_npub.8xssyidksmiup9og9k47s41hy7zt71r74fm6zhoc3cuxj9qr7ray	
text = "npub17zh5navmw7zrdmdfgm8khmeef0zrgyn4kjx4g2x6j0fkcyg7m8wqe3zmwj"

[melvincarvalho]

This would be solved with: #1593

[mikedilger]

Just add it to metadata. People added dozens of fields to metadata before with no community synchronization or discussion. Metadata doesn't have a strictly defined set of keys. You can have it listed on NIP-24 if you want.

[melvincarvalho]

Just add it to metadata. People added dozens of fields to metadata before with no community synchronization or discussion. Metadata doesn't have a strictly defined set of keys. You can have it listed on NIP-24 if you want.

That makes a lot of sense. However, I realized there’s some confusion around what pubky really is, which became clear while chatting with @DanConwayDev. Let me clarify:

Pubky is actually two things: a system and a serialization.

1. The Serialization:
   Think of the pubky as "the npub of ed25519." It's essentially a base32-encoded ed25519 public key (without a checksum). This makes encoding/decoding effortless. It’s already used in systems like BitTorrent, where it’s proven incredibly practical for users. If you’re curious about the broader possibilities of ed25519 public keys, this page sums it up well:
   https://ianix.com/pub/ed25519-deployment.html

   Imagine opening the door to all these use cases for nostr: apps, devs, and users. It’s especially useful for git, adding instant tooling like signing and verifying commits. That’s a big win. And since nostr’s private key and ed25519 private key are the same, we don’t even need to reinvent key management—it’s all ready to go.

2. The System:
   The system aspect of pubky is what people seem focused on. Sure, it’s great for censorship-resistant DNS, leveraging your public key for lookups. But that’s just one of many possible use cases. Once ed25519 keys are added to profiles, the possibilities multiply.

   I wonder if the term "pubky" itself caused confusion, as it might seem like something unique. But really, it’s just ed25519 in action—a well-known standard that’s been used for decades (thanks, to BitTorrent, git, ssh, ssl etc).

   Adding ed25519 to your nostr profile becomes a strong cryptographic assertion. You can even take it a step further: sign your pubky from the other key (like NIP-05) to prove control of both. That’s powerful—but perhaps overkill.

[melvincarvalho]

What would the extra metadata field do?

It feels like if we had to use something like pubky, it would be to avoid using relay URLs with domain names and just connect to the relay's own key instead. So, I don't know what the extra NIP-24 field would be doing.

Relays without DNS would definitely be an interesting use case. The benefit here is that if one server is taken down, the key can simply point to another server with minimal disruption—and no need to purchase or rely on a domain name, to run a relay.

But the potential goes far beyond just DNS-less relays. Adding pubky unlocks a wide range of use cases, as mentioned in the comment above. For example, Ed25519 keys are also used in systems like Tor, which you might find interesting. This approach could enable greater flexibility and resilience in relay infrastructure while adding more possibilities for decentralized tooling.

[mikedilger]

And since nostr’s private key and ed25519 private key are the same, we don’t even need to reinvent key management—it’s all ready to go

I'm a bit skeptical about using the same bits for the private key of both cryptosystems. But barring this point, I'm not against users having ed25519 keypairs and binding these to nostr keypairs. I think it would open up a lot of things.