Re: Bluesky spins out an entity for did:plc

I mean, you could cram all the DID properties into an Actor document, but that doesn't necessarily mean you _should_.

did:ap or did:activitypub would just introduce yet another resolution method for discovering the Actor document, on top of 
webfinger and similar. It'd probably be better to just use did:web or did:webvh and have the DID document served 
separately from the Actor document.

It's kinda like how people tried to cram absolutely everything into the webid documents in solid.

Just because you can, doesn't mean it's a good idea.

— Emelia

> On 20 Sep 2025, at 20:43, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> 
> 
> so 20. 9. 2025 v 2:39 odesílatel emelia <emelia@brandedcode.com <mailto:emelia@brandedcode.com>> napsal:
>> What would the theoretical syntax for `did:activitypub` be Melvin?
>> 
>> I've been playing with `did:web` to reasonable success, e.g., `did:web:example.princess.works` works in 
>> my little side project experimenting with AT Proto style OAuth:
>> https://github.com/ThisIsMissEm/activitypds/
>> 
>> (assuming there's a user `example` on the server and `princess.works` is the handle domain)
>> 
>> For a `did:activitypub` the question is what would come after that? The URI to the actor document? A webfinger address?
>> 
>> Would it perhaps be: 
>> - `did:activitypub:hachyderm.io/users/thisismissem` <http://hachyderm.io/users/thisismissem>
>> - `did:activitypub:hachyderm.io <http://hachyderm.io/>?username=thisismissem`
>> 
>> I'm not sure those are much simpler than `did:web`, and you're just shifting the implementation code from 
>> the server to the client by going the custom did method here.
> 
> Nice work, Emelia, adding OAuth there is a cool idea. I think you’re along the right lines; there’s some wiggle room in syntax, but a generic form could end up looking something like:
> 
> did:ap:<host>:<user>
> 
> One aspect is that unlike did:web, no did.json would be needed since the Actor JSON is already there. Definitely something we could explore further.
>  
>> 
>> Yours,
>> Emelia
>> 
>>> On 19 Sep 2025, at 23:27, Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>>> 
>>> pá 19. 9. 2025 v 22:37 odesílatel a <a@trwnh.com <mailto:a@trwnh.com>> napsal:
>>>> >  FYI: both bluesky and nostr now have did methods, each with millions of users, interoperable using w3c standards.
>>>> 
>>>> What does "interoperable" mean here?
>>> 
>>> It means different systems can talk to each other using the same data model and vocabulary, like how ActivityPub lets diverse servers interoperate.
>>>  
>>>> 
>>>> >  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.
>>>  
>> 
>