I vote for ats://; I should be able to identify a permissioned space uri at a glance.
7 Likes
I keep forgetting to leave my thoughts here. In part because I think others have already mentioned the big arguments (I’ll try to not repeat those too much) and in part because I have been, and somewhat remain, indecisive about what I think. Currently I’m leaning mostly towards the ats crowd. I think the biggest arguments here are about the differences in data structure and authority between the two kinds of data.
Permissioned data and public data are two quite separate things. Sync is one argument but I agree with Daniel here that one of the beauties of at as a scheme is that it’s a little CID like in how it identifies a “what”, a specific record from a specific user, moreso than a “how to get it”. And a permissioned data is quite similar there. However I still also think that, the fact that, permissioned data involves two authorities who both hold power is very significant! and makes the semantics of the two quite different. In a sense I almost want to respond to
with “using the same scheme dilutes the at-uri idea just as much if not more”. In some sense the idea of an at URI and it’s semantics is a promise about user control. A promise that isn’t held up in quite the same way for permissioned data because a bit of the control is relinquished to the space authority. Then again spaces are still incredibly “atmospheric” in design and do still have user control as a core pillar. But I do think the semantics a URI can promise about these two kinds of data are still very very different.
The branding argument is a pretty good reason in some ways to want to stick to one scheme. But at the same time I don’t think anyone would argue that anyone has a hard time considering both http and https as parts of “The World Wide Web”. atproto is a collection of technologies in much the same way the web is. Containing multiple URI schemes doesn’t do against that I’d say. Though separate schemes do push the idea and feel of “public data hosting” and “permissioned data hosting” being two different technologies under the atproto umbrella, rather than two halves of one “data hosting” technology under the atproto umbrella. As a last point on branding, being able to clearly differentiate the two, not just by length which can vary quite a lot with different DIDs, NSIDs, etc, but by literally the first thing I see is, I’d say, a branding based argument to split them.
At the end of the day I can see good arguments for both sides. I won’t hide that one reason I like ats is that it “feels” more right in my brain, separate semantics → separate scheme. Part of me can’t really shake the feeling that we might come to regret not being clearer about the semantic differences here. Whatever ends up being chosen in the end I can live with it just fine and I think technology can too.
5 Likes