Post

Evelyn
@kandake.africa

It breaks the protocol in a way as yhen every developer needs to define a new set of lexicons that would structurally be identical.

Jack
@jackvalinsky.com

so the idea is that a if it's under a different uri than you can reuse lexicons but it resolves the data differently?

Jack
@jackvalinsky.com

I'm assuming that adding a new uri also introduces new headaches for the working group/people working on standards?

daniel holmgren 🫠
@dholms.at

well the particular rub here is that at-uris are in scope for the ietf working group on at protocol. but permissioned data isn't in scope. so this awkwardly straddles the line if we're trying to tack something onto the uri format while the working group is actively trying to standardize it

Jack
@jackvalinsky.com

in case it got buried, I like Emelia's suggestion: at://<did>/<extension>/<nsid> where here <extension> is "space" or w/e to denote private data, avoids new uri or adding some kind of private type to the Lexicon type system

0 reposts6 likes

Jack
@jackvalinsky.com

if we have to do a new uri then sure at+<extension>:// is the clearest vs. something like ats:// (confusing b/c does the s mean secure like https??) or space:// (not even related to at:// at all) I worry about the implications of introducing a new uri so early witchsky.app/profile/did:...

Emelia@thisismissem.social

Right, which makes it even more the WGs responsibility to make sure our URI scheme works for multiple future needs, and doesn't lock us into one usage