Post

daniel holmgren 🫠
@dholms.at

(oh also `ats://` stands for "authenticated transfer spaces" not "secure", and the fact that it's so similar to something https is actually a downside to me. also it's not visually distinct enough from `at` imo)

tierney cyren
@bnb.im

definitely worried about consumer signaling. We finally taught them that the s in https means security, this could get confusing/misleading.

Lou
@loustella.com

Short for Authenticated Transfer NOT Secure? Because that seems like a great way to avoid "The S in BGP stands for Secure!" jokes if nothing else lmao

Joel Hill
@joelh.social

Without a deeper understanding of how different the protocol is from apt:// it seems really disconnected from what we are already using. Are people going to start using spaces:// for public stuff too because it’s easier than supporting two different schemas? Is this functionally apt2?

Zicklag
@zicklag.dev

I feel like space:// is a little too generic. Feels like we need the "at" in there somewhere. What about pat:// "permissioned authenticated transfer"?

daniel holmgren 🫠
@dholms.at

makes me think of the test i had to take in highschool lol hmmm "at" is so *slick*. and "space" gives me a similar feeling. tacking on letters onto "at" just feels a little clunky to me. i like psat/sat over pat fwiw

Paul Rohr
@pevohr.bsky.social

In your model, spaces are permissioned by definition, so only of those two words is necessary If "pat = permissioned authenticated transfer" is too stuttery for you, then definitely "sat" over "psat"

Paul Rohr@pevohr.bsky.social

Or "sat://" for "space-authenticated transfer" Also works as an in-joke for protocol nerds by evoking the differences between ftp vs. sftp vs. ftps

Jake Gold
@jacob.gold

SPACE COLON SLASH SLASH I'd definitely want my client to support ` ://` Haven't followed super closely but immediate reaction to seeing new URI scheme is that I don't want any new URI schemes if possible. Did you explain why at:// can't support spaces? Why it needs its own dedicated namespace?

Jake Gold
@jacob.gold

Ah great. I'm very excited that you guys are working on this and looking forward to hopefully building something on it eventually. Love the shout out. Thanks!

matt
@stavola.xyz

If we're going to go for longer names like space://, maybe atps:// for AT permissioned space?

Ezra🦋
@ezraboeth.com
Ezra🦋@ezraboeth.com

I feel like at+spc:// is the middle ground here. it's shorter than at+space:// and more clear than ats://, while still being intuitive

manoo
@manoo.dev

i vouch for this, I think it's clean and clear but you have to be 100% sure that the name "space" is gonna stick

DemigirlBOObs
@demigirlboss.win

It reads really clearly!! ats is like, fine, also, I guess, but spaces just instantly clocks as "oh yeah that's the URI for a permission space".

JP
@byjp.me

It feels pretty detached from at:// to me. I’d go with atps:// atsp:// at+s:// or even just sp://

Nick Gerakines
@ngerakines.me

I think it’s too generic. ats:// captures the incremental and additive vibe of spaces to (at)protocol. IMO it should be at+space because it’s still an AT-URI but with additional URI context. I think just keeping it at:// is best but I get the fear of breaking compatibility with current systems.

Laurens
@laurenshof.online

are spaces actually incremental/additive to atproto? like depending on where it goes i can actually see the value in positioning it explicitly as a different/separate protocol?

Lao
@lao.ooo

atsp sounds better because s at the end makes me think of secure, it's too close to https

Paul Rohr
@pevohr.bsky.social

Naive question -- say you have the following records: A. public record B. record in space P C. record in space Q Is it a design goal for references to any/all of them to coexist in the same record? Why? What are the semantics of crossing space boundaries like that?

Evelyn
@kandake.africa

It breaks the protocol in a way as yhen every developer needs to define a new set of lexicons that would structurally be identical.

daniel holmgren 🫠
@dholms.at

lexicons could be updated to be tolerant to use a string format that's tolerant to both at & space uris but yeah lexicon authors would then have the ability to basically decide if a record is meant for public/permissioned/both

Jack
@jackvalinsky.com

so the idea is that a if it's under a different uri than you can reuse lexicons but it resolves the data differently?

vielle 🪤
@vielle.dev

im more partial to any of the at+space:// or at+sp:// or anything the + indicates its an extension to atproto,, i think keeping the at in there is really important too i do like ats:// from an athstetic pov, but being mixed up w secure really is the dealbreaker

Trezy
@trezy.codes

Against, personally. ats:// at least feels like it belongs within the namespace, and not so general as space://.

bryan newbold
@bnewbold.net

I think these URIs are going to be at lot less visible to end users vs at://, which makes me feel a bit bad about grabbing a nice juicy noun like "space://". I sorta like 'psst://' or something that hints at a whisper / non-public.

bryan newbold
@bnewbold.net

having 'at' in the there makes the protocol family clear. I kind of like 'at+space://' for that. it's a bit less "authenticated transfer", but "self-certifying" is the real property space data doesn't have

Ezra🦋
@ezraboeth.com

I feel like at+spc:// is the middle ground here. it's shorter than at+space:// and more clear than ats://, while still being intuitive

bryan newbold
@bnewbold.net

I would be in favor of having variations of the path structure for "strong refs" (append CID as an extra path segment), and for referencing blobs (use 'blob' instead of an NSID, and CID as rkey)