Nostr Web Client

So Web5 has completely ditched ION and don't even explain to anyone why?, or even make a comment about ditching it?, they will just pretend ION never existed after so many years of telling all the critics that ION was this amazing idea and that anyone who dared to criticize it was dumb?

https://twitter.com/csuwildcat/status/1761168521663316228

fiatjaf 1y ago

The most stupid thing about the entire concept of a "DID" is that it was supposed be this one interoperable thing, right? You use "DIDs" in your project and now people using all sorts of DIDs can interoperate.

But what actually happens in practice (obviously) is that projects have to pick one specific DID and support just that.

So Web5 only works with "did-dht" and Bluesky with "did-plc" (aka their server) and one is not compatible with the other.

But somehow Nostr is less compatible and morally wrong because Nostr keys don't have a "did:" prefix in them.

nostr:nevent1qyd8wumn8ghj7urewfsk66ty9enxjct5dfskvtnrdakj7qgmwaehxw309aex2mrp0yh8wetnw3jhymnzw33jucm0d5hsz9mhwden5te0wfjkccte9ehx7um5wghxyctwvshsz9thwden5te0wfjkccte9ejxzmt4wvhxjme0qy88wumn8ghj7mn0wvhxcmmv9uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshszxrhwden5te0wfjkccte9e3h2unjv4h8gtnx095j7qpqzxjq7cesh9dehesk60k99xlgkqf4st98l8ax2kz6wzd4zt08nkeqz3ts7a

Reply to this note

Please Login to reply.

Discussion

frphank 1y ago

It'll converge somehow. The important part is the basis of cryptographic identities i.e. public/private keypairs.

Everything else are superficial differences. Once tke keypairs are there you can easily convert between formats.

You can even link separate identities from different ecosystems even with different key algos (e.g. EcDsa vs. EdDsa) via certificates a.k.a. nostr "delegates".

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z

nostr:npub1w4uswmv6lu9yel005l3qgheysmr7tk9uvwluddznju3nuxalevvs2d0jr5

fiatjaf 1y ago

"somehow"

frphank 1y ago

Yup.

frphank 1y ago

That linked document specifies a "did:key" btw -- that's like nostr.

fiatjaf 1y ago

Except no, because keys are different in different curves, and Nostr is not interoperable with anything because Nostr keys specifically sign Nostr events and all the tooling and apps expect that. It's not possible to just plug a new DID method, which was the idea, but I don't expect you understand my point anymore.

_ 1y ago

did:key has secp256k1 variants, and if you used did:dht, you can just put your npub in your key set, along with any other keys you want to add of any types. Additionally, you can add relay endpoints to your DID's service endpoint routing section.

frphank 1y ago

😃😃

I'm glad we've got smart cookies running the show here.

frphank 1y ago

Btw the did "DHT" thing has been around for a long time in IPFS called IPNS.

https://specs.ipfs.tech/ipns/ipns-record/

Nuh 1y ago

Except Mainline is a decade older than IPNS and IPNS doesn't fuckin work like all protocol labs garbage

hacktheplanet 1y ago

Be fair. It ... wait... wait... wait... wait... wait... works most of the time!

frphank 1y ago

Both DHTs are Kademlia and work exactly the same. If IPFS appears slower then that's -- ironically -- because it's so much more popular.

frphank 1y ago

You didn't have an answer last time, you don't have one this time.

nostr:note1qm6l6kzcv9acp6zymz068l5gmken8ja8llwptqq0hsvanjajuzyssv2wt8

Nuh 1y ago

Good luck.

Mike Staub 1y ago

They all can interoperate as the schemas and standardized, how they are resolved to documents is an implementation detail and adapters are trivial to implement. This is an elegant design pattern for linking systems across orgs.

frphank 1y ago

👍

Vitor Pamplona 1y ago

Yep, DID Resolvers have always been a huge issue.

Funny thing: the universal DID resolver https://dev.uniresolver.io/ instantiates a docker machine for each DID method because it's impossible to develop a single library that resolves them all.

frphank 1y ago

That's fine. It's early days. Things will converge.