Howdy friends 
recapping the discussion from the meeting for anyone that was unable to join! Thank you to those that were able to join and everyone participating in this discussion so far, I’m VERY excited to see these things start to move and to soon see Atmospheric Groups in real apps 
Deep-dive on how to model proxy/delegated permissions for communities (groups) in atproto OAuth, and on spam vectors in the PDS-hosted invite/space inbox design. No decisions; group will continue in Discourse and possibly regroup in a couple weeks.
Proxy Permissions for Community DIDs
-
Core question: how to express ‘act on behalf of community DID’ in an OAuth scope a user can consent to
-
Two approaches weighed: spec a new third-party repo-access resource, vs. app holds its own OAuth credential to the community
-
Daniel leans toward the latter: simpler, no new primitives, matches web norms
-
Ms Boba wants protocol-level support so burden isn’t on every app, even if 6 months out
-
-
Alternative: extend repo/RPC resource with an ‘audience’ / ‘acting as’ parameter (star or specific DID), akin to audience tokens
-
Shank noted JWT Bearer Grant (used in Habitat) lets community accept any app of a given type without per-app authorization
Invite Inbox & Spam Vectors
-
PDS-hosted space inbox creates a spam vector via notifyWrite + listRepos accumulating author rows
-
Debate: apps are better equipped to filter spam than PDSs; labeling services could tag spammy apps like spam accounts
- Mitigations floated: retention period on write notifications, compressed (space, author) keys
-
Zicklag proposal: one level of indirection — user points to a separate inbox DID / space host designed for spam handling, keeping inbox on protocol
-
Open question raised: can a DID have multiple space hosts (e.g. one for groups, one for notifications)?
Next Steps
-
Continue both discussions, and any others, in Discourse and schedule a follow-up call in a couple weeks if needed
-
Prototype a fake OAuth consent screen for the proxy-permission flow to evaluate UX