Discussion: Implementation-specific prefixes for DSNP URIs

[wilwade]

• How should DSNP URIs be handled across implementations?
• Current Ideas:
  • Prefixing DSNP Ids
    • Wouldn't do. These are for internal use.
  • Prefixing DSNP User URIs
    • If a DSNP Id in an implementation is just a u64. Instead of using the u64 we might use something like these:
      • [impl]:[u64] frqcy:12345 or frqcy/12345
      • [prefix][id] 90/12345
    • In this case if we did DIDs, they might end up with one of the following:
    • did:dsnp:frqcy/12345 (dsnp resolver)
    • did:dsnp-frqcy:12345 (dsnp frequency resolver)
    • did:frqcy:12345 (frequency resolver only)
  • Prefixing DSNP Content URIs
  • Use the DSNP User URI as a base. See above.

General Thoughts

• User Ids and Content Hashes are "INTERNAL"
• URIs are "EXTERNAL"

Open Questions

• Would these need to be used internally or just in some interchange setup?
• How would the Graph work? It wants to use internal data structures, but users might want to reference external.

[wesbiggs]

DID methods unfortunately don't allow non-alphanumeric values, so the did:dsnp-frqcy:12345 example would have to be did:dsnpfrqcy:12345.

[wesbiggs]

Noting here that the current graph design (#233) uses internal User Ids (64-bit) only. However, different schema (using DIDs or URIs generally) to represent external or inter-implementation graphs could be used for additional user data types e.g. externalConnections, so I think this is the right approach to optimize for the immediate use case without ruling out the possibility of future interop.

[wilwade]

Archive