Re: Bluesky spins out an entity for did:plc

so 20. 9. 2025 v 0:33 odesílatel Ryan Barrett <public@ryanb.org> napsal:

> On Fri, Sep 19, 2025 at 2:28 PM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>> >  FYI: both bluesky and nostr now have did methods, each with millions
>>> of users, interoperable using w3c standards.
>>>
>> It means different systems can talk to each other using the same data
>> model and vocabulary, like how ActivityPub lets diverse servers
>> interoperate.
>>
>
> Technically true!...but needs a massive caveat: in practice the "same data
> model and vocabulary" here are tiny subsets of data. did:nostr has
> id/handle, keys, servers (relays), profile info, and in the maximalist
> case, follows. (Which is exciting!) Bluesky did:plc and did:web have much
> less, just id/handle, keys, and server (PDS).
>
> In both cases, the vast majority of the *data* on each network -
> followers, posts, likes, reposts, and Bluesky profiles and follows - are
> not in the DID docs. Which is ok! DID docs don't need to do everything or
> contain all data to support interop. We can be realistic about how much
> DIDs alone get us, and still appreciate them as a useful improvement.
>
> (did:activitypub is still obviously speculative at this point, but the
> proposals I've seen are roughly evenly split between Webfinger-based, which
> would be a very minimalist approach similar to Bluesky's, and AS2 actor
> based, which would be much more of the complete profile, but still nothing
> beyond that.)
>

Thanks Ryan, really appreciate the thoughtful caveat. I also find it
exciting, as you say, that even a generic “follows” in a social graph can
be represented. Some data naturally belongs in the DID document, while
other data is better linked externally. With ActivityPub, the nice thing is
that what is in the Actor object is deterministic and already published, so
a did:activitypub could be zero-config for servers. The DID document then
serves as a minimal glue, able to bridge all the open social network
protocols together.

Would love to hear more about different proposals, too.


>
>
>
>>
>>>
>>> >  We could possibly spin up a simple ActivityPub method, along the
>>> lines of did:web so something like did:ap or did:activitypub
>>>
>>> How would this did:activitypub differ from did:web, or https:?
>>>
>>
>> https:
>> Just a URL. No DID semantics.
>>
>> did:web:
>> Generic DID: needs a did.json hosted at the domain.
>>
>> did:activitypub:
>> Specialized DID: no did.json needed, just reuses the existing ActivityPub
>> Actor JSON (public key, inbox/outbox) as the DID document.
>>
>> Difference: did:activitypub is zero-config for Fediverse accounts.
>>
>>
>
>
> --
> https://snarfed.org/
>