Thoughts on atmosphere groups "Invite" space

Working Groups WG Community Standards
1

Hey folks I wanted to start a thread on the invite model proposed in my opensocial.community proposal (and yes I’m coming around on the name, that’s just what the proposal’s still called :sweat_smile:).

Here’s the original thread: Opensocial.community proposal

Here’s the Google doc: opensocial communities proposal - Google Docs

Here’s the relevant section on Invites:

An invite is an interesting case because it must reach someone who isn’t yet a member and therefore does not necessarily have access to the community’s spaces. Invites usually should not be broadcast publicly.

Instead, each user who is interested in receiving invites to communities hosts an invites space under their own DID, and a community writes an invite record into that space. The community will notify the user’s PDS of the write which will in turn forward that notification to any relevant services which can then read and present the notification to the user.

Only the user (and authorized applications) may read the space. In other words, the inviting community writes the record but can’t read other invites in the space.

Currently this isn’t possible to implement in the spaces alpha. I took a stab at it in this thread and this PR.

Basically, I wanted to get a read on how people are feeling about this!

To me, we basically have four options:

  • This proposal
  • Invites are a code/link/qr code/capability/etc.
    • This is great and simpler in some ways! But you just can’t build a normal “you got invited to this community” notification flow off of this. The notifcation needs to get delivered across apps for the notification to work
    • Just seems like a non-starter to say “you can’t build the type of invite flow users have come to expect from modern social apps”
  • Communities post in their own invites space and then share that with a bunch of apps.
    • This kinda sucks because smaller apps won’t be able to show invites. So a user would have to accept the invite
  • A centralized invite service :frowning:

I think this model of doing things sounds a little zany at first, but I actually think it’s quite nice in practice. I can see many things built off of it. Ms. Boba said something similar:

The main downside is that this is the first open unsolicited push vector in the PDS. That makes it a natural spam vector.

Things that make me feel better about this:

  • The PDS does not ever show these invites to users. Applications get access to them and then show them to users. Apps are in a good spot to do actual spam detection!
    • “User is annoyed by invites” ← this is a problem for applications.
    • “Resource abuse from storing/forwarding a lot of write notifs” ← this is a problem for PDSes
    • The latter is much easier to deal with than the former. But the PDS doesn’t have to deal with the former!
  • The PDS never stores any of the records that other accounts publish in the space. It just stores the write notification basically. And this is only ever the latest notification per-user.
    • So one account cannot “fill up” a PDS. You need many DIDs to cause any real resource abuse. I expect this can be detected generically
  • A PDS is not required to forward write notifs or store the latest. If it detects spam or gets notifications from known bad actors, it can drop them.

Anyways, chime in and let me know your thoughts! Or if you have alternative ideas!

5 Likes
Opensocial.community proposal
Atproto spaces alpha updates
2

For what it’s worth, we haven’t implemented formal invites in Roundabout. This is my broken record track, but I think it’s a mistake to define standards for problems that multiple (n > 3) products aren’t asking for and aren’t actively trying to coordinate on. When that work needs to happen, I think the requirements should come from those products, not the standards body. <3

1 Like
3

(my solution here would be “let the community manager handle this in a micro-centralized way until we have a better handle on real-world use-cases”)

4

That’s a fair argument! And I’m sympathetic to the notion that we should keep this spec as light as possible.

I am pretty sure we will be implementing invites in the Bluesky app for the groups feature that we build on top of this standard. So that leaves us with three options:

  1. do it in the Atmosphere Groups standard
  2. do basically the same thing as proposed here but in an app.bsky namespace
  3. do it off protocol

If not #1, I expect we’d do #2. For what it’s worth, apps wouldn’t have to use the invites part of the standard. It would just make it available to applications that want it.

1 Like
5

I think this is good as proposed. I think some form of inbox is unavoidable, and that it aligns nicely with just using the spaces protocol as-is.

I also understand the sentiment, but I do think that we need some form of invites essentially immediately if we want to have inter-app groups, which is the main goal I think for drafting out this spec.

I don’t think we need to treat this proposal as more “ready” than it is: like it’s not too bad to get going early and change it if necessary. I’m not sure if this is the general feeling, but I see it as a first-pass attempt for us to try and integrate into our n > 3 apps as they come along to feel out whether it actually works for us.

If it doesn’t, then it’s probably worth revising. But just getting the discussion out there so that we can help identify issues with each-others’ use-cases early seems not too bad.

Yeah, I think it’s probably OK. I do think that there there is possibly an argument that it’s a little too much to ask for from every PDS implementation to be able to handle incoming spam properly while managing resources appropriately. In that case it seems like having the user define an inbox space / account that could be hosted on another space host and have tools specifically for spam might be a good mitigation, but I’m not sure if we want to be preemptively respond to the potential issue if it might not be too much trouble for the PDS to protect itself from a relatively slim attack vector.

1 Like
6

A concern I have that’s somewhat along those lines is that if the PDS has to mitigate spam to an extent, then if no good implementation of that is given, the system could be unreliable across implementations to an extent, and user-facing that would fall onto apps in terms of blame.

Another problem is that automatic spam detection and mitigation may be much more difficult for apps with this protocol than in a public broadcast or centralised system, so I expect this to be a problem on smaller compatible apps if any become too popular.

…but if such an invite space is created that everyone has, I’d rather prefer that it be actually special-cased, so that it can be managed once in advance and mitigations (hopefully!) won’t have to be applied to the same extent to most other spaces.

7

This stuff in the doc about the need to prototype OAuth stuff for individual users to write as the community DID stood out to me. If I am understanding it correctly, this refers to users with role permissions allowing them to do so being able to act from the community account, such as writing announcement posts or performing moderation actions like banning someone, correct? What are the core situations that a user would end up “creat[ing] records on behalf of a community DID” for?

I’ve pulled out the relevant parts of the doc below:

If a user (for instance a community admin) wishes to write as the community DID, they do so by holding an OAuth credential for the community DID and writing that record to the community service. The community service will support all com.atproto.space.* CRUD methods.

This does not imply that the user needs to have “full access” to the community account or that they need to login to the app as the community account in a traditional sense. Rather, the community service also serves as an OAuth authorization server for the community DID. Instead of requiring a password, it requires that the user authenticate using their personal account.

The OAuth scopes that each user/role is able to request for the community DID are also encoded in the access record in each relevant space.

Some questions

  • Can we think of ways to smooth over the UX of needing to go through an OAuth flow in order to create records on behalf of a community DID?

  • Are their alternatives to the above that are secure and legible to users in OAuth consent screens?

  • 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

Prototype a fake OAuth consent screen for the proxy-permission flow to evaluate UX

What would a good prototype of this fake OAuth consent screen show? To bring in some old HCI concepts, are you looking more for a sense of the role such a thing might take place in user’s lives and how they’d approach it, the visual design determining how screens for it look, or testing out the technical implementation on a small scale? I’d like to take a stab at exploring concepts for this, but there’s a little bit of a technical gap for me and I want to make sure I’m on the same page as others first.

1 Like
8

Hey @brightperegrine.bsky.social, we had a longer discussion on the delegated authorization over in this thread:

I think for now we’re just going to do an OAuth flow for the community account where you authenticate using your user account.

Tranquil actually has an implementation of something very similar which @nel.pet did a short writeup on over here: Tranquil account delegation: status and what we've learned

I think that’s be a good place to start if you want to explore UX!

9

Thanks for pointing these out to me. Definitely seems like there’s still some big questions on the technical implementation side. Looks like I have some reading to do on the Tranquil thing…