Conversation

Notices

1. Embed this notice
   Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 06:50:02 JST Alex Gleason

   I’m reading about ATProtocol so you don’t have to.

   Instead of ActivityPub IDs (which are URLs like https://gleasonator.com/users/alex), they use DIDs (“decentalized ID”). What’s a DID? Absolutely nothing - it’s an 87 page document describing the format of a string that starts with did: and no implementation details.

   The implementation is up to you. Well, there are some already. We have did:etho:Ac9aB5Fc04Dc1cB1789Af75b523Bd23C70B2D717 for Ethereum addresses, did:dns:alexgleason.me for domain names, and there’s even one called did?xxx for MasterCard’s proprietary/centralized(!) ID network. DIDs are in the format did:<method>:<id>, where the method can be a known method enshrined by the w3c, or a custom one.

   So what’s ATProtocol using? A custom “work in progress” DID method called “placeholder” (did:plc:<id>) that… seems to talk to a centralized server?

   Remember when Bluesky was under development for 2 years because they couldn’t figure out how to do decentralized identity. So what did they do? THEY JUST GAVE UP?

   The did:plc spec is a vague “work in progress”: https://atproto.com/specs/did-plc

   We cheekily titled the method “Placeholder”, because we don’t want it to stick around. We’re actively hoping to replace it with something less centralized.

   So they still haven’t actually solved the core problem they set out to solve… are they going to resolve DIDs by talking to a centralized service? I suppose they thought since DID has the word “decentralized” in it, that’s good enough to move forward.

   This is not inspiring confidence.

   • ぐぬ管 (GNU social JP管理人), 寮 and arcanicanis like this.
   • ぐぬ管 (GNU social JP管理人) repeated this.
   • Embed this notice
     Matty (matty@nicecrew.digital)'s status on Friday, 28-Oct-2022 06:51:45 JST Matty

     in reply to
     Yeah Alex but if you call it decentralized but use a centralized identity server it's still decentralized if you ignore the centralization.
     Alex Gleason likes this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 06:52:43 JST Alex Gleason

     in reply to

     • Platinum
     I haven't seen a good movie in years because they're all shitty remakes. So, Scream 2?
   • Embed this notice
     Platinum (platinum@nicecrew.digital)'s status on Friday, 28-Oct-2022 06:52:46 JST Platinum

     in reply to
     that's boring
     
     name the last good movie you saw
   • Embed this notice
     Curtis Rock, SkD (curtis@social.teci.world)'s status on Friday, 28-Oct-2022 06:57:53 JST Curtis Rock, SkD

     in reply to

     https://www.w3.org/TR/did-core/

     Alex Gleason likes this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 06:58:43 JST Alex Gleason

     in reply to

     • Curtis Rock, SkD
     That's in theory what the spec author wants it to do. But if you take a look at the list of DID methods: https://w3c.github.io/did-spec-registries/#did-methods
     
     ...they don't all fulfill that promise!
     ぐぬ管 (GNU social JP管理人) likes this.
   • Embed this notice
     Curtis Rock, SkD (curtis@social.teci.world)'s status on Friday, 28-Oct-2022 06:58:44 JST Curtis Rock, SkD

     in reply to

     Here’s the DID use case

     the design enables the controller of a DID to prove control over it without requiring permission from any other party

   • Embed this notice
     Hoss Delgado (hoss@shitpost.cloud)'s status on Friday, 28-Oct-2022 06:59:03 JST Hoss Delgado

     in reply to
     >We’re actively hoping to replace it with something less centralized.
     Yeah that's never happening.
     Alex Gleason likes this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 07:01:51 JST Alex Gleason

     in reply to
     What the FUCK is this?? https://did-did.spruceid.com/
     
     Surely a joke.
   • Embed this notice
     Hyolobrikator (hyolobrika@gleasonator.com)'s status on Friday, 28-Oct-2022 07:03:13 JST Hyolobrikator

     in reply to

     • Curtis Rock, SkD
     >they don't all
     that gives people choice
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 07:03:13 JST Alex Gleason

     in reply to

     • Hyolobrikator
     • Curtis Rock, SkD
     Except that bluesky will only accept one or two.
     
     If we end up having to adopt ATProtocol, at least we can add an ActivityPub DID like `did:ap:https://gleasonator.com/users/alex`
   • Embed this notice
     King Henry VIII (goodperson@nicecrew.digital)'s status on Friday, 28-Oct-2022 07:12:00 JST King Henry VIII

     in reply to
     NGL that is pretty funny
     Alex Gleason likes this.
   • Embed this notice
     Neko McCatface v2023 :verified::makemeneko: (roboneko@bae.st)'s status on Friday, 28-Oct-2022 07:21:00 JST Neko McCatface v2023 :verified::makemeneko:

     in reply to

     • Curtis Rock, SkD
     @curtis that's just a public key tho :think_bread: how is that usecase different from "onion address with alternative string representation and 87 pages of extra steps"?
     
     @alex any idea what specifically they are trying to solve with this that asymmetric key pairs don't?
     
     autonomous proof - asymmetric crypto
     
     nomadic identity - cross signing, revocation, etc
     
     DID - ??????
     Alex Gleason and arcanicanis like this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 07:24:34 JST Alex Gleason

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • Curtis Rock, SkD

     Yeah, I’m surprised that did:ed25519:... is not already a thing… that would be extremely obvious.

     According to Bluesky this is unacceptable because if your private key got leaked there’s no way to recover from that. All crypto-backed DIDs have the same problem.

   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 07:30:24 JST Alex Gleason

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • Curtis Rock, SkD
     Also, a DID needs a resolver that can find information about you based on the DID alone. With the keypair example you're likely hitting MIT's keyserver to try to resolve it, or Keybase or whatever.
     
     The good thing about ActivityPub IDs is that you can easily resolve them from the ID alone, since they're URLs. Most other solutions have us depending on centralized servers, or reinventing DNS. IPFS seems like it would work well for this, if it wasn't extremely slow.
   • Embed this notice
     Miss Pasture :monapat: (pasture@pl.gamers.exposed)'s status on Friday, 28-Oct-2022 07:31:38 JST Miss Pasture :monapat:

     in reply to
     @alex I read this when it came out however many weeks ago and concluded that it was the product of autism + activitypub + javascript
     Alex Gleason likes this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 07:32:14 JST Alex Gleason

     in reply to

     • Miss Pasture :monapat:

     autism + activitypub

     You mean even more than it already was?

   • Embed this notice
     Neko McCatface v2023 :verified::makemeneko: (roboneko@bae.st)'s status on Friday, 28-Oct-2022 07:32:37 JST Neko McCatface v2023 :verified::makemeneko:

     in reply to

     • Hyolobrikator
     • Curtis Rock, SkD
     @alex yeah I'm not seeing how you can avoid that issue at the level of the underlying primitive itself
     
     what you *could* do though is address it at a higher level. matrix kind of sort of almost does this. when you have multiple keys and they cross sign each other then you've got your own little web of trust. and you can put one of them on a hardware token and stick that in a safety deposit box or something if you want
     
     there was also a framework or spec (???) for software updates that did something like that. I can't remember what it was called sorry
     
     @curtis @Hyolobrika
     Alex Gleason likes this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 07:34:59 JST Alex Gleason

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • Hyolobrikator
     • Curtis Rock, SkD
     • Josh Adams

     keys that cross-sign each other

     I need @josh to see this thread.

   • Embed this notice
     Curtis Rock, SkD (curtis@social.teci.world)'s status on Friday, 28-Oct-2022 07:40:40 JST Curtis Rock, SkD

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:

     talltree was right in the middle of the DID resolving vs dereferencing discussion in 2019

     https://github.com/w3c-ccg/did-spec/issues/166#issuecomment-464502719

     Alex Gleason likes this.
   • Embed this notice
     Neko McCatface v2023 :verified::makemeneko: (roboneko@bae.st)'s status on Friday, 28-Oct-2022 07:42:02 JST Neko McCatface v2023 :verified::makemeneko:

     in reply to

     • Curtis Rock, SkD
     @alex @curtis
     
     > Also, a DID needs a resolver that can find information about you based on the DID alone. With the keypair example you're likely hitting MIT's keyserver to try to resolve it, or Keybase or whatever.
     
     I'd argue that's a separate concern. different task. whatever. onion, GNS, DNS, and a keyserver are all different solutions to it
     
     >The good thing about ActivityPub IDs is that you can easily resolve them from the ID alone, since they're URLs.
     
     :02_laugh: nigga please. that's just using an ICANT sanctioned URL and pretending it's suitable as an ID. the "real" ID is the server key. much grief has come of these two things being hopelessly conflated by current AP implementations
     
     > Most other solutions have us depending on centralized servers, or reinventing DNS.
     
     ... fedi is hopeless dependent on ICANT DNS at present. if your domain gets pulled what are you going to do?
     
     > IPFS seems like it would work well for this, if it wasn't extremely slow.
     
     exactly, what does DID do that an IPNS record doesn't? that combines keypair with decentralized name resolution. of course tor .onion also do the exact same thing ...
     Alex Gleason likes this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Friday, 28-Oct-2022 07:46:39 JST Alex Gleason

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • Curtis Rock, SkD
     We need to just let people federate over blockchain domains and Tor.
   • Embed this notice
     Curtis Rock, SkD (curtis@social.teci.world)'s status on Friday, 28-Oct-2022 07:55:07 JST Curtis Rock, SkD

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:

     It’s time to put the use case chart on the wall to solve this equation for all variables

   • Embed this notice
     Store-Brand Pikachu (pcachu@shitposter.club)'s status on Friday, 28-Oct-2022 08:11:17 JST Store-Brand Pikachu

     in reply to
     @alex oh goody, cargo cult protocol design. if we name it right it will totally fulfill its name! eventually! maybe! fuck if we know!
     Alex Gleason likes this.
   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Friday, 28-Oct-2022 09:52:03 JST arcanicanis

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • Curtis Rock, SkD
     Actually the spec has a 'recoveryKey' component as well for did:plc of which:
     > "(...) provides a 72hr window during which the recoveryKey can "rewrite" history.
     > This is to be used in adversarial situations in which a user's signingKey leaks or is being held by some custodian who turns out to be a bad actor."
     ( https://atproto.com/specs/did-plc#account-recovery )
     
     Which seems like a pretty simple implementation, without cross-signing or any other ideas to be piled on to achieve the same.
     
     Also, I think the idea is that there's a different primary identifier (the DNS-style usernames), which resolves and points to the DID as it's canonical identifier.
   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Friday, 28-Oct-2022 09:53:33 JST arcanicanis

     in reply to

     • Neko McCatface v2023 :verified::makemeneko:
     • Curtis Rock, SkD

     Actually the spec has a ‘recoveryKey’ component as well for did:plc of which:

     “(…) provides a 72hr window during which the recoveryKey can “rewrite” history. This is to be used in adversarial situations in which a user’s signingKey leaks or is being held by some custodian who turns out to be a bad actor.” ( https://atproto.com/specs/did-plc#account-recovery )

     Which seems like a pretty simple implementation, without cross-signing or any other ideas to be piled on to achieve the same.

     Also, I think the idea is that there’s a different primary identifier (the DNS-style usernames), which resolves and points to the DID as it’s canonical identifier.