Agreed that in general, I think this is a solid direction, and I’m extremely appreciative of @dholms.xyz work on all of this! The overall shape feels “right” and as you said, the ideal here is “minimum viable privacy” at a PDS level, with the ability to extend the semantics at the application level.
I’m personally entirely way too busy right now to really stress test it against our systems, but my concern is that splitting the private/public APIs makes a lot of what we do potentially much more complicated, with two potential code paths for every write.
Where it’s not made more complicated, my sense is that we’ll just switch to using private spaces, since I suspect it will be hard to justify a public and private write path – which I worry will have the net effect of moving the vast majority of the atproto network into a private space paradigm.
My initial post was framed out of feeling like the bsky vs. community power dynamic was landing a bit wrong with the “70% fait accompli” framing, but I really appreciate your perspective, @zicklag.dev. I know no-one has any mal intent, and take your comments here as a sign that there’s still time to change things.
That is a great point. I’m not sure if there’s a way around it, but that’s essentially what we are planning on doing with Roomy: every Roomy space will have a DID with a space host, and even public communities will user permissioned spaces, they will just not require membership to get a space credential.
That is best for Roomy since it allows us to easily make channels public / private instantly, etc. And group chat isn’t the kind of thing that is the most important to have going over the firehose. It’s fine, and possibly even preferable, to have apps subscribing to particular spaces.
I’m not even sure the firehose could handle it if we ended up the “Discord” of ATProto.
We figure if we need public exposure we can use the arbiter to publish public records to the community’s public repo, even if sometimes it’s just a “wrapper” around / link to a perm space record.
Totally! I have the same concern & that’s why I’m trying to telegraph where we’re at & ask for feedback every step of the way. That was my goal with this thread. I didn’t expect there to be much surprising in the proposed lexicons. It was basically just a schema version of the big picture post from a few months ago & that I chatted with a bunch of folks about at AtmosphereConf. Lots of details & mechanisms have gotten updated based on concerns from builders & alternate proposals. But I I haven’t encountered any deal-breakers on the rough big picture.
Don’t worry though! The iron’s still hot & has lots of give. I’m trying to get a full proposal together with details ironed down by the end of the month. But even then, it’s still a proposal & I’m actively looking for feedback on it. We have some time before things are set in stone. If anyone is building in the ecosystem & has major concerns with where the design is headed, it would be good to get those to the surface ASAP.
It does sound like doing a weekly round up would be useful and provide structure. I don’t expect everyone in the ecosystem to dedicate substantial time to keeping track of all the convos, but I still want those opinions to shape the design. I’ll try to collect links & threads throughout the week and publish those on a thread in this forum. Other folks can publish anything that I missed as replies or get into discussion on anything in the works. I’ve found async has been working well, but I’m around for a video chat too if you like.
Ah I was talking about client authorization for writes on the PDS. You’re correct that anyone can write to a space on a hacked up PDS (and that’s why we ultimately decided to not do write authorization for spaces at the protocol level). But still, we need a way for users to consent to authorize OAuth clients to do writes in a space on a PDS. Designing so that permissioned data is legible on an OAuth consent screen is one of the biggest design constraints.
There’s also just a hard blocker on reusing the com.atproto.repo methods for spaces. Which is that it would probably work by adding an optional space param & there’s a major backwards-compatibility concern there. If a PDS doesn’t support the permissioned data protocol yet, then a write to a space would be interpreted as a write to a public repository which is a major user consent violation.
You don’t need to! A user never proxies anything to a space. They’re always just writing to their PDS. It’s up to applications to keep you from doing “nonsense writes”. In the same way that the Bluesky app doesn’t let you reply to someone you have blocked (even though you technically can in your PDS).
Ah that’s interesting. And that would just be a method to call to register that you want notifications, right (as in, it’s not a websocket)?
Right now I have that just riffing on the credential flow (basically if you get a credential, that it auto-subscribes you for writes). But maybe it’s better to make it a bit more clear of a relationship & also add some flexibility as well.
That’s true, though the data can’t be rebroadcasted in a self-certifying manner (I strongly view asymmetric signatures to be an anti-pattern for permissioned data). So this would rely on a trust relationship a la jetstream. And the rebroadcasting service (vacuum gives me postgres PTSD flashbacks lol ) would just need to be diligent about not violating access boundaries of the space
I took a stab at refactoring the PDS lexicons. Interested to hear thoughts!
The idea was to remove the member list as a protocol concept. However managing membership is still how most spaces under a user’s DID on a PDS would operate. So this required having two “levels” to the Lexicons for spaces. One which is the core protocol implementation and the other which is a “space management api” which would be required on PDSes.
As I worked on it, it actually felt like I could go a step further and split it into 3
spacehost: required protocol implementation for space hosts/authorities (an arbiter would implement this for instance, as would a PDS)
spacerepo: required protocol implementation for space repo hosts (every PDS would need to implement this)
simplespace: a simple space management api built around membership. this is not considered a “core part of the data protocol” but would be a required api for PDS implementations (as many apps will rely on this)
See com.atproto.spacehost.getSpace for an interesting example of how this plays out. The config on the output is an open union that returns a simplespace config. However a more complex space host (like an arbiter for instance), may return a completely different type of config.
I am not deep enough in the details to confirm the assertions involved, but it tracks to me that the membership controls can be pluggable. Access grants are the narrow waist of authorization (IIUC) so you can wrap that with a diversity of implementations. Given that a lot of the inventive schemes around communities seem to anchor around membership & authority mechanisms, I think that could be a solid win.
The new namespaces are a tad inelegant. It’s rough to staple two lowercase words together. What about com.atproto.space.repo.*, com.atproto.space.host.*, com.atproto.space.simple.*?
Although after sleeping on it, I’m kinda leaning towards merging back together the host/repo namespaces (nearly always services will support both). So just:
com.atproto.space.*
com.atproto.simplespace.*
Which the latter doesn’t bother me as much to staple the words together cause it kinda just seems like it’s own new noun
) would just need to be diligent about not violating access boundaries of the space