5 ms·

Because expecting standardization of DID methods at this point is unreasonable. A premature attempt to standardize DID methods would be both futile and likely

Because expecting standardization of DID methods at this point is unreasonable. A premature attempt to standardize DID methods would be both futile and likely harmful. It's futile because the future universe of DID methods can't be anticipated now, so whatever wrong set of DID methods W3 promulgated would include both poor choices and omit good choices. It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard. Better to avoid prematurely enshrining some arbitrary set of methods and allow a consensus to emerge via practice and exposure. At some point, as the inevitable shake-out of bad ideas and nefarious actors occurs, DID methods can be standardized in a useful way. Yes, the lack of a simple list of SHALLs will impede the immediate adoption of DID for all conceivable purposes, but better that struggle than the next to impossible task of loosening the grip of beneficial parties that have a standards document to wave around. It's almost like they've learned something over the last quarter century.

cratermoon 4y ago
> It's futile because the future universe of DID methods can't be anticipated now, so whatever wrong set of DID methods W3 promulgated would include both poor choices and omit good choices Or maybe it's just too soon to try to carve a "standard" into the w3c process stone. A half-baked protocol is worse than no protocol at all.
- asimpletune 4y ago
  > A half-baked protocol is worse than no protocol at all. I think the literal opposite is true, no?
  - SahAssar 4y ago
    If there is no protocol nobody expects interoperability. If there is a half-baked protocol everyone expects interoperability but it never works as it should.
    - cratermoon 4y ago
      > never works as it should. Not only that, by exploiting ambiguities and gaps, protocols can be made to work as they shouldn't. At least that keeps the security consultants in business.
DannyBee 4y ago
If you have literally no idea what a good or bad answer even looks like, it's not time to standardize it at this sort of formal level yet. Beyond that, some of this is just odd. " It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard." Good. We can deal with that in v2.0. Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know, then i go back to the first sentence i wrote :) Beyond that, your optimism in what will happen (shakeout of bad ideas and then harmonious replacement with standards) seems ... mostly misplaced. Assume it takes off - what will instead happen is that you will be stuck supporting tons of non-standard methods developed between now and when anyone standardizes them forever. It will likely hamstring your future development as well. I cite as evidence - literally the history of everything :) There was 100% no reason to standardize this now other than wanting to feel good about themselves. It isn't needed to push forward. It should have waited until someone had any idea what good looks like.
- dmitriid 4y ago
  > Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know Whatever you design for the web stays on the web for decades. So yes, you have to look into the future and anticipate things. It's not "move fast and break things"
  - DannyBee 4y ago
    I'm not at all suggesting move fast and break things. Yes, things stay for decades. So don't standardize something when you have literally no idea what good looks like. There is a limit to anticipation. Trying to guess what the world will look like 10 years from now is dumb. Nobody does it well. So just because v1 will have inertia doesn't mean you will actually predict the future more successfully. Instead, you have to figure out how you deal with that inertia. In practice, the reason things have tremendous intertia is because they are often not built to be migrated from or to in a relatively seamless way. Those standards that allow for easy migration tend to see much faster adoption of new versions. Those that don't, the old standards linger even longer.

cratermoon 4y ago

> It's futile because the future universe of DID methods can't be anticipated now, so whatever wrong set of DID methods W3 promulgated would include both poor choices and omit good choices Or maybe it's just too soon to try to carve a "standard" into the w3c process stone. A half-baked protocol is worse than no protocol at all.

asimpletune 4y ago
> A half-baked protocol is worse than no protocol at all. I think the literal opposite is true, no?
- SahAssar 4y ago
  If there is no protocol nobody expects interoperability. If there is a half-baked protocol everyone expects interoperability but it never works as it should.
  - cratermoon 4y ago
    > never works as it should. Not only that, by exploiting ambiguities and gaps, protocols can be made to work as they shouldn't. At least that keeps the security consultants in business.

DannyBee 4y ago

If you have literally no idea what a good or bad answer even looks like, it's not time to standardize it at this sort of formal level yet. Beyond that, some of this is just odd. " It's harmful because whatever future methods might emerge will relegated to a second class for having failed to 'get in' on the initial standard." Good. We can deal with that in v2.0. Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know, then i go back to the first sentence i wrote :) Beyond that, your optimism in what will happen (shakeout of bad ideas and then harmonious replacement with standards) seems ... mostly misplaced. Assume it takes off - what will instead happen is that you will be stuck supporting tons of non-standard methods developed between now and when anyone standardizes them forever. It will likely hamstring your future development as well. I cite as evidence - literally the history of everything :) There was 100% no reason to standardize this now other than wanting to feel good about themselves. It isn't needed to push forward. It should have waited until someone had any idea what good looks like.

dmitriid 4y ago
> Trying to design this kind of thing to anticipate every possible future good thing that might come along is a folly. If you can't standardize them yet because you don't even know Whatever you design for the web stays on the web for decades. So yes, you have to look into the future and anticipate things. It's not "move fast and break things"
- DannyBee 4y ago
  I'm not at all suggesting move fast and break things. Yes, things stay for decades. So don't standardize something when you have literally no idea what good looks like. There is a limit to anticipation. Trying to guess what the world will look like 10 years from now is dumb. Nobody does it well. So just because v1 will have inertia doesn't mean you will actually predict the future more successfully. Instead, you have to figure out how you deal with that inertia. In practice, the reason things have tremendous intertia is because they are often not built to be migrated from or to in a relatively seamless way. Those standards that allow for easy migration tend to see much faster adoption of new versions. Those that don't, the old standards linger even longer.