bumblefudge

@gandalf_der_12te@discuss.tchncs.de haha i think that was a typo i meant normal dereferencing (which is admittedly already an annoying term of Semantic Web art that I only use to help people bashing their head against these specs for the first time). plainly speaking, a “web-based DID” (any of the did:web successors linked above) gives you rules for translating, e.g., did:webvh:bumblefudge.com:1234 into https://bumblefudge.com/1234/.well-known/did.json – you can just make that second string into the id property of an actor, and put a normal AP actor object in the file you get back at that URL and for the AP world (that doesn’t have to know or care what a DID is) that’s just… an Actor. The controller of that Actor can use the the first string in DID-based system, if those ever exist at scale. To date, the only pertinent place you can use a DID but not an Actor ID is in… an At Protocol URI, i.e. at://did:webvh:1234/lexicon/recordkey (sidenote, yes, those colons are invalid, dropping the did:and inverting the rest of the authority to 1234:didwebvh would be a more conformant URI)

Anyways, hope that’s helpful to whatever research and/or design you’re doing, I’ve probably ranted enough for one thread :sweat_smile:

See also FEP-e3e9 on DID-like redereferencing from an HTTP server of actor objects-that-are-also-DID-docs

using a did:… as an actor.id prop is a little spicy and isn’t exactly backwards compatible with the entirely HTTPS-based fediverse, BUT all web-based did methods in their respective ways (did:web, did:webvh, did:webplus, and even did:plc if you squint a little and hardcode the discovery path to a document cache like plc.directory or a custom resolver like pdsls.dev) let you express a DID not just as a did string but also as a normal URL that dereferences to a DID document that is also a conformant/valid Actor object. if the server does con-neg and returns the actor object as JSON-LD (or debatably even if it ignores con-neg and just already serves a JSON-LD did doc without the appropriate content-type header) then… you just dereferenced an actor conformantly even though what you got back was a “DID Document” in addition to being an actor object.