Super appreciate all the work you’ve been doing on this. I think maybe now that the shape of things is becoming more clear, there’s value in having a conversation that’s a bit more consensus-driven, versus the requirements / technical shape gathering that you’ve been doing to date?
Part of this is very much in terms of building buy-in from the various interested parties. My concern is that if your proposal doesn’t match folks’ expectations in fundamental ways, we could end up in a not-ideal situation where core PDS mechanics are begrudgingly or not-at-all adopted by the community. Speaking for myself, there are a lot of various threads at this point, and keeping track of them all is fairly tricky, which means that the (probably incorrect!) impression I have from the “outside” / limited-time view is that “@dholms.xyz is taking input under consideration and will tell everyone what the protocol will be” vs “we’re working on this together and building a consensus that @dholms.xyz / Bluesky are happy to support on ‘mainline’ PDSes”
Is there any particular reason for wanting to use the existing methods? One reason for separating them is that they actually don’t retain their existing authorization semantics. Different OAuth scopes are needed for writing to a space vs to a public repo collection. Roughly, I think the “space type” and “space did” are the main axes that you can authorize on. I get into that more in this post (sorry for all the links lol 
).
Yes! So, I think the authorization for writes doesn’t lie at the PDS level at all. There’s nothing stopping anyone from writing to a space on their own hacked up PDS, even if some PDSes enforce these constraints, if I’ve understood the full proposal correctly (i.e., data living on individuals’ pdses). Since the “authorization” lives at the intersections of community pds ∩ user pds ∩ appview policy it seems kind of redundant to implement separate methods.
Error handling is a separate question, but I do worry about having to proxy an auth request to the space every time the user’s PDS wants to make a write.
For reads the situation is obviously different, and I think I could be convinced for the alternate approach, especially if it’s push-based. For that mechanism, though, I could imagine something that relied on the ‘central’ community PDS being “special.”
Specifically, having a subscribeWrite method that takes a destination as an argument and that requires sufficient group auth in order to subscribe to notifyWrite callbacks might be a more generally useful mechanism? The space PDS could (but wouldn’t have to!) call subscribeWrite on all new members, but for differently factored architectures, we could imagine a separate type of private relay server that could handle those events.
This would map it quite closely to the subscribeRepos semantics (and, I would argue, could be implemented as an internal filter over subscribeRepos with a parameterized set of auth tokens. But, that gets a bit messy for a variety of reasons, so the notifyWrite mechanism does seem fine. As a side note, having a space service (vacuum vs relay because space is a vacuum, ahem) that collects all of the space’s posts would mean that the appview could expose a pds/relay subscribeRepos or jetstream-style subscribe authz’d with a valid member token could be a nice simplification.
Does that make sense? Have I missed something obvious?
