Post
Not sure how I feel about it. Maybe psat:// "permissioned space authenticted transfer".
0 reposts1 like
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"
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
For something slicker, consider: "st" = space transfer, or "ps" = permissioned sync Both backronyms would actually convey something about what this protocol variant does that at:// doesn't Is it still a general-purpose transfer mechanism (like at), or a more narrowly-designed sync mechanism?
I vote st:// for the AT space uri scheme because when i think of spaces I think of gathering locations, which a street is. st also doubles as a TLD which benefitted at:// and also it would give us even more metaphors than simply the atmosphere/sky.. such as neighborhoods & gated communities
And -- unlike "space" -- none of these have the slashdot problem of making the URI ambiguous when read aloud
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?