[jonathanstrange]

Since I'm using libp2p in Go for a side project, may I take this opportunity to ask how this could work in principle for a decentralized network? The way I see it, this seems to be impossible but maybe I'm missing something.

For example, in my network, anyone can start a node and the user has full control over it. So how would you censor this node? The following ideas don't seem to work:

1. Voting or another social choice consensus mechanism. Problems:

- Allows a colluding majority to mount DOS attacks against anyone.

- Can easily be circumvented by changing host keys / creating a new identity.

2. The equivalent of a killfile: Users decide to blacklist a node, dropping all connections to it. Problems:

- Easy to circumvent by creating new host keys / creating a new identity.

3. Karma system: This is just the same as voting / social choice aggregation and has the same problems.

4. IP banning by distributing the blocked IPs with the binaries in frequent updates. Problem:

- Does not work well with dynamic IPs and VPNs.

Basically, I can't see a way to prevent users from creating new identities / key pairs for themselves whenever the old one has been banned. Other than security by obscurity nonsense ("rootkit" on the user's machine, hidden keys embedded in binaries, etc.) or a centralized server as a gateway, how would you solve that problem?

[Ajedi32]

I've thought about this a lot. Currently, my preferred solution to the problem of Sybil attacks in decentralized social networks is a reputation system based on a meritocratic web of trust.

Basically it would work something like this: By default, clients hide content (comments, submissions, votes, etc) created by new identities, treating it as untrusted (possible spam/abusive/malicious content) unless another identity with a good reputation vouches for it. (Either by vouching for the content directly, or vouching for the identity that submitted it.) Upvoting a piece of content vouches for it, and increases your identity's trust in the content's submitter. Flagging a piece of content distrusts it and decreases your identity's trust in the content's submitter (possibly by a large amount depending on the flag type), and in other identities that vouched for that content. Previously unseen identities are assigned a reputation based on how much other identities you trust (and they identities they trust, etc.) trust or distrust that unseen identity.

The advantage of this system is that it not only prevents sibyl attacks, but also doubles as a form of fully decentralized community-driven moderation.

That's the general idea anyway. The exact details of how a system like that would work probably need a lot of fleshing out and real-world testing in order to make them work effectively.

[yorwba]

> I can't see a way to prevent users from creating new identities / key pairs for themselves whenever the old one has been banned.

You could prevent banned users from returning with a new identity by disallowing the creation of new identities. E.g. many Mastodon instances disable their signup pages and new users can only be added by the admins.

If you don't want to put restrictions on new identities, you could still treat them as suspect by default. E.g. apply a kind of rate limiting where content created by new users is shown at most once per day and the limit rises slowly as the user's content is viewed more and more without requiring moderation. (This is a half-baked idea I had just now, so I'm sure there are many drawbacks. But it might be worth a shot.)

[JulianMorrison]

The way it works in Mastodon is that (1) not everyone runs a node, but there are many nodes, and they each have their own policies and can kick users off, and (2) nodes can blacklist other nodes they federate content from.

This two level split allows node operators to think of most other users at the node level, which means dealing with far fewer entities. It provides users with a choice of hosts, but means that their choice has consequences.