Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle duplicates #569

Open
jandrieu opened this issue Jul 22, 2024 · 2 comments
Open

How to handle duplicates #569

jandrieu opened this issue Jul 22, 2024 · 2 comments

Comments

@jandrieu
Copy link
Contributor

As I mentioned this on our call (last week?), there is no requirement in the DID Core spec that method names be unique. However, the current registry editors are following a first-come, first-served policy, which gives an unfortunate advantage to first movers, creating significant problems with name squatting, abandonment, censorship, and maintenance.

I suggest we follow the semantics of phone directories, aka white pages, which regularly list multiple entries for people with the same name. Sometimes they provide meta-data like an address for the reader to disambiguate. What they do not do is restrict listings based on the first to sign up with a particular name.

I realize this undermines the reasonable desire many in this work have, to create an automated discovery mechanism where you can programmatically depend on the method name itself as if it were unique. However, if we base the root of the DID namespaces on a centralized authority, we have merely recreated the pattern successfully implemented by DNS.

The hard problem is figuring out how to deal with the fact of nature that people can, and will, create DID methods that have conflicting human-friendly names (see Zooko's triangle).

IMO, solving this problem in a decentralized way would mean there is no single authority who

  1. gets to/must decide who was "first" to register something,
  2. gets to decide who can update a listing initially created by someone else,
  3. gets to define or restrict mechanisms used by other's DID methods

What we MUST deal with in a centralized manner is the shared specification of how such systems interoperate. That's the URL syntax, DID document format, and the resolution API. That's it.

With consensus on what a DID URL means, what resolution provides, and the API for requesting DID Documents from conformant resolver, then we have an interoperable system that gives everyone the ability to pick and choose which methods they want or need to support, without deference to any centralized authority. Each method's resolvers provide the software component that enables a common interface and developers are free to build to that common interface when integrating different DID methods into their software stack.

That's the hard problem we are here to solve.

@wip-abramson
Copy link

This is related to #374, although the discussion is more around how to handle namesquatting.

@wip-abramson
Copy link

See also #304, which discusses allowing multiple registrations for the same name.

The issue makes me think that handling duplicates is not just about DID methods, but all properties in the registry. Is that reading correct?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants