[Proposal] AT-URI for cross-service records

[scott.nstar.social]

Great write-up and thank you for the insight. The artificial limitations imposed by a single-PDS per user is not practical for many of the reason’s you’ve stated above. We can’t expect a single PDS to scale to the services that will be invented in the coming years. Even if a single PDS could evolve to provide these future innovations, it would require ALL PDS providers to adopt innovations simultaneously for an app to be successful at capturing the existing user base. And in a reasonable timeframe. That, of course, will never happen.

We’re seeing people looking for workarounds for what the URI spec already successfully accomplishes. I mentioned the need for the AT-URI to come into compliance with the URI standards in this discussion:

Permissioned data is a love triangle

Thanks Nick! Thought I’d bring my concerns about adding a property to the lexicon here as the appropriate forum for discussion ;-). Hiding service awareness in a lexicon seems like a workaround that doesn’t need to exist. The URI standard has been the catalyst and backbone of the Internet. Their flexibility has spawned enormous innovation. And, I’d argue, AT-URI’s single most important contribution is user data portability – swapping the host with a DID is a clever “innovation”. We should give…

Adding a query parameter to the AT-URI would be compliant with URI and DID Document standards. You reference a DID service with the query ?service={service_name}. That is what we’ve adopted for NorthStar Social to be aligned with existing standards.

@boltless.me

We can append ?service={service_name} to blessed AT-URI syntax to qualify current full AT-URI syntax. But honestly I think using userinfo field of URI makes more sense:

"at://" [ SERVICE "@" ] AUTHORITY [ PATH ]

This addition of the DID document service to the AT-URI authority component would further deviate from URI (and DID document) standards. The @ is already reserved for user information (username:password) with specific implementations in URI parsers. I’d rather see the URI standard adopt DIDs in the authority with the emergence of a “DNS” for DID lookup (something greater than the PLC directory). This makes more sense since the authority can easily adopt the did:xxx:abcd.. in place of hostname/ip:port without much headache for parsers to adopt universally. Two colons vs one colon. A URI compliant workaround without such a standard would be encoding the DID colons in the AT-URI.