Re: Bluesky spins out an entity for did:plc

I believe ActivityPub should not have its own DID method. Here's why:

   - *Multiple DID methods benefit the ecosystem.* The right choice is
   contextual and use-case specific - it's not something for which there
   should be a consensus. It's always been possible to use every DID method
   with ActivityPub, including did:web, did:webvh, did:plc, did:nostr, etc.
   - *We already have interoperability.* The claim that "all the networks
   would be interoperable via a common language" overlooks that these networks
   already are interoperable via a common language: URIs and DIDs. There is
   loose coupling between ActivityPub and the specific URI scheme, let alone
   the specific DID method.
   - *Existing solutions work well.* Several FEPs make use of various
   existing DID methods and did not need a did:activitypub method. Where we're
   tempted to make any new DID method, we should first define a DID trait
   instead so many DID methods can share and reuse semantics. (DID traits
   allow multiple methods to implement common functionality - see
   https://identity.foundation/did-traits/)
   - *Protocol-agnostic DIDs enable true SSO.* If we don't make
   protocol-specific DID methods, then end-users and their agents can manage
   one DID and use it across all these protocols. This is the best path
   forward - it's simpler, gives people the single sign-on experience they
   want, involves less spec work, and leaves DID method choices where they
   belong: with the end user.
   - *Cross-protocol compatibility already exists.* You can use your
   did:plc with ActivityPub. You can use your did:web with ATProto (unless it
   doesn't end in .arpa - though that restriction seems arbitrary). You can
   use your did:nostr or did:ebsi with ActivityPub too.
   - *ActivityPub should stay in its lane.* It's best for ActivityPub to
   provide a social layer for all DIDs rather than becoming a DID method
   itself. ActivityPub isn't a DID Method, and shouldn't be.
   - *We have the tooling already.* The alsoKnownAs property was defined
   with the same semantics in both AS2 and DID namespaces by a former SWICG
   chair specifically so that AP Actors and DID Documents could cross-link.
   That infrastructure is worth using.

*Recommendation:* Instead of creating did:activitypub, let's focus on
ensuring ActivityPub works seamlessly with existing DID methods and
continue building the interoperable, user-controlled identity layer we all
want.









On Sun, Sep 21, 2025 at 1:34 AM Juan Caballero <virtualofficehours@gmail.com>
wrote:

> (i think the portability use cases FEP, for all its weaknesses, covers
> some more use cases that any proposed did method design would score points
> by covering some of!)
>
>
> ------------------------------
> Juan Caballero, PhD.
> Freelance <https://www.caballerojuan.com> researcher, consultant, and
> free thinker
> Signal/whatsapp: +1 415-3101351
> Berlin-based: +49 1573 5994525, CET/UTC+2
> Native: English, Español; Functional: Deutsch, Français, Português
>
> On Sun, Sep 21, 2025, 10:32 AM Juan Caballero <
> virtualofficehours@gmail.com> wrote:
>
>> I would argue we're better off clarifying the use case for non-webfinger
>> discovery and seeing if the work of giving AP implementers (at minimum) a
>> new endpoint to implement for a new DID method helps that use case along
>> and justifies the upgrade.
>>
>> more generally tho, I like the idea! just learned long ago that did
>> methods are export formats for solutions to many (mostly implicit or
>> underanalyzed) usecases. prefer to have ground truth on which solutions
>> justify an upgrade
>>
>>
>> ------------------------------
>> Juan Caballero, PhD.
>> Freelance <https://www.caballerojuan.com> researcher, consultant, and
>> free thinker
>> Signal/whatsapp: +1 415-3101351
>> Berlin-based: +49 1573 5994525, CET/UTC+2
>> Native: English, Español; Functional: Deutsch, Français, Português
>>
>> On Sat, Sep 20, 2025, 9:55 PM Sarven Capadisli <info@csarven.ca> wrote:
>>
>>> On 2025-09-20 20:55, emelia wrote:
>>> > It's kinda like how people tried to cram absolutely everything into
>>> the
>>> > webid documents in solid.
>>>
>>> Kinda?
>>>
>>> Which people?
>>>
>>> Tried what?
>>>
>>> Absolutely everything refers to?
>>>
>>> As far as I know, there may be two relevant specifications to what you
>>> have in mind for your statement. If you had others in mind, please share:
>>>
>>> https://solidproject.org/TR/protocol
>>>
>>> https://solid.github.io/webid-profile/
>>>
>>> Can you point out where in those specs your claim is supported? Or are
>>> you referring to specific implementations or published documents?
>>>
>>> Are you bringing up some Solid/WebID history as if it proves your case,
>>> when the technologies and design choices differ? Because if so, that's
>>> perhaps kinda like a red herring?
>>>
>>> I'm not aware of Solid "people" trying to cram absolutely everything
>>> into a WebID document, but I'm all ears.
>>>
>>>  From experience, the vast majority of WebID documents use the WebID URI
>>> as the subject. Sure, there can be other statements where it's not (it
>>> is not forbidden), but pointing that out feels pedantic.
>>>
>>> Payloads and notifications in both Solid and ActivityPub often include
>>> auxiliary information in order to minimise network requests. Likewise,
>>> ActivityPub Activities frequently wrap the Object with considerable
>>> detail. Would you consider that to be "cramming everything" into the
>>> Activity? Or is it simply a design choice in linked data representation?
>>>
>>> "Linked data" people / connectionists do not see the world as binary.
>>> There is a spectrum of approaches to describing a resource, and in
>>> practice, that's just how the web tends to work.
>>>
>>> -Sarven
>>> https://csarven.ca/#i
>>>
>>