Creating a space for discussion for the recent post:
8 Likes
Awesome, thanks @ngerakines.me
I moved it to WG Private Data – which I think I do need to capitulate and rename to “Private & Permissioned Data” 
Really great write up, thanks for putting the time into this.
5 Likes
Hi Nick,
Thank you for this write up!
By “applications,” I mean more than just the PDS. It includes the PDS that stores the data, the AppView that displays it, and any relay or indexer involved. Every application in this chain is part of the trust relationship.
Could you please clarify whether applications includes Ozone, and whether an ozone instance ran by the same service provider of the PDS would also be able to see the contents of permissioned data?
1 Like
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!
2 Likes