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 
).
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
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!