Yes! I think this makes a lot of sense. In that thread I suggested that we make a space host that literally lies about the membership list to participants other than the owner.
I think the very fact that we could consider this “compatible” “tweak” to the protocol that is useful and yet somewhat subversive is a good sign that maybe the member list doesn’t belong at this level.
Like you say here:
This is essentially the same boat we were in with the idea of public permissioned spaces: there’s no reason the space host can’t just give the any random passerby a space credential.
Having the protocol be “honest” about the freedom that the space host has here seems like a good call and means that we aren’t soft-excluding more creative use-cases by either giving them more work than necessary or making them technically non-compliant to the spec even if they are compatible because the PDS can’t tell the difference.
Yeah, I think this might help Habitat, too. 
In Roomy we will probably still need to materialize a member list, so it might not make things a ton simpler at the end of the day, but it does still feel better that we can leave that choice to implementations / scenarios where it is actually needed.
This is very similar to the “federated spaces” idea that we were thinking about with the arbiter and, in the latest iteration, our policies can call out to any other XRPC endpoint in order to make auth decisions like this.
So that’s perfectly along the lines of what we were thinking. And @essentialrandom.bsky.social’s post that Boris link touches lightly on this, too.
Yes! No more syncing. We can just decide, at request time, by any means, whether or not someone is allowed to read the space.
This may actually solve some performance concerns I had about very large groups, too.
You could have millions of readers added to a group and not having to enumerate them can potentially make it a lot easier to maintain performance as the group grows.
Yep! I think that community semantics are notoriously difficult to nail down, and that the Atmosphere should have as much time as it wants to figure that out, while we need private data on protocol ASAP.
I think that Bluesky will likely want to define it’s own group semantics for the purpose of the Bluesky app, and maybe it will be generic enough that some other apps can use it as a starting point too.
But I really think most of this lies in the realm of lexicon development. I think that all we really need on protocol is the bare essentials of private data and synchronization. The rest is all stuff that we need to figure out as the Atmosphere, and that will develop over time, just like standard.site and lexicons.