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 serious discussion for the AT-URI becoming compliant with URI standards. Revising the AT-URI spec to officially be a compliant URI opens the doors to fragments and queries that will spawn a wide range of possibilities that are not dependent initially on a lexicon’s existence yet alone availability. It’s two things that need to be shared instead of a single URI.
We should also consider the DID spec for fragments and queries in the conversation. It could lead to a set of “reserved” fragment/query names in a AT-URI used for looking up signatures, services, etc in the DID. For instance, one could conceive that “?service=” would be reserved to lookup a specific service entry point that hosts the record. For legacy AT-URIs, the non-existence could default to “?service=atproto”
As you noted in the Bluesky thread, to be URI compliant, the DID would need to be encoded. That is the logical architectural decision and the most problematic for existing/legacy systems. but not insurmountable. Libraries could be updated to encode/decode on transmission. For instance:
at://did%3Aplc%3Aw4xbfzo7kqfes5zb7r6qv3rw/app.bsky.feed.post/3me5kw5txns2c?service=atgated_pds
Perhaps, “at://” will become another thing web browsers adopt alongside “http/s”. Or, perhaps it spawns a new generation of browsers. The power lies in the URI standard IMO.
Anyway, I always appreciate reading your insights and thoughts, not to mention your contributions to atproto!