Initial atomic data was purely HTTP based, which also mean we often had nice, clean, human-readable URLs.
https://example.com/people/joep
But now we're migrating to did identifiers. Great that they rely on cryptography instead of trust, but they look like gibberish:
did:ad:awidonwaunsbg389n82n3tn1891
So would we still be able to share our did resources with a nice human-readable URL? Well, yeah I think we should.
We could introduce a new special path property, which we check for drive-scoped uniqueness, and we use that to resolve using HTTP.
If a user opens example.com/people/joep we find the path property and resolve it to the resource.
However, note that this requires one drive per domain. We could also add a drive-specific namespace in front of the path, or we could use a subdomain.
Initial atomic data was purely HTTP based, which also mean we often had nice, clean, human-readable URLs.
https://example.com/people/joepBut now we're migrating to
dididentifiers. Great that they rely on cryptography instead of trust, but they look like gibberish:did:ad:awidonwaunsbg389n82n3tn1891So would we still be able to share our did resources with a nice human-readable URL? Well, yeah I think we should.
We could introduce a new special
pathproperty, which we check for drive-scoped uniqueness, and we use that to resolve using HTTP.If a user opens
example.com/people/joepwe find thepathproperty and resolve it to the resource.However, note that this requires one drive per domain. We could also add a drive-specific namespace in front of the path, or we could use a subdomain.