Post An2iK9A2X0Az2bk7nc by arcanicanis@were.social
(DIR) More posts by arcanicanis@were.social
(DIR) Post #AmqltEYaLJDbkBFQQK by erlend@writing.exchange
2024-10-09T23:08:08Z
1 likes, 0 repeats
@bnewbold.net @bnewbold you’re looking for @arcanicanis
(DIR) Post #AmqltG0yvDWkGXXcK8 by arcanicanis@were.social
2024-10-10T03:05:03.673147Z
0 likes, 0 repeats
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 )
(DIR) Post #An2g7xOGGiH79TSFe4 by by_caballero@mastodon.social
2024-10-15T18:05:54Z
0 likes, 0 repeats
@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
(DIR) Post #An2g7yYZvq7cllI0Mi by by_caballero@mastodon.social
2024-10-15T18:07:14Z
1 likes, 0 repeats
@arcanicanis @silverpill @bnewbold @erlend One useful piece of prior art to look at would be did:cheqd, both the method and the production implementation (and maybe even the veramo plug-in!). the cheqd team has really been driving a lot of the effort to do something grown-up with DID URLs in prod and in standardized ways...https://docs.cheqd.io/product/sdk/veramo-plugin/did-linked-resources
(DIR) Post #An2g80Q90AZ0YBMIUq by by_caballero@mastodon.social
2024-10-15T18:13:13Z
1 likes, 0 repeats
@arcanicanis @silverpill @bnewbold @erlend FEP-e3e9 snuck in "DID URL syntax" to a standalone "permalink service", such that everything after the ? would model what a DID-URL permalink for nomadic content could look like; what comes before the ? is a traditional HTTPS URL in the FEP, but could also be a gateway that takes a DID as a path... (i.e. https://indexer.example/did/plc/53ogl5ixuq44t73wuqawpa33?...)
(DIR) Post #An2iK9A2X0Az2bk7nc by arcanicanis@were.social
2024-10-15T21:21:45.454299Z
0 likes, 0 repeats
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 I guess relative-ref 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. 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.
(DIR) Post #AnEPdTlCbIwdCO9JkO by bnewbold@social.coop
2024-10-21T04:50:58Z
0 likes, 0 repeats
@arcanicanis @by_caballero @silverpill @erlend (glad to re-connect!)i'm not sure I understand the advantage of leaning in to DID URLs instead of creating a new URI scheme (eg, fedi://).it would be great if we could get WHATWG to allow DIDs in the authority section of URLs, at least non-HTTP URLs. I haven't started that conversation yet, but could be helpful for a bunch of DID-using projects.curious to hear about how did:fedi resolution would work! aka how to discover authoritative server
(DIR) Post #AnEPdUquXZ6aaNpOHg by silverpill@mitra.social
2024-10-21T12:48:24.070766Z
0 likes, 0 repeats
@bnewbold There is no advantage in using DID URLs. That severely limits the number of DID methods developers can use, and excludes the most important method, did:key.You're right, new URI scheme is much better. This approach is being explored in FEP-ef61 (where ap:// scheme was proposed).ActivityPub IDs are RFC-3986 URIs, and that RFC doesn't forbid non-DNS naming authorities (idk about WHATWG standard). However, you can't build a valid RFC-3986 URI with plain DID because the portion after the last colon is parsed as a port number. Two solutions has been proposed:- Percent encode DID: ap://did%3Akey%3Az6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2/actor- Pretend that we are using IP address from the future: ap://[vd.did:key:z6MkvUie7gDQugJmyDQQPhMCCBfKJo7aGvzQYF2BqvFvdwx6]/actor@arcanicanis @by_caballero @erlend
(DIR) Post #AnEQuDMAwTizCVzGWu by silverpill@mitra.social
2024-10-21T13:02:44.572812Z
0 likes, 0 repeats
@bnewbold Of course, a new syntax for DID authorities would be preferableap://{did:key:z6MkvUie7gDQugJmyDQQPhMCCBfKJo7aGvzQYF2BqvFvdwx6}/actorBut standardization of it may take many years. And after that people will need to update all existing URI/URL parsing libraries and software that depends on them.@arcanicanis @by_caballero @erlend
(DIR) Post #AnEzugI8rM2jKw3gbQ by by_caballero@mastodon.social
2024-10-21T18:46:33Z
0 likes, 0 repeats
@silverpill @arcanicanis @erlend @bnewbold why is support for more did methods an assumed goal? for whom and in which use cases is a non http protocol handler justified? why is did:key important? why is ap:// the best possible url scheme for the AP protocol? it feels like we're talking at a general level and yet so many usecase-specific requirements and goals keep sneaking in
(DIR) Post #AnEzuh5lspk3orHJxY by silverpill@mitra.social
2024-10-21T19:34:54.995246Z
0 likes, 0 repeats
@by_caballero>why is support for more did methods an assumed goal?Because extensibility is good. New DID methods are constantly being invented and there shouldn't be any artificial restrictions on their use.>for whom and in which use cases is a non http protocol handler justified?In an 'http' URL, the authority is derived from the domain name. In our case, authority is derived from a cryptographic identity, so a custom URI scheme is more appropriate.>why is did:key important?did:key doesn't depend on any external services and is the easiest to implement.>why is ap: the best possible url scheme for the AP protocol?It works and so far no other scheme has been proposed.@erlend @bnewbold @arcanicanis