Threads for cel

  1. 3

    A related headline: W3C overrules objections by Google, Mozilla to decentralized identifier spec.

    Edits! Thanks to this comment:

    The W3C response to this: Director’s Decision on DID 1.0 Proposed Recommendation Formal Objections.

    Personally I find it deeply concerning that this spec would rely on a proof-of-work blockchain.

    1. 9

      The linked FAQ is the DID Working Group’s public response to the formal objections in 2021. The W3C (Director) decided on the formal objections in 2022: (

      The Decentralized Identifiers (DIDs) v1.0 specification does not rely on proof-of-work or blockchains. How to perform DID operations - recording, distributing, and querying state, etc. - is up to each DID method.

      1. 5

        This is a fantastic clarification, thanks for commenting!

        1. 1

          You’re welcome! It’s an important concern.

          It should be up to applications what DID methods to support.

          Some DID methods are rated by various criteria, in this DID Method Rubric: Some applications may choose to support or prohibit some DID methods based on relevant criteria for various use cases.

          Some DID methods are listed in DID Specification Registries: Listing there is not required and does not imply any kind of endorsement; but it is intended to reduce namespace conflicts.

      2. 7

        I haven’t read through the whole spec yet, but based on the Introduction, I don’t see anything requiring a blockchain.

        The obvious way to define a concrete DID scheme is to put a public key (or digest thereof) into the URI, and to have the identity document be signed by that key. The tricky part is how the payload of a URI is resolved to that document. The spec says:

        …any such system that supports recording DIDs and returning data necessary to produce DID documents is called a verifiable data registry. Examples include distributed ledgers, decentralized file systems, databases of any kind, peer-to-peer networks, and other forms of trusted data storage.

        It’s “just”a global namespace that maps public keys to signed identity documents. This is conceptually simple; the only problems are scale and redundancy. Those are serious problems but they’re simpler than those of decentralized digital currency, and they don’t need the same solutions (blockchains.) There are existing technologies like Keybase that attempt to solve it.

        Here’s a simple but workable non-blockchain solution: upload your identity document to any web server, with its HTTP URL containing the encoded public key, and link to it from some public HTML page. Then resolvers can use any web search engine to look for it.

        1. 1

          Good idea! Sounds like a hybrid of did:key and did:web.

      1. 6

        Here’s the actual spec. Odd that the PR didn’t link to it.

        1. 1

          Here is also the particular version/snapshot published today as the Recommendation:

          W3C’s home page currently links to this^ - in this blog post:

          Additional backlinks in W3C public mailing lists:

          Shared on Lemmy:
          Shared on Secure Scuttlebutt: %EiDaoVNwPGMteykCAmkoMS8r4hpreGANkw9eZPy6BJw=.sha256

          1. 2

            So how do nodes actually find each other?

            1. 2

              Addresses of pub servers are shared on the network and used for connecting. Nodes on the same LAN discover eachother using UDP broadcast packets. Using an invite code triggers connecting to a node at a specific address.

            1. 1

              What happen if one fork it’s own log of event?

              1. 1

                Peers won’t accept new messages that reuse a sequence number of an existing message in the feed. So they will stop being able to replicate that feed.

                1. 1