Heya! Thanks for all the feedback 
I’ve been writing my permissioned data diaries for the last few months and collecting & integrating feedback from folks along the way. My goal was to explore the design & solution space in real-time in collaboration with the ecosystem. Generally, my read is that the reception has been positive! I haven’t encountered any major deal-breakers with the general shape of the solution. And most of the folks working in the private data & communities space have signalled that they’re happy with the general shape of the design. The energy from teams like Habitat & Roomy has shifted to building the higher-level abstractions on top of the lower-level data protocol.
I think the problem may be less that it’s closed & more that it’s scattered across Bluesky threads, Leaflet posts, Discourse posts, Discord channels, etc. It’s a lot to keep track of. I have a somewhat unique lens on this because part of my full-time job right now is to wrangle these discussions (and even I still miss a lot!). Would it be helpful to do weekly or bi-weekly posts to this forum that are basically “things that happened with permissioned data this week”? I could include links to discussions, prompt questions, & try to sign-post rough timelines around decisions & expectations for releases.
I really want this to be collaborative & ensure it meets folks’ use cases, but I also want to avoid getting bogged down in too much process. It’s always a balance of course. Happy to hear feedback/thoughts on how to structure that as well.
That sounds great! I would definitely join for that as well!
There is a meaningful difference between the two! But I also think a lot of the meaningful stuff is on the community standards side. The protocol is intentionally kept very simple in terms of authorization semantics & things like roles (more on that here). The work Zicklag is doing with the Arbiter (good in depth post on it here) shows the type of rich application & authorization semantics that can be built on the permissioned data protocol.
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 
).
I laid out a rough version of my thoughts on this in my Big Picture post. I think doing a stateful websocket is going to be hard to manage with all the credentials that applications will be juggling. Unless you do a Websocket-per-space. But the downside of that is that many of these spaces will be very low throughput (especially on small or self-hosted PDS distributions). I think write notifications + pull-based sync (with HTTP/2 support for connection re-use!) is basically as close as we can get to subscribeRepos while owning up to those limitations & the lack of relays. I’m very interested if folks have other ideas!
I also hope that dev-tooling can help paper over some of the differences between the public & permissioned protocols.