This is a forum thread to collect feedback on the permissioned data protocol proposal!
To clarify: this is still a proposal. I expect many changes along the way. Suggestions may also be submitted as issues/PRs.
I had hoped to have an alpha version of the PDS alongside this proposal, however I didn’t quite get there yet. Hoping to have that in the next couple weeks.
The previous thread was here: Early permissioned data proposal draft feedback
Changes since then:
- Responded to a bunch of feedback from the PR. Tightening, clarifications, renames, etc
- Added “Considerations” section at the bottom with some non-normative thoughts on moderation, scaling & account lifecycle
- Added a permissioned repo serialization (CAR) format
- Switched from
ats:// → at:// (this one is still not quite decided - discussion over here)
- DID-doc entries are optional with fallback to current #atproto/#atproto_pds values
client_id removed from space credential- Oauth scope parameter changed from
did → authority & defaults to self (so bare space:<type> scope now grants only spaces under the user’s authority)
10 Likes
Sharing my official public feedback on this proposal:
Hot. dog.
6 Likes
Overall looks great.
The access control requiring a users delegation token leans heavily into user triggered access, which makes sense for most use cases. For clients that need to process data ahead of delivery to users (e.g, client moderation, notification of new content), or clients that are working on publicly readable permissioned spaces, is it intended that they use a bot DID of their own to request space credentials?
And a minor one: you mention that a space authority can “un-register if it no longer wishes to be notified”, but I don’t see where that can be done in the current write up.
I want to put this on record because the proposal lands pretty well for the book-clubs work I’ve been doing on Livtet ( What's Supposed to be Different about Livtet? - Jacky Alciné ) - and that’s a narrow enough use case to be a useful stress test.
The shape works. Federation of shared reading groups is now possible without me having to stand up a relay-equivalent; notifyWrite plus listRepos is the operational backbone, and the LtHash self-heals missed events. The per-reader ikm and HMAC means a leaked proposal doesn’t prove what the user said, which matters when a club is reading something a member would rather not be associated with later. That’s not a hypothetical concern -I think about it for clubs I’m in (and considering the current political landscape).
A few things gave me pause, though:
- Member eviction has no protocol signal. @dholms.xyz named this in Diary 6 ( Permissioned Data Diary 6: Boring Auth - Daniel's Leaflets ): “revocation has to fan out to every writer in the space, not just the space owner. Tractable, but not trivial.” Shape I’d want:
com.atproto.space.notifyMemberEvicted, sent by the authority to every endpoint registered via registerNotify. Payload would be something like
{ space, memberDid, evictedAt, reason? } where reason is a typed list of voluntary | removed | expired. Sender authenticated via service auth. Receivers treat it as a hint and confirm via credential-renewal failure before deleting - that’s what closes the door on spoofed-notification-triggered purges and it’s also the path missed notifications self-heal on. Without this, GDPR’s right-to-erasure story has no answer for pull-based syncers (and tbh, this makes it easy to allow folks to consentually leave and not be forcibly readded; gives clients a way to pull immediate removal from groups, etc etc).
URI unification. @bnewbold.net — I’m following your lean toward at:// + space even though you argued for ats://. I’ve isolated URI handling behind one abstraction, so a flip is a one-file change if the consensus swings the other way. But your visual-distinctiveness point landed for me; I won’t mourn it either way.
authority=self defaulting on the OAuth scope I think is right — but the revocation UX is where the protocol can’t help me. Once a member has granted space:…?authority=alice, how do they later see and revoke that grant without losing their data? Bluesky’s per-app-permission screen is the closest reference; the protocol doesn’t dictate the shape and the granularity here is more than most users are used to reading, I imagine.
1 Like