Sapporo wrote:In reality this whole system being discussed is a Karma system, and there is no use in calling it anything else.
While the word "Karma" is cute and all, it has connotations that are completely opposite what the aim here is. If you don't pick up these differences with the rest of my response I can go into more detail on this.
It's taken me a couple of hours of reading to figure out just what this "ratings" system will cover (all in one sitting too!).
Yes, we need to generate some webpages clearly expressing the purpose and goals of the project. Rooting through a developers' mailing list is never the best way to get to the heart of a project.
Said simply, Karma is a representation of your contribution to the community. People with a good/high Karma should be rewarded as they have helped the community grow. [...] People with a lower Karma should not be negatively affected, but the won't get the VIP treatment.
I could hardly disagree with more things in the above quote
Karma is a representation of.... ummm.... some abstract concept of amount of good. As such, people who have been good and thus have high Karma should be rewarded, yes, but most interpretations of Karma would see nothing wrong with punishing people with bad Karma. In fact, most day to day use of the word Karma (at least in my part of the world) is associated with bad things happening to a person with bad karma.
It's quibbling over words, but a ratings system, to me, implies a much more mechanistic, deterministic, and practical device. In my opinion we WANT the ratings system to sink into the background where people will hardly ever think of it again. Once the get the picture that sharing more is good the rest of the effects of the system will only be relevent to client developers. "Ratings system" should be on the same level as "IP address", not "client skin".
First I think the boundries of the Karma system need to be defined. The DirectConnect network is a decentralized Peer2Peer network which I'm sure your all aware of. With that being restated, a HUB considers itself to be the only HUB in the entire universe. There are no alien lifeforms, and it doesn't communicate with them. Implementing a Karma server that multiple HUBs can utilize will inevitable fail in my opinion; for a few reasons.
It's ironic that you start right in saying that DC is decentralized and then immediately throw up a centralized view of the thing. But no matter.
Hubs don't necessarily communicate with the ratings system. The ratings are there for clients to use, not hubs. One of the biggest flaws in DC is the mindset that the hub is the center of the universe. A proper view of the system would be much more considerate of the clients. One of the things that the ratings system does is to empower clients, irrespective of their hubs. This actually ends up being good for both clients AND hubs.
Since each HUB considers itself to be alone, it implements it's own rules. [...] If I have a HUB, why would I want to share my users ratings with another HUB?
Hubs currently implement these rules as a very, very poor measure to improve quality of sharing going on. DC is flawed in that such patches are necessary to keep the whole thing from crashing. With a ratings system in place these rules become much less needed and the quality of sharing can go exponentially beyond what even the most effective rules could hope to provide.
As for the question of why share user ratings, who cares? You're a hub. Your job is to route messages from one client to another. You mind your business and let the clients mind theirs.
I think that a HUB should be the level of granularity for what is considered a community.
Of course you do, you have a centralized, hub-as-the-center view of the world. I, on the other hand, recognize the value of the clients and let the clients chose what communities they consider to be the proper level of granularity. Normally this will probably be at the hub level, but not always.
This also makes sense, considering that most HUBs are theme based communities. For example if I join an Anime HUB and share only porn, am I contributing to that community?
If people download the porn from you, then yes, you are contributing. If people don't download from you because you don't have Anime then no, you're not contributing. The ratings system will rate you as to your ACTUAL value to the community, not the value you're "supposed" to have based on the community's stated rules.
Another thing to consider is the fact that I bet most HUB operators will implement their own Karma server (which might be a moot point see below about Karma Benefits).
And under the proposed system they have every opportunity to. However, also under the proposed system the actual location of the server and its relationship to other servers is completely irrelevant. What I mean is that I could set up my server and you could set up a different server, but in the end it will work no differently from us setting up a single server. The decision as to which way to go here becomes matters of trust of server admin and hardware constraints.
Also, I should point out that the Karma system should be an optional system that the HUB can implement. It should also be implemented so that clients that don't support Karma will still continue to work. It still could be required by a HUB though.
The proposed system is completely optional, benefiting those who participate while not directly injuring those who don't. However, it isn't the hub implementing it. The user is implementing it. Like I said, the hub needs to go back to routing messages and let the user make sense of ratings. Finally, it is technologically impossible for a hub to require it in any implementation without causing massive problems. And you wouldn't get any real benefit out of it anyway.
Next I think Karma should be defined. What is it? What contributes to having a good Karma? How is Karma calculated? How does time and history affect my Karma? Some basic questions that I don't think have been answered because we are stuck on this 'rating' concept.
Not at all. They are answered, and the answer is "let the user decide". Problem solved
I don't think this should be based on a value that can go up or down like a rating.
Of course they should go up and down in response to the user's activities on DC. Otherwise you'd have all of the massive misuse of the system that exists now.
(Ok, I'm too tired to figure out a way of doing this right now. Basically, all of the above people should have a similar Karma. Looking at that I wonder if the contributed amount should also be limited to a week of data like availability. With a total contributed stored seperately.)
Answer: let the user decide.
Anyway, the users you mentioned above got their ratings in very different ways. That they have the same ratings would mean a very poor metric is being used, seeing as different users in different situations WILL want different aspects of the subject's profile to be positive.
Take for example the difference between a mp3 fan wanting high burst rates while a movie fan would want stable connections.
Anyways, I think that Karma Benefits need to be defined as they are the reason to use the system in the first place. If it's impossible or diffult to award benefits I want, then why use the system? Suggestions on this? (I maybe forgeting some others that were mentioned.)
Well here's the simple answer: we'll bully you into using it.
If by not using the system you are having a 2% harder time downloading, then by holding out you're hurting yourself.
Here's a longer answer: you have no choice in the matter. If you upload to someone who is participating then you're in the system. You will never necessarily have any way of knowing if you're uploading to someone participating, and so you are forced to accept it. If you're going to be getting points for it you then might as well step up and accept them.
Ratings benefits CANNOT be defined because we're not omnipotent and therefore cannot forsee all possible benefits to having higher ratings. All we can do is say that at least you
might stand a higher chance of grabbing download slots if you participate.
A lot of what you went into detail above has been already discussed in this thread. That the rewarding of priority on downloads has to occur on the clients, for example, is a fundamental part of the proposal.
Another fundamental part addresses you question of when to report. This will be reported at various times during file transferrs. At the beginning and end, certainly, but also occasionally throughout.
Security is not a big deal to us simply because in such a distributed system it will be almost impossible to make a significant false impact on a user's ratings without basically owning most of the hub, at which point you have bigger problems to worry about. We have discussed a couple of simple measures to make it more difficult to forge reports, but on the whole there is only so secure that a system can get and this is not a problem.