I want to put in my firm dissenting opinion on this: a separate URI scheme (like ats://) is the better all-around design.
Globally public URIs and access-controlled URIs have different audiences and are going to show up in different places. A public at:// is like a domain name or account handle; or a wikipedia or reddit URL. They are the recognizable public brand, will show up outside the atmosphere, and are a welcome sign: if you see one, you can almost certainly resolve the reference. A permissioned ats:// is more like a file://, http://localhost:3000, or email message UUID; or a discord invite link. The “intent” or “what can I do with this” is pretty different. I think that is worth bumping up to the left-most, top-level-bit of the URI string: the scheme.
I think it is fine for the “atproto protocol framework” to encompass multiple URI schemes. It definitely encompasses multiple sync/resolution mechanisms. Public repo content and permissioned space content are all under the same big tent, but they are also pretty distinct, and I think that maintaining that distinction visually is better than conflating them. Public data (with a at://) is radically more public and redistributable than regular web content (with a https://) and I think we shouldn’t forget how different and important that is. Putting permissioned data under the same URI scheme weakens that expectation.
You could receive an atproto record on a thumbdrive and it may still be verified as “authentic”.
^ this is true for public repo data, but not for permissioned data!
In terms of lexicon string types, I think it is sort of a wash. You are going to care whether something is a public ref vs private ref in almost all situations, so it dilutes the at-uri meaning to be almost as general as uri. I think that we should be able to reuse the same lexicon record schemas for both public and permissioned records, but it is going to require some thought and probably tweaks to existing schemas either way.
Even though adding s is just a single character, I think it is visually distinctive because the part before :// is so short. ats:// vs at:// is even more visually distinct than https:// vs http://. I’m not super hung up on the name though. atspace:// would also be fine. I think the prefix of the URI is much more important for visual distinctiveness and understanding than the length of the URI, and especially compared to a single additional path segment in the middle (eg, for differentiating a “3-part public record URI” from “3-part space URI plus /space/”).
My overall argument is that we should keep things simple and predictable. In this case we need to reference records in two fairly distinct ways: in one way we have a global public reference (single authority), and in another we need to provide both space context and repo context (two authorities). Those are different enough that I think it is simpler to have separate URI schemes, each with consistent predictable structure and expectations, instead of overloading a single URI scheme for both.