Content-addressing and URN resolution

ActivityPub
2

RDF 1.1 Concepts section on skolemization mentions the genid well-known IRI:

Systems that want Skolem IRIs to be recognizable outside of the system boundaries SHOULD use a well-known IRI [RFC5785] with the registered name genid . This is an IRI that uses the HTTP or HTTPS scheme, or another scheme that has been specified to use well-known IRIs; and whose path component starts with /.well-known/genid/ .

For example, the authority responsible for the domain example.com could mint the following recognizable Skolem IRI:

http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6

I could imagine exploiting this well-known endpoint to address ERIS URNs:

https://openEngiadina.example/.well-known/genid/urn:erisx2:AAADAF4BGFGNTYG65ZX3JW7A75VBCMRWN7B2WGIQ7PAQGBHOKYGMRESC2QZVSBDYW5P45R6FRRPBZYGZ5H6XTWSNR6HEXKOD735UG3B7IQ

This would avoid having to provide a template such as WebFinger, to register a new well-known IRI or to use uri-lists. Any conformant server could have such URI and send the decoded version of the URN.

This way, the simplest solution would be for implementations to try this on the origin server if they do not implement ERIS URN resolution locally, or use their own.

Of course that does not solve the problem if the activity is received from a server that did not dereference it and simply forwards it, and does not support ERIS.

There MAY be a known service that will implement this, but it would kind of re-centralize the service. E.g., we could agree to host a URN to URI resolver at a known URL, but the idea makes me shiver. What’s the point of using content-addressing if it is to fall back to a single domain?

Other resources might be useful:

Another idea would be to use the URN as the identifier, and use AlsoKnownAs for the URI (maybe the genid).

1 Like