@arcanicanis@silverpill@bnewbold@erlend sadly there isn't much support for DID URLs in the wild, as that whole set of features is optional and few DID method specifications even mention (whether mandatory or optional) how implementations could dereference DID URLs... I would mention that one of the formal objections complained about this unspecified behavior and thus the DID WG has prioritized the DID Resolution spec, which might help a little: https://w3c.github.io/did-resolution/#dereferencing
I stole a few ideas from did:plc and did:tdw, yes. It's just an experiment insofar, as I'm using it as a stand-in for other methods, as something I can adjust to my needs as I toy with DIDs in a way with reverse-compatibility to standard non-DID ActivityPub.
As it currently stands, there doesn't seem to be a lot of methods that clarify whether DID URLs are permitted or not with the method.
There were a few adjustments I was going to add, such as what other 'authoritative' servers the did:fedi can be discovered from, within the method-specific protocol, maybe.
Either way, I haven't been public about it yet. Just finished a basic key wrapping and serialization format to go along with it, and I'll probably push out a newer version of the generator demo (which presently lacks a polyfill for browsers that don't have native Ed25519 within WebCrypto) in a day or two. I'll probably be more vocal when I have results.
As for the primer, that was probably over a year ago, and the mentioned FEPs, even a year before that (with all those FEPs devised by @silverpill )
I have been reading parts of the DID Resolution spec, yes. There are some inconsistencies I noticed when trying to sorta-implement it, such as the example for "8. DID URL Dereferencing Result" whereas it has didUrlDereferencingMetadata while the current JSON-LD context (which is https://w3id.org/did-resolution/v1 which redirects to a broken URL of https://w3c-ccg.github.io/did-resolution/contexts/did-resolution-v1.json, when I think it's instead meant to go to https://w3c.github.io/did-resolution/contexts/did-resolution-v1.json) defines a property name of dereferencingMetadata instead; or also relative-ref instead of relativeRef in some of the diagrams.
There had been light inferences about using DID URLs for binary content, but it's difficult to see the application of it, when most of it comes to returning a JSON resolution/dereferencing metadata document as an envelope. There's no mention of anything with content negotiation, like if there was a mechanism where: a DID-aware application could ask for the JSON info on resolution, or else, a non-DID-aware application (that doesn't list DID resolution media type in the 'Accept' header) could just be redirected to the dereferenced binary file instead.
There also doesn't seem to be much for options with simply pointing to the location of the resource, rather than embedding the resulting document directly.
I've generally tried just 'making up' some makeshift extensions to fill the gaps in my use-case, and might have some results within a week-ish (I have a resolver implemented with DID URL dereferencing, I just need to make further client-facing changes). There could also be a chance that I might have skipped over something important that might address my complaints, as I'm usually skimming through fragments of all the miscellaneous specs at a time.