4 ms·

> the financial incentives to be a bad actor could very quickly outpace the incentives to be a good actor. This def is an unfortunate truth of many of our onli

> the financial incentives to be a bad actor could very quickly outpace the incentives to be a good actor. This def is an unfortunate truth of many of our online systems. Any ideas on what a reputation system needs to work? Or do you think the general way it tends to get implemented would suffice?

packetlost 2y ago
Reputation is notoriously difficult, but I have some ideas on how you could manage it in a decentralized-ish (I'll get to the "-ish" part later) manner that can't easily be gamed: - Nodes discover each other via DHTs or DNS records - Nodes peer with other nodes - Node administrator selects a subset of "trusted" nodes. In practice, this creates centralization, but is important for bootstrapping... - Nodes use the list of trusted nodes to calculate a reputation score. The reputation score is a float. The reputation score of a node starts at 0.0 and may be influenced by administrator-decided metrics such as spam detection, user interaction, or manual intervention to boost or deboost a score. The score is also weighted against the "opinion" other nodes have of that node, with a higher weight placed on trust the previously selected "trusted nodes" - Nodes that fall below some threshold do not get events forwarded but do still get their reputation tracked and shared with other nodes There's a bunch of details that need to be enforced by the network to ensure this works: nodes identity is at least partially tied to an IP address. All communications are signed using an alternate PKI web of mutual signature chains and trust. Reputation assertions are digitally signed and virtually unforgeable. Nodes may have different classes for serving different purposes. For example, nodes whose role is exclusively to provide a reputation score to other nodes should be common and may chose to collect payment for verifying a node (yes, pay to play is a requirement for a healthy ecosystem). Other nodes may exist exclusively for spam filtration purposes and provide reputation scores based on heuristics. Bake in a few heuristics into user interaction (blocks, reports, etc.) that in a reference implementation translate into dings in reputation scores should incentivize admins to police appropriately but should be weighed against echo chamber effects that may result. I've thought about this rather extensively. Email is a great blueprint for this, but relies on protocols that make it very difficult to implement some of these features and so struggles to this day with spam management.

packetlost 2y ago

Reputation is notoriously difficult, but I have some ideas on how you could manage it in a decentralized-ish (I'll get to the "-ish" part later) manner that can't easily be gamed: - Nodes discover each other via DHTs or DNS records - Nodes peer with other nodes - Node administrator selects a subset of "trusted" nodes. In practice, this creates centralization, but is important for bootstrapping... - Nodes use the list of trusted nodes to calculate a reputation score. The reputation score is a float. The reputation score of a node starts at 0.0 and may be influenced by administrator-decided metrics such as spam detection, user interaction, or manual intervention to boost or deboost a score. The score is also weighted against the "opinion" other nodes have of that node, with a higher weight placed on trust the previously selected "trusted nodes" - Nodes that fall below some threshold do not get events forwarded but do still get their reputation tracked and shared with other nodes There's a bunch of details that need to be enforced by the network to ensure this works: nodes identity is at least partially tied to an IP address. All communications are signed using an alternate PKI web of mutual signature chains and trust. Reputation assertions are digitally signed and virtually unforgeable. Nodes may have different classes for serving different purposes. For example, nodes whose role is exclusively to provide a reputation score to other nodes should be common and may chose to collect payment for verifying a node (yes, pay to play is a requirement for a healthy ecosystem). Other nodes may exist exclusively for spam filtration purposes and provide reputation scores based on heuristics. Bake in a few heuristics into user interaction (blocks, reports, etc.) that in a reference implementation translate into dings in reputation scores should incentivize admins to police appropriately but should be weighed against echo chamber effects that may result. I've thought about this rather extensively. Email is a great blueprint for this, but relies on protocols that make it very difficult to implement some of these features and so struggles to this day with spam management.