add did-nostr #56

New issue

Open

opened 2025-04-04 01:39:34 +13:00 by melvincarvalho · 4 comments

melvincarvalho commented

2025-04-04 01:39:34 +13:00

(Migrated from github.com)

🧭 What Does did-nostr Do?

did-nostr is a DID method that brings decentralized identity to Nostr. It lets you attach useful metadata and service endpoints to your Nostr public key, turning it into a portable identity hub.

Instead of just being a key that signs events, your Nostr pubkey becomes a rich identifier that can point to relays, profiles, storage, Bitcoin wallets, and much more.

https://dev.to/melvincarvalho/what-does-did-nostr-do-2o68

🧭 What Does did-nostr Do? did-nostr is a [DID method](https://www.w3.org/TR/did-core/) that brings decentralized identity to Nostr. It lets you attach useful metadata and service endpoints to your Nostr public key, turning it into a portable identity hub. Instead of just being a key that signs events, your Nostr pubkey becomes a rich identifier that can point to relays, profiles, storage, Bitcoin wallets, and much more. Read more: https://dev.to/melvincarvalho/what-does-did-nostr-do-2o68

mikedilger commented

2025-04-04 11:20:24 +13:00

(Migrated from github.com)

I've read https://www.w3.org/TR/did-1.0/ and https://dev.to/melvincarvalho/what-does-did-nostr-do-2o68

DIDs could be added on without the core system needing them, and DIDs would be useful if there is some external system that uses it. Otherwise it becomes a formalization that isn't used.

So I'm not against as something like an extention, but I don't see a compelling reason to depend on DID documents within the core.

In particular I'm not at all excited about software needing to understand the meaning of and act on all these different keys and well-known values. I'd much rather introduce such things slowly, one at a time, with a clear need and purpose.

Of course I'm into the self-sovereignty, and attaching metadata and service endpoints. But that can be done in the DHT which also provides the "registry".

I've read https://www.w3.org/TR/did-1.0/ and https://dev.to/melvincarvalho/what-does-did-nostr-do-2o68 DIDs could be added on without the core system needing them, and DIDs would be useful if there is some external system that uses it. Otherwise it becomes a formalization that isn't used. So I'm not against as something like an extention, but I don't see a compelling reason to depend on DID documents within the core. In particular I'm not at all excited about software needing to understand the meaning of and act on all these different keys and well-known values. I'd much rather introduce such things slowly, one at a time, with a clear need and purpose. Of course I'm into the self-sovereignty, and attaching metadata and service endpoints. But that can be done in the DHT which also provides the "registry".

👍 1

melvincarvalho commented

2025-04-16 07:09:16 +12:00

(Migrated from github.com)

What does the 'core' mean? I thought 10% of nostr was the protocol and 90% extensions.

Yes, you can attach meta data via a DHT, but that will be slow and it wont be uniform

People already starting to use DIDs. I'll probably base all of my nostr next technology on it, personally.

https://medium.com/@sondreb/scaling-nostr-e50276774367

What does the 'core' mean? I thought 10% of nostr was the protocol and 90% extensions. Yes, you can attach meta data via a DHT, but that will be slow and it wont be uniform People already starting to use DIDs. I'll probably base all of my nostr next technology on it, personally. https://medium.com/@sondreb/scaling-nostr-e50276774367

mikedilger commented

2025-04-16 07:33:41 +12:00

(Migrated from github.com)

What does the 'core' mean?

I just mean something that every single client and every single relay must know about and code for.

> What does the 'core' mean? I just mean something that every single client and every single relay must know about and code for.

melvincarvalho commented

2025-04-28 21:34:51 +12:00

(Migrated from github.com)

So I'm not against as something like an extention, but I don't see a compelling reason to depend on DID documents within the core.

I've articulated a few here:

Global discovery without relying on central servers.
No need for DNS or other trusted naming systems.
Discovery relays make finding people and data more flexible.
Profiles can stay consistent across apps and relays.
Personal storage can be linked directly to your identity.
Easy integration with pubky and other nostr tools.
A path toward open standards for business and enterprise adoption.
Financial commitments possible via Taproot and Bitcoin.
Relay lists can travel with you, making switching easier.
Extensible to many use cases, pemissionless
Agentic nostr allows orchestration of agents
helps nostr scale better by reducing duplication.

Note: that nostr is failing on quite a lot of these points in reality, and will continue to fail on them for years. I'd love to use another solution, in fact I thought we'd have one years ago, but nothing has emerged or is emerging. So even though I have reservations about DID, I decided to make it.

In particular I'm not at all excited about software needing to understand the meaning of and act on all these different keys and well-known values. I'd much rather introduce such things slowly, one at a time, with a clear need and purpose.

This makes sense. However it uses JSON-LD which is global standard, used on billions of pages, and millions of websites (e.g. with schema.org), so most JSON tooling already speaks it.

Clients can just ignore what they are not interested in, and use what they are interested in.

Of course I'm into the self-sovereignty, and attaching metadata and service endpoints. But that can be done in the DHT which also provides the "registry".

Good! DHT is another great delivery method, and it can also deliver a DID.

Sondre has written up some good arguments here: https://medium.com/@sondreb

> So I'm not against as something like an extention, but I don't see a compelling reason to depend on DID documents within the core. I've articulated a few here: - Global discovery without relying on central servers. - No need for DNS or other trusted naming systems. - Discovery relays make finding people and data more flexible. - Profiles can stay consistent across apps and relays. - Personal storage can be linked directly to your identity. - Easy integration with pubky and other nostr tools. - A path toward open standards for business and enterprise adoption. - Financial commitments possible via Taproot and Bitcoin. - Relay lists can travel with you, making switching easier. - Extensible to many use cases, pemissionless - Agentic nostr allows orchestration of agents - helps nostr scale better by reducing duplication. Note: that nostr is failing on quite a lot of these points in reality, and will continue to fail on them for years. I'd love to use another solution, in fact I thought we'd have one years ago, but nothing has emerged or is emerging. So even though I have reservations about DID, I decided to make it. > In particular I'm not at all excited about software needing to understand the meaning of and act on all these different keys and well-known values. I'd much rather introduce such things slowly, one at a time, with a clear need and purpose. This makes sense. However it uses JSON-LD which is global standard, used on billions of pages, and millions of websites (e.g. with schema.org), so most JSON tooling already speaks it. Clients can just ignore what they are not interested in, and use what they are interested in. > Of course I'm into the self-sovereignty, and attaching metadata and service endpoints. But that can be done in the DHT which also provides the "registry". Good! DHT is another great delivery method, and it can also deliver a DID. Sondre has written up some good arguments here: https://medium.com/@sondreb