Continuing to ramble (cc @dinosaur, @andrestaltz), here's a small idea for handling trust in a gossip protocol:

Peer discovery happens via view shuffling as usual for gossip protocol, that is to say: A pair of peers with a direct connection established between them will occasionally exchange the ip addresses of other peers they are connected to. That way, both learn of the existence of potential gossiping partners, this process builds the overlay network (this is simplified, but provides the gist of it. In particular, ip addresses are just a stand-in for more realistic connection information). Now instead of solely exchanging ip addresses, you'd exchange triples of (public id, ip address, trust byte). The public id is something like the pubkey of a feed in ssb. The trust byte signifies how much trust you put into that public id, the lower the value, the more trusted it is. This trust byte gets modified as follows:

• when sending a well-known id, set the trust byte to whatever trust value you associate with it. Examples:
  • your own id is well-known to yourself and you fully trust it, thus send a trust byte of 0
  • if you happen to have built a follow-graph like most ssb servers do, and the id known to you because it appears in the follow-graph, set the trust byte to the distance from between yourself and that id in the graph
  • if the id is in the map of temporarily known ids (see below), retrieve the associated trust byte and increment it (saturating at 127, not wrapping around)

When receiving an id that is not well-known to you, add it to a map of temporarily known ids. As the value associated with that id, put in either the trust byte associated with the id when you received it, or the trust byte of the peer who sent you that id, whichever is higher.

This little scheme has very low overhead, but established a nice, distributed, and fully subjective notion of trust. In particular, any attempt to "cheat" to make something look more trustworthy only works on those who already trust you. But as an untrusted peer, you don't get any shortcuts to get others to trust yourself or some other id of your choice.

On top of this, you could do all sorts of useful stuff, e.g.

• only replicate with peers below a certain trust threshold t
• only pass on data to the application layer that comes from an id below a certain trust threshold t
• strive to always keep up at least n connections to peers below a certain trust threshold t, guarding against eclipse attacks, while at the same time using the other connection slots for less-trusted peers to reduce the likelihood of network partition