[_8j50]

First, you will get many frowns for '| sudo sh' installation. For all the crypto you use I would expect signed installers or packages,not a URL,but these are somewhat cosmetic hair-splittings.

My real feedback: I personallh despise +/- voting systems to measure reputation, these systems can be gamed, you'll have to actively moderate fraud (if possible) and sybil attacks.

My suggestion, 1) just collect transactional and contextual telemetry and let clients decide how to measure reputation. 2) Similar to #1, require contextual inputs for transaction. Context about the user, the voter,the nature of the post or transaction (tags?) and output a network verdict but still allow clients to override network metrics. For example, a client can distrust or give a 10x multiplier for votes from a poster/user, or add a 10x multiplier on negative reps for certain types of transactions.

IMO, if you make reps a client only feature,you can adopt to threats and come up with better rep measurement by simply updating clients with a new version without worrying to much about how many people use a certain version.

[fsantanna]

Thank you! To install, `sudo` is not even required, so I'll change the default script. I understand that designing any kind of distributed consensus is somewhat disputable (if not pretentious), but I'm not convinced that client-side decisions are enough. For example, local reputation would not prevent posts from new users to be linked in the dependency graphs forever. Client rules can still override the network for posts that are not blocked. In fact, this reputation system is more about preventing abuse from new users and in some cases mistakes or hacked accounts from old users. I think there's still space for experimentation on global consensus besides PoS (S=something). In this particular system, reputation/consensus is local (per-topic) and depends on its own resources (posts) as well.