Handling Sybils?

[makoConstruct]

As I understand it, currently in cabal a person can create as many accounts as they like at no cost, and the default disposition on a new participant is non-blocked, yeah? This would make ban evasion quite easy. I have some thoughts about how to approach this, to keep the issue general, I'll post them in a separate comment.

[makoConstruct]

Essentially I think there needs to be a whitelisting web as well as cabal's existing blacklist web.

I'd suggest a web of trust representing a quality like "invitations" or like recognition of unique registration. Anyone not reachable for you, in this web, should be blocked by default. Any erroneous issuance of invitation could be traced back to the first accountable inviter, that person can be told to stop handing out invites thoughtlessly, or if those invites were found to be intentional (if, say, they turn out to be a spambot maintainer), they can be severed from the invitations web.

I can sorta imagine overloading the moderation web to serve this purpose, and automatically blocking anyone with less than 0.001 mod energy or whatever the threshold should be. I think that would actually be very awkward. When I invite someone, I shouldn't really have to make a judgement about the validity of their decisions to block. When I disagree with someone's moderation decisions, I should not have to ask anyone to effectively ban them from my segment of the system. The whitelist and the blacklist have different characters.

I don't think doing this would complicate the process of inviting people to cabal. I think how it would be done is... instead of giving people a link that just has a room address, it would also have an invitation key, which entitles the new user to (automatically) create an invite endorsement to themselves, from the person who created the link. When the link is created, the creator sets a limit on how many new users coming via this link they will endorse (sometimes the limit would be 1), and they may place a limit on how long the link will remain valid. The links would be longer, but the UX would otherwise be pretty much the same?

[okdistribute]

Thanks for bringing this up!! Great idea to talk about this.. would love to see more sybil prevention out of the box for cabal. Your web of trust idea is very cool and experimental which is great for cabal because well cabal is also experimental :). If not implemented directly in cabal, it could also be accomplished using a bot. There are a few bot template libraries and examples in the cabal github org and probably also on npm if you do a search.

Cabal already provides pretty good invite-only support by only allowing users with the original public key to join the cabal. This public key is not discoverable, similar to how a google doc link works or a discord link. If your cabal is very large, you might get an issue with sybil attacks for sure. If your cabal is small, you probably can figure out that a person is not who they say they are with some investigation, and somehow disinvite or ban that device. However, if they already know the key they could rejoin...

Different providers have different user experiences for handling this..

1. Timer. Discord provides a timer (1 day) by default for these links. The benefit here is that hopefully the invite links would only be sent to known parties, and any potential leak of an invite code to an attacker would then expire and they would not gain access. I don't know of a decentralized app that is doing this right now but I bet it exists somewhere.
2. One-time use invites. Magic wormhole provides invitation links that only work once, and if there is a failed attempt, the invite connection is broken and must be re-established with a new invite password. This is also called PAKE (or improved SPAKE2).
3. Revocation. Something like what you mentioned above regarding the chain of invites & moderators.. TACO is an example implementation.
4. Walkaway keys. Discussed in another issue (not sure where... anyone know? @cblgh?), this method is essentially how to dis-invite in the app level, without changing the protocol layer at all.. how it works is a new key can be issued and only sent to individuals who the issuer wants be included (i.e., minus the device that should be dis-invited, the sybil attacker).
5. Nickserv. This is how IRC prevents sybil attacks. You could use a 3rd party service (like email) and a cabal bot that verifies user nicknames based on their registration and password (or if you want to go blockchainy instead of email, some private key zero proof crypto stuff).

[makoConstruct]

I'm fairly sure it couldn't be done with a bot.

Just having a non-discoverable link is not a good way of doing invite-only communities. If it leaks, and eventually it will, there will be no way to figure out who is responsible, let alone stop it from spreading further. Invite trees (or webs) track who is responsible for each invitation, they really seem to be just the correct data structure for recording/revoking invitations. Consider how they'd handle a situation where someone wrote a spambot that would invite more copies of itself, which invited more copies. Being able to trace back the abusive invitations to their root (the first spambot) and cut them all away there is a really good way to handle that, having to handle that without being able to trace the lineage back would always be a terrible mess that never really ends.

[okdistribute]

Depends on if you trust the bot or not. It introduces a point of failure so you have to take that into consideration! I think the solution changes greatly depending on what your use case is and how many people are in the cabal

[fabianhjr]

A simpler approach could be to require some PoW on an id. Say, something that takes about 10 seconds per id on a mid-range 5-year old computer with something like scrypt.