Our friends at Tricycle will push through a zero-based karma system (no self-voting possible) sometime this evening. At present this will only cover future posts/comments - they may go back and revise history some time in the indefinite future (or not), but apparently that would be overly complicated for now. We'll see how this works.
New Comment
We've just deployed another related change: Now you can only cast as many down votes as your karma value.
I would assume you can only cast as many up votes as your karma value, too?
I'm not sure what the change accomplishes. Was there a thread on this I missed?
ETA: capping the up votes similarly will produce bad effects. :) But I'm still worried this tells legitimate lurkers "contribute written comments or we don't want to know when you think a comment/post is poor!"
Up votes aren't capped but your point about lurkers is interesting. The primary motivation for the change is to stop it being easy to just register an account then down vote everything you can find.
Then it should be possible to see how many down votes I've cast, to know how many are left. In practice, I expect that the number of downvotes is significantly less than the amount of Karma, but I'm not sure. If this is true, then the limitation is roughly equivalent to simply prohibiting people with Karma less than a threshold to downvote.
You are notified when you reach the limit by a message stating how many down votes you've made and what your current karma is. Until then I imagine you should not let this limit influence you:
Note: It is possible to see this message and the down vote count be greater than the karma due its dynamic nature.
You are notified when you reach the limit by a message stating how many down votes you've made and what your current karma is. Until then I imagine you should not let this limit influence you:
I disagree, I want to reserve that power for where I see fit to apply it. I would prefer to calibrate my behavior, so that I won't be left out unexpectedly.
If you reach the limit and encounter a post you really want to downvote you can always un-downvote a previous comment that you dislike less. That would be easier if the 'disliked' link showed comments as well as top level posts.
Yes, that's an obvious solution, but placing yourself in that situation is unnecessary, and implementing the amendment you suggest is a waste of time where the situation could be avoided in the first place.
You seem to be thinking of things from the point of view of 'I don't want to suddenly find I can't downvote', where I'm thinking of it from the point of view of 'what is likely to lead to the most informative karma scores'. I don't think you're wrong given where you seem to be coming from but I'm not looking at it from the same perspective.
This'll take getting some used to, mentally recalibrating myself to not consider 0 -point comments as bad ones. But a good change, nonetheless. :)
Great. I really hope that, when time permits, the folks at Tricycle can apply this retroactively as well. There are a few users who, despite posting comments of low quality, manage to have high karmas due to sheer frequency of commenting.
I don't see why it would be at all complicated to do. Shouldn't it just be something like
UPDATE comments c SET c.score = c.score - 1 WHERE c.post_date < 'some time today'
UPDATE users u SET u.karma = u.karma - (SELECT COUNT(*) FROM comments c WHERE c.author = u.id AND c.post_date < 'some time today')?
Some people were testing the system by deliberately not voting for themselves. Also, Reddit doesn't really run off a proper database. And there could be other consistency checks (I haven't looked at the code).
Last I spoke with Steve Huffman, he told me they were running on top of PostgreSQL, but maybe they switched to something non-relational in the most recent rewrite. Now you've got me curious; I'll check the source.
That's not the problem, apparently, it's that what Reddit built on top of the SQL is a huge list of key/value pairs or something like that - in any case it's not as simple as an SQL query.
I just finished going through the source, and while it's still Postgres-based, the schema just uses five tables: type, rel_type, thing, data, rel. So yes, it's fundamentally just a key-value store. I bet I could still whip up some SQL that would do the trick, though it would be a good deal uglier than the above.
This is pretty much right, it uses a big key value store. The issue with karma is that the Account record maintains the karma value but the vote is stored as a separate relationship between the Account and the Link (article). Generally is is not safe to update the database directly as it is necessary to keep the separate memcache coherent. Thus any changes must be done via Python code. Whilst such a change is possible and relatively straightforward I'm not sure its worth it. From what I've seen there are no truly obnoxious users on less wrong that need to be dealt with by such a change.
Do we still get an immediate karma point for posting a comment?
(I'll have answered my own question by posting this, and will edit with the answer momentarily.)
Answer: no.
testing
ETA: comment showed up with a zero score, and now displays without vote up/down links. Well done folks =)
Due to some users being unexpectedly limited from down voting by the prior change. The threshold is now four times your karma.
I thought the point was to limit people's ability to down vote. Wouldn't that be a reason not to change the threshold?
The main driver for the limit was to prevent someone registering one or more accounts and being free to vote everything down.
Well, in that case, we could just pick a threshhold and say anyone above that level gets the keys to the ammo closet.
ETA: Or the garden shed, to stick with the going metaphor.
I agree with this, but with no limit on upvotes, the hypothetical spammer could just register more accounts to give each other lots of karma, then use that one to vote everything down. But then, that's a problem for this system too.
Are we just chasing ghosts?
Are we just chasing ghosts?
For the moment, yes -- I don't see us being a high-enough priority target to be anticipating barbarians with torches and pitchforks. Still, if we go as far as we're hoping, it seems like a possibility.
The right model would perform some kind of flow analysis, starting from the vote graph. I guess there must be standard techniques in web search (linking as voting) and the like, that oppose spam linking (page rank? I haven't studied what it is).
You are looking for "attack resistant trust metrics". Google's PageRank is one such; Raph Levien's Advogato algorithm is another; my TrustFlow is a third.
I've wondered if it wouldn't be better to give relatively more weight to votes from people with high karma. I haven't proposed it because it seems counter-productive to escaping the dangers of an echo-chamber, and because it seems like a conflict of interest coming from someone with high karma.
The rule should be stateless: users vote, and it's data. Then, there's an algorithm that computes karma of users and rating of comments, starting from that data. Giving more weight to high-Karma users (adjusted for inadequate voting=significantly different from what others value, and for balance of votes) is similar to electing moderators, and ultimately roots in the founders' conception of what's on-topic, what's valued on this particular forum.
i agree. Have a karma based limit under a certain threshold, then, above that threshold, free reign.
would that mean that on default settings, a post or comment would be invisible until someone voted for it? Should I set my filters for -1?
I just finished going through the source, and while it's still Postgres-based, the schema just uses five tables: type, rel_type, thing, data, rel. So yes, it's fundamentally just a key-value store. I bet I could still whip up some SQL that would do the trick, though it would be a good deal uglier than the above.
This is pretty much right, it uses a big key value store. The issue with karma is that the Account record maintains the karma value but the vote is stored as a separate relationship between the Account and the Link (article). Generally is is not safe to update the database directly as it is necessary to keep the separate memcache coherent. Thus any changes must be done via Python code. Whilst such a change is possible and relatively straightforward I'm not sure its worth it. From what I've seen there are no truly obnoxious users on less wrong that need to be dealt with by such a change.