For public data URIs, the existing ‘at://’ syntax would be supported indefinitely (“MUST”) as a legacy format, so all the billions of existing records would be fully supported. In the new format, we can debate whether ‘public’ is the best word to use (maybe ‘repo’?). And there would be no urgency to specify or implement the public URI syntax.
For spaces, if we go with this syntax for the upcoming “beta” launch, we could avoid ever needing more than one syntax for space data. This new syntax also has some advantages: the ‘space’ part moves “to the left” and is more visually distinct, while still clearly being under the overall ‘at:’ namespace.
Basically the current ‘at://’ format would end up as a “v0” that is limited to public data references, and has syntax problems with the broader web ecosystem. The new “v1” format would be more general-purpose, visually expressive, and integrate better outside the atproto ecosystem.
We want to have strong confidence that the overall pattern makes sense and would likely be adopted for public URIs to make that commitment though. We have proposed this on the IETF WG mailing list (link), and that is the best place to leave formal feedback if you have it. But we are also looking for feedback here from the atmosphere developer ecosystem, if you are unwilling or uninterested in the IETF process.
Specific questions for feedback:
are folks willing to let go of the nice ‘at://’ prefix?
is it worth the disruption and friction of supporting two syntaxes (“valid URI” and “legacy non-URI”) indefinitely?
are there any firm counter-proposals waiting in the wings?
any strong aesthetic or conceptual objections to this new syntax?
So… I’m generally not a fan of the idea to replace or supersede the at:// syntax… But I don’t know how realistic it is to not do that. We can’t get rid of it completely, so like you say we would have to support both forever, so I’m not sure what this buys us, if new implementations of various things would likely still need to not only manually implement the at-URI handling, but implement two ways of it.
If we do go with this, I’d say at:/<account>/<collection>/<rkey> would be preferable to at:public imho, it’s shorter and more similar to the existing format, and it doesn’t feel like it conflicts with at:space/ for space URIs.
Yeah, I agree here, could make it best practice to move to at:/ going forward. It is definitely a bit weird to be so slightly different, but at the same time it scans better and avoids the need to decide between at:public, at:repo or something. at:space is fine and reads well, no issues there.
These proposals mean that from a web point of view, you discard all structure: you just get a path name with the value `space/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.board/self/did:plc:735r43lcgemuv2woqpvx3lso/my.bulletin.post/3mtiiz6ci6c2j` from the initial example.
That’s not terrible, just a bid sad.
Alternative proposal: use the `ats:/` protocol for spaces, and `atp:/` for public data.
I like the at:/ prefix and dislike the extra characters of overhead in the public and space disambiguators. I think it’s worth considering whether implementations could successfully distinguish at:/<account>/<collection>/<rkey> from at:/<space-account>/<space-collection>/<skey> and how this might be handled with simple precedence rules (perhaps collections could supersede space-collections).
My strong impression is that the at:// scheme’s nonconformance is pretty intractable. The impression I get is that there’s very little will to try to update all the URL parsers in the world to handle the 2+ : characters in the authority section.
What you’re describing here is, from the perspective of the WhatWG URI spec, a question of whether the path section is hierarchical or opaque.
A scheme which starts with a single slash, such as at:/, is considered hierarchical. If there is not a leading slash, ie at:public, then it is not hierarchical in the “standard path” sense.
(Just adding information, not stating any preference myself)
Now to actually state a preference: I do personally think there’s a benefit to upfront tagging the URI with public or space. In software I’ve been writing that handles public & spaces, I have found myself wishing for a way to cleanly disambiguate their codepaths, and a leading prefix is quite nice for it. It almost serves as a taint tag. I’ve been disinclined to suggest a separate URI scheme (eg ats://) as it suggests separate protocols, and I’m too icked out by a scheme combinator (eg at+space://) so this proposal appeals to me.
Whether bare (at:space) or with a slash (at:/space) I’m more indifferent about. I find the bare version nicer personally, but I’m not keyed up about it. And - this is all lightly stated personal preference.
This would be difficult to distinguish without resolving the collection to determine if it is a space. Alternatively, use one character like at:p/<account>/<collection>/<rkey> or at:s/<space-account>/<space-collection>/<skey>.
Looking into this further, it appears to me that an NSID can only be defined to have one type. A single NSID cannot be both a collection type and a space id, so these paths are already disambiguated. Tagging in the URI seems to purely be a convenience for developers, and I think developer experience should defer to user experience. I think it is bad UX for ATURI users to have to include “space” and “public” in their URIs only because it allows developers to avoid looking up an NSID.
I’m for it. I like the bare at:public and at:space prefixes followed by the slash-separated repeating triples. My gut reaction is that the second segment (public or space) is effectively an alias for parsing length which has nice functional feel.
Tentatively in favor of at:public and at:space as proposed. at:/did with no prefix I think is more confusing; looks too much like a typo of at:// to me.
(And yes we don’t need to agree on public right now but I will continue my ongoing campaign to point out we can totally make spaces public too so maybe I’m +1 for repo or something instead.)
i haven’t weighed in much on uri syntax and don’t have super strong opinions about it, but this seems like the nicest way forward so far (short of moving the whole world for at://), and doesn’t have any real problems i’ve seen. +1 from me.
also +1 on bikeshedding public a bit
lol @ at:hose, my hose.cam joke domain about to be legitimized
It’s kind of a shame to have to have a breaking change here but if it’s breaking, it should be obviously breaking. I think at:public/ and at:space/ are fine. Also is somewhat nice in that allows for extensions in the future (unlike an ats://).
Probably code only has to handle the final pathing with something like atUrl.replaceAtStart("at://", "at:public/") being required as a normalization step.
Wondering if we’re making a breaking change anyways, would it make sense to ban handles in the authority section?
this is probably the proposal so far i like the most! it keeps the two both combined yet easily distinguished. one thing ive disliked about the ats:// and ats:/ proposals is that they look too much like sftp, https, etc where the s almost always implies a degree of added encryption which isnt the case here. at:space neatly solves that for me.
i agree with others that if we go this route we should bikeshed at:public a bit more, since spaces can also be public access. at:firehose or at:hose make a lot of sense i think! since it highlights the actual main difference between the two models: distribution (and access control), i would throw in at:global as a maybe option too? not sure how i feel about it but i thought of it so have it for consideration.
i also really like that under this model you could view the whole thing more or less as at:<distribution + access specifier>/<record specifier>. in general i do like the idea of at-uris helping people see how the spaces and firehose models are actually quite conceptually similar (distributed key-value store) even if the details are quite different. this does that quite well i think. seconding liking how theyre visually distinct from soon-to-be legacy at-uris so confusion between the two is unlikely, whereas i could imagine at:/ leading to confusion since a single slash can be hard to notice sometimes.
as an aside i personally like to think of firehose data as conceptually belonging to an implicit, public access, collectively owned space. and following that model i had considered at:<record>/<space> as an option. where firehose distributed data would be at:<user did>/<collection>/<rkey>/firehose and spaces data would be at:<user did>/<collection>/<rkey>/<space did>/<space type>/<skey>, firehose being a name for that special case space thats distributed over the firehose. and this proposal is kind of a similar, almost inverted, variant on that.
My concern is that this implies that AT-URI’s can only be “public” or “space(s)”. That seems rather limiting. And, do these prefixes imply additional prefixes would be under some form of protocol governance committee? How does that help/hinder the innovation we’ve seen over the last few decades via flexibility of http/s URI specification.
The single most valuable innovation of the AT-URI’s specification is the definition of a portable identity (DID vs domain) as the “authority.” For local-first content, we’ve been modeling AT-URI’s for portability between domains (local, private, public). The “local” context doesn’t fit either paradigm.
I’d be in favor of at:/ for public and at:s/ for spaces, but if we’re doing at:public/ and at:space/ I am not sure of a reason why we can’t keep at:// for them?