Idea #7: Anti-spam measures

Spam is an issue in many blogs, forums, ims, any communication. It is only an issue if it reaches a real person. Therefore, all actions and modifications to content made by untrusted persons will have to undergo some kind of review in order to not cause a spam problem. In the meantime, their content will have to wait, which is a tradeoff.

1 - Direct connection, XMPP style

Submit comes with token and user@server. That token is validated with that server for that user. Content is trusted to come from that user. No sign in required.

If users@servers are blacklisted, spam will still occur. Users may be required to register then and those registered users whitelisted. Who to trust to register? Lets go onto number 2:

2 - Ring of trust

Any user may register. However, not all are trusted. Trust can earned for user@server by asking server who vouches for user. If we trust any user that vouches for that user, we verify that with that voucher_user@voucher_server. If verified, we assign +rep trust from that user and store it locally with that user's registration. If the circle of trust is outside our scope of registered users, we go to number 3:

3 - Proof of work

User is asked to give a proof of work problem that an average user can handle. If this is solved correctly (maybe a captcha in addition or instead), the user comment is given to manual review. If a manual review is verified, that user is assigned +1 rep from the system.

Caveats

• You still need manual review. If your Proof of work is broken, manual verification can become unwieldy.
• User information must be sent with a comment. That user's server must be up at the time of connection.
• This system only works if trust from the system may be revoked (otherwise mistakes are permanent). Certain highly networked users might become too big to fail and if hacked, cause cascading registration issues (or conversely, solutions). Keeping track of a reputation as well as trust will help mitigate this, as users can be slowly trusted by the system due to reputation rather than relying solely on a brittle trust network.
• The circle of trust implementation here is very basic. The problem is that the server might not know which of its user's vouchers are registered with the site, and this information is private. This results in extraneous information. The 'who can vouch for me' information itself might be private as well. It would likely be better to send along the system name to the user when asking for vouchers. This way they can ask their vouchers who trusts that server and maintain privacy of their vouchers.
• This system does not allow for mass anonymity except through duplicate accounts.