My understanding of simple spaces is that it’s supposed to contain the minimal functionality we expect every PDS to be able to support. This way we can expect every user in the Atmosphere to be able to have these spaces under their identity without a custom space host. More complex spaces will have custom space hosts and can provide all sorts of fancier functionality.
But going through the simple spaces alpha implementation, I’ve noticed that reading and writing are strongly tied together. There is no way, even when using a managing app, to allow a user to read but not write (or write but not read). And to be clear when I say write here, I mean their write notifications will be forwarded through, and their PDS will be listed on listRepos calls on the space.
This feels like a gap in what we’d want as the baseline for all users PDS’s. I’m not asking for more advanced controls of what collections within a space you may have access to, or determining a user’s access to one space by data in another space. All that can be done in custom space hosts. But I was expecting at minimum I’d be able to share a little bookmark list I had made on a space I own with another user, without giving them write access, and without having to use a custom space host for it. I’d also argue this should be able to be done without a managing app, but at least let it be done there.
This ability to separate reads and writes will also be a prerequisite If we want to support (I know not everyone agrees on this yet) the invite spaces for standard open social groups.
Have I misunderstood what use cases simple spaces are supposed to cover?
Good question. You’re right that at a minimum for the Atmosphere Groups standard invites space, we’ll need read-limited spaces that allow open writes (assuming we go with the current proposal). I was planning to capture that with just a boolean for openWrites.
As for something like the bookmarking app, the idea is that writes would be limited to the same list of readers. Applications would enforce write management in the way they normally do. For single writer spaces like bookmarks, applications could just be smart enough to never bother syncing any other space besides the owner.
The main downside is it’s a resource abuse vector, but I don’t know how bad that actually is if writes are still limited to the member list.
The thinking here was just to keep it as simple as possible. This mirrored an earlier design of the protocol where the member list was in the protocol and writes were enforced by the application.
BUT, since we’re now in userland (with simplespace), I think we can be a bit more opinionated and it’s not crazy to add write notification forwarding back in. Basically, each member would just carry two flags for read and write? I’m not really opposed to it & it does seem like it helps answer a common question
I’m still a bit nervous about allowing open writes (because of resource abuse concerns), but I haven’t figured out a good alternative yet.
