Removing the member list?

[zicklag.dev]

@nandi.uk

I’m not 100% up to date on this stuff, so I may be wrong here …… but, it seems like the more stuff we offload to appview and not have on protocol, the more the app owner controls data flow and we revert back to the world where the enshittified service owns my data and not me. Hopefully I’m wrong and ya’ll can correct me

I think there are several things that make this different.

The data can still be stored on user PDSes.

So even if the AppView can control who gets a credential to view my data, it can’t take my data on my PDS away from me. ( For the sake of argument, assuming you trust your PDS. )

Communities tend to need some central control.

I think @essentialrandom.bsky.social does a really good job walking through the holistic “why” of that in her post here: The Vault: a (possible) answer to the "Fully-Private Community Data" question.

Basically, we do need communities to be able to elect a central coordinator for private or shared community data. The important part is being able to swap out this service if it goes bad, which is preserved. ( And explained in @essentialrandom.bsky.social’s post, too. )

The members can still bypass the space host.

Hypothetically if the community members know about each-other ( which is sometimes an anti-feature as in the Frequency use-case ), then they can bypass the space host and grant each-other access to the community data hosted on each-others’ PDS.

This can be used to create a new community with the old data, if the community doesn’t have control over the community DID and they just need to “fork” to a new community DID.

The space host is more narrow than an AppView.

The space host doesn’t have all of the responsibilities of an AppView. You can also still have multiple AppViews that index the same community. The space host can end up more like a member / policy-aware “relay”.

So while it does hold a lot of power, it can still be replaced, and it doesn’t hold all the power.

---

@rochebit.net

But is it not also expected that anyone can host a space under their own identity on their own PDS? These spaces hosted under the users own identity shouldn’t need the more complex membership management (or if a user thinks they do they should go to one of these dedicated space hosts). Would removing this member list lead to PDS hosts (which are currently very ubiquitous) handling these in different ways?

Yeah, I honestly wonder whether or not it’s a good idea to let people host spaces on their PDS or not.

I think that the only way it makes sense to have groups hosted on the PDS is if we can come up with very simple, general, and yet still useful group semantics that are reasonable to force every PDS implementation to implement.

Maybe a basic membership list is simple and generic, but I guess the question is whether or not it is useful.

Are apps actually going to use it, or is it something that may as well be stored as records in your repo that an app’s space host can read? In practice will apps generally have to have a more sophisticated space host anyway?

Maybe this is something we don’t have to answer right now?

For example, we can implement the base protocol without having any space host on the PDS and let other people start building apps with private data and groups as soon as that is done. Then if it seems that there is a use-case for a built-in space host that is general enough to expect all PDSes to implement it, we can add that in another step.