Inboxes - use cases and spam prevention

[elf-pavlik]

Some app developers would want to use public append inboxes. I see it as a big ask from the user to create a public append inbox that can open a spam gate.

In this discussion, I would like to gather use cases for when people would like to use inboxes. Evaluate alternative patterns which address potential spam issues. Weigh when it is recommended to ask a user to create a public append inbox and when not. Discuss dedicated inbox providers which can use spam protection similar to mail servers.

[mrkvon]

The following are use-cases for hospitality exchange community app we build, but they are imo relevant to many social interactions

Copied from discussion in solid/app-development Matrix room

1. bi-directional contacts: it makes sense for our use-case to show contact between people when both have established it. (i.e. both sides published that they know each other) (Further, they grant the other person some additional access rights in the process.)
   When first person establishes the contact, they let the other person know that they should do it, too (if they want)
2. messaging, especially first message between 2 people, invitation to group chat etc.: when one person sends a message (i.e. publishes it on their pod for the other person(s) to see), they need to let the other person know that there is the message for them to read
3. many such social interactions, i publish something on my pod and let the other side know, either to ask for action on their side, or just let them know

It needs to go to the place which is well-known to the other side, which is the inbox.

[elf-pavlik]

Since you are developing an app to facilitate hospitality exchange. When I think about using such an app, I would not want it to access all my messages (equivalent to an email inbox). I may have messages which are from my health care provider, financial services provider, unemployment services, dating, etc. None of those are relevant or should be made available to a hospitality exchange app.
Do you plan to have built-in messaging or only facilitate exchanging contact information and leave out messaging to whatever generic app different users chose for messages?
When it comes to establishing bi-directional data sharing. In SAI it is facilitated with reciprocal Social Agent Registrations. I'm also preparing to work on establishing those registrations using pre-established communication channels solid/data-interoperability-panel#302 there are various aspects of privacy, potential imposing/spoofing that have to be addressed.
Do you plan some kind of hub service to accompany your app? How do you expect strangers to make first contact? How will two strangers know that they have a common interest in sharing hospitality? If you plan such a hub element that could introduce peers and enable finding one another, such a hub could also play the role of facilitator in establishing connections and mitigating spam.

[mrkvon]

Do you plan to have built-in messaging?

edit: We're currently discussing whether to include messaging or not. My previous answer wasn't correct. The use-case of inboxes for messaging, imo, is still valid, regardless.

Yes, we do, and it already works (just email notifications don't work). I've implemented messages, but we're discussing whether to include that feature or not. In principle, we're implementing user experience similar to that of https://bewelcome.org or https://trustroots.org. However, if that's problematic, we can also just let people share their Signal/Telegram/phone/email/whatever...
Or if you mean generic Solid app for chat, then sure, they're free to choose, as long as the apps use interoperable data. (we follow data structure of pod-chat.com, i.e. each person publishes messages on their pod, and lets the other party know via their inbox.)

When I think about using such an app, I would not want it to access all my messages

Fair enough. We would happily limit the access of the (client-side, browser) app to only what's needed, if such mechanism currently existed and was user-friendly. We'll be happy to use it when it is stable and usable for non-technical folks (maybe something like we commonly see with oAuth). (i can see efforts in this direction in the SAI draft, i guess) As of now, the app requires full access, including Control (we're using it to establish access of the particular resources that the app creates).
It's client-side and open-source, so at least you have some control that your other data aren't messed-up with, or sent to third parties.

When it comes to establishing bi-directional data sharing. [...]

I don't understand this enough to comment on it. Anyways, we let people share their relevant data with others by giving access via WAC to a vcard:Group in which members join, or to a specific other person. That seems to suffice.

Do you plan some kind of hub service to accompany your app? How do you expect strangers to make first contact? How will two strangers know that they have a common interest in sharing hospitality?

Currently, folks join a sioc:Community by adding themselves (or maybe requesting to join in the future) to vcard:Group, and find each other there. The group serves both for data access control via acl:agentGroup, and for members discovery. The app shows available accommodations by looking into every group member's offers (via public type indexes). We also hope to make geo index that will facilitate this accommodation search. We also hope to make the group redundant, so many people can host a copy; to remove this one central point of failure.

Here's example community and group. Used at https://dev.sleepy.bike. Please note that we lost access to that pod (don't remember email used for signup). the group is public and we won't be able to delete or edit it in nearest future.
This group currently needs to be public, for technical limitations of WAC access control. We'd love to have it accessible only for its members (it would self-reference in its own ACL), but currently it has to be public.

If you plan such a hub element that could introduce peers and enable finding one another, such a hub could also play the role of facilitator in establishing connections and mitigating spam.

We'd prefer to leave out unnecessary centralization. We'd prefer if contact between folks could be established without such a hub. Also it's one piece to maintain less, and one less point of failure. Well, maybe folks could have inboxes which only the group members can append to (well, that depends on this central piece). In longer term, more spam-protected general-purpose Solid inboxes would be nice. I'm also curious to hear about other solutions that would fit this scenario.

More generally, it seems like this is a question whether people who previously didn't know each other can make a connection via Solid or not? And if yes, how? (And how does spam come into the picture?)

I'd say i'd generally want folks to be able to contact me if they say who they are (are authenticated), and if i can stop those who prove to be malicious...

For now, we're focusing on making it work. We'll hopefully improve things as we progress.

[elf-pavlik]

Thank you for all the clarifications and pointers. I will look deeper into your use case and share more thoughts over next days.

Minting new WebIDs is pretty cheap, just an IRI. One could easily deploy something that crates throw away WebIDs, possibly similar to https://www.guerrillamail.com/ Any blacklisting approach wouldn't work unless one starts banning whole domains or OIDC Providers, which already goes into non-trivial spam protection.

BTW Did you try contacting @ewingson about your lost access to account on solidweb.me ?

[ewingson]

@elf-pavlik @mrkvon
I have the access and a brain.
the access is on the ssh layer and I will do anything to make things work.
just write to my email [email protected] mentioning the account in question and I will do my best.