search

TBD54566975 / did-nostr

35 stars 8 forks source link

use absolute URIs instead of relative URIs #5

Closed mistermoe closed 1 year ago

mistermoe commented 1 year ago

suggestion made by @melvincarvalho

image
mistermoe commented 1 year ago

Relative DID URI section in did-core spec

image
csuwildcat commented 1 year ago

I'm not sure why one would be unnecessarily verbose here and not just follow the spec for relative URIs. It's well-defined behavior, so I don't see a reason to bloat these documents.

melvincarvalho commented 1 year ago

@mistermoe, thank you for referencing this

Typically, I would suggest using relative #hash URIs as they can aid with portability and save a few characters. However, in the case of DID documents, there are already a lot of characters present. The # identifier will be unique regardless, so portability never comes into play, and the processor will need to expand it, anyway.

Unfortunately, this is one aspect of the DID Core specification that is somewhat unclear. When I raised a concern regarding the clarification of the document, base, type, controller, and subject, the response was an even messier diagram.

image

The idea is to determine the base of the document out of band and add it as a prefix to the fragment. However, this approach ignores the fact that the base can be ambiguous or change on the web. It's a hack at best and an anti-pattern at worst.

The DID method used by Nostr can avoid this issue by being explicit. It's important for Nostr to have well-designed, clean identifiers that provide an advantage in scaling.

metacatdud commented 1 year ago

@melvincarvalho

Man, this is disarmingly complex (not what is in this repo, but the w3 org specs in general). I seriously wonder (and question for that matter) if whoever came up with this complexity built these based on real-life, hands-on experiences.

I am not trying to be dismissive in any way here, but I am just wondering if this entire thing is worth the trouble. Seem like a lot of head ake and whoever will want to build (even with this simplified version you are trying to design) for various languages will have to understand "the why".

IDK, maybe I am short-sighted and I can't see the big picture, but I refuse to believe there isn't a simple way.

Going over the diagram above is clear to me that whoever started this entire specification forgot where they left off and forgot where they are going.