User rating system

[mo]

This idea does not originate with me, I would just like to get people talking about it.

The Concept:
Every time you upload something, it's logged on one global server.
The data on the server generates a rating that others can request when your trying to download from them.
The more you upload the more you deserve a slot for download, or the more bandwidth you deserve.


Example:
Jim has uploaded 500mb in the last 5 days
Ed has only uploaded 50mb

When downloading from a standard client, let’s assume both users equally share the bandwidth. (20k/s each)
If they are downloading from a ratings enabled client, Jim would get 75% of the connection and Ed would only get 25% (30k/s - 10k/s)

Also, there could be an option to open extra slots for users who have a certain rating.
Jim would meet this rating, and Ed would just have to wait for a standard slot to open.


Benefits:
1) If an upload limiter was added to dc++, this would encourage people to set it reasonably.
2) People who support the community would be rewarded for doing so.


How To:
What information do we need?
I suggest the following table format... ID, FileID, UploaderID, ULSize, DownloaderID, DLSize
ID = Primary Key
FileID = MD5 Hash of path/file
UploaderID = MD5 Hash of uploader id/nick
ULSize = Size of file uploaded
DownloaderID = MD5 Hash of downloaded id/nick
DLSize = Size of file downloaded

How do we collect this information?
On successfully upload {
1) The uploader sends everything to the server except the dl size.
2) The downloader sends everything to the server except the ul size.
}

Why should both UL and DL client send information?
If both clients send information, it's easier to determine if people are abusing the system.

What is the rating based on?
The rating is based solely on the amount of data you upload.

Do I have a higher rating if I've been using this system longer than someone else?
No, the upload information is only saved for a few days. So uploads you did a week ago have long since been forgotten.


Well, this is just a starting point anyway...
Is this too much work for too little benefit?
[/u]

[raelin]

While a rating system is an interesting idea, it's a single point of failure. Given the commotion we've all had recently with regards to the public hubs list, where would this mega rating system be hosted from? Putting runtime dependancies on a particular location is probably not a good idea, and this really sounds like it should be a part of the hub software.

That being said, a client that is restrictive for no apparent gain (other than the gain to the commons) will probably not go over very well. In other words, you'd have to put a limiter on all uploads and then give bonus to the people who actually use the system or else everyone will use clients that don't log ratings, which brings up the whole uploads limiter argument.

[sarf]

By the by, I created this topic in "Protocol alley" a while ago. Go here to check it out.

While a rating system is an interesting idea, it's a single point of failure. Given the commotion we've all had recently with regards to the public hubs list, where would this mega rating system be hosted from?

There is no need to have only one "mega rating system". I envisioned every hub network having one, with smaller hubs sharing ratings servers. Of course, this would mean that each client can report to several ratings servers.

Putting runtime dependancies on a particular location is probably not a good idea, and this really sounds like it should be a part of the hub software.

Yes and no. The hub should be able to suggest a ratings server, but since that information can be shared in a PM (with a certain syntax to make "ratings enabled" clients interpret it correctly) or using an extended command $RatingServer or whatnot, there is really no problem with this.
I had thought that a "few good" ratings servers could be contained in the version.xml that every clients download anyhow, since that was the way I built in auto-updating of hublists in my modified clients. That gives the client somewhere to start.

That being said, a client that is restrictive for no apparent gain (other than the gain to the commons) will probably not go over very well. In other words, you'd have to put a limiter on all uploads and then give bonus to the people who actually use the system or else everyone will use clients that don't log ratings, which brings up the whole uploads limiter argument.

No, as a first step you introduce an upload queue, and then you order it based on the ratings so that rating is all that determines the position in the queue (or perhaps some combination using time spent queueing and rating). For this to work in a good way you'd have to have "auto-open slots when below X kb/s" enabled, since this way a highly rated client would become favoured but not to the point of annoying people (by always getting the slots before any other can get them).

The idea is to benefit ratings enabled clients, not to punish those that do not support the ratings.

Sarf
---
"Lord, please make me the kind of person my dog thinks I am."

[volkris]

Putting runtime dependancies on a particular location is probably not a good idea, and this really sounds like it should be a part of the hub software.

If a ratings server is down and so no ratings are available, the client should just assume that people are unrated. In other words, the ratings service can only help.

That being said, a client that is restrictive for no apparent gain (other than the gain to the commons) will probably not go over very well. In other words, you'd have to put a limiter on all uploads and then give bonus to the people who actually use the system or else everyone will use clients that don't log ratings, which brings up the whole uploads limiter argument.

Actually, with ratings in place clients can become MUCH less restrictive. That's a large part of the whole point. Once you have ratings to "encourage" people to do the Right Thing you no longer have to try to force it through the clients. You no longer have to deny users bandwidth limiters that would let them decide what to do with their bandwidth, you can implement a "never let users with names starting with 'l' download" feature without worry of abuse, heck you no longer even have to enforce a minimum share size, as people will be automatically encouraged to share more. The point is to fix the system that currently trusts users to do what's not in their best intrests.

Anyway, the key problem with what you just said is that nobody loses from putting a prioritization on his own uploads. Why do I care that one of the three strangers transferring from me is getting his file faster? If there is no loss but there is the gain for the commons then I might as well use it. Additionally we can build in a ratings jump for anyone actually reporting ratings. Suddenly those using the modified clients will automatically get priority over those without.

No, as a first step you introduce an upload queue,

We don't necessarily need a queue. We could just change the sending rates so that higher ratings mean more data in the output buffer. I don't know how it's actually done in DC++ but you get the idea. Perhaps we could also offer a queue that would only be available to those with ratings.

The idea is to benefit ratings enabled clients, not to punish those that do not support the ratings.

I couldn't have said it better myself
As always, reward good behavior, but don't punish bad. That will make DC strong.

[MeThinks]

I have an ADSL dynamic ip connection. The ip changes every x days - doesn't it mean that i'll loose my rating?

[MeThinks]

Oh, sorry, the idea is not to log the ip, but the nick. But still - there would have to be a registering system on each hub, since people are getting less imaginative and use popular nicks.

[volkris]

I have an ADSL dynamic ip connection. The ip changes every x days - doesn't it mean that i'll loose my rating?

Not necessarily. Who said ratings had to be tied to ip address?

We'll have to discuss it further, but as far as I'm concerned users shouldn't even be tied to one computer. You know, go over to your friends house and still use your hard earned rating to download from his computer.

We'll see.

[sarf]

No, as a first step you introduce an upload queue,

We don't necessarily need a queue. We could just change the sending rates so that higher ratings mean more data in the output buffer. I don't know how it's actually done in DC++ but you get the idea. Perhaps we could also offer a queue that would only be available to those with ratings.

One reason for the upload queue is that the idea of a queue is much less threatening than (gasp!) giving the users control over their bandwidth. Besides, no one (at least no one I know of) is happy with the current way the slots are distributed (free-for-all request hammering).
The other reason is that, due to certain experimentations of my own, a properly designed upload queue would be easier to implement than bandwidth-per-slot.

Also, an upload queue would be a Good Thing (tm) in itself - even without ratings.

Sarf
---
"We must cater to the idiots, so that we may corrupt them."

[GargoyleMT]

One reason for the upload queue is that the idea of a queue is much less threatening than (gasp!) giving the users control over their bandwidth. Besides, no one (at least no one I know of) is happy with the current way the slots are distributed (free-for-all request hammering).
The other reason is that, due to certain experimentations of my own, a properly designed upload queue would be easier to implement than bandwidth-per-slot.

Also, an upload queue would be a Good Thing (tm) in itself - even without ratings.

I agree, I think it's one of the features that people who've tried other P2P applications look for. However, doesn't a queue lose a lot of effectiveness when someone can stay on it for days? You can integrate a ratings system and have people wait based on all sorts of interesting criteria, but if the slots are semi-permanent, what does it gain you?

I think it's natural to have a permutation on the queueing algorithm apply to people in the queue. Or you could have a transfer or time limit instead (I don't think the file # limit offered by DC++k is too useful for this purpose, other than as a proof of concept).

One point worth bringing up is that the old users of DC might not like this idea too much, having grown accustomed to the current way it functions. And I can imagine scenarios when even the uploader would want to override any slot transfer limit or time limit.

This might be a topic to restart in the haven.

[sarf]

I agree, I think it's one of the features that people who've tried other P2P applications look for. However, doesn't a queue lose a lot of effectiveness when someone can stay on it for days? You can integrate a ratings system and have people wait based on all sorts of interesting criteria, but if the slots are semi-permanent, what does it gain you?

"Well, then, what do you think we should stop doing?" (sem-changed quote from Futurama).

Slots should not be permanent. "Idling" of slots should be a bannable offense. FYI, "idling" is when someone starts a connection and does small requests on it to keep it from timing out (I think requesting file sizes would do the trick, but I've heard people using the "redownload filelist" trick).

I think it's natural to have a permutation on the queueing algorithm apply to people in the queue. Or you could have a transfer or time limit instead (I don't think the file # limit offered by DC++k is too useful for this purpose, other than as a proof of concept).

Eek. That code was done... well... ages ago. It was a first try. Not even a proof of concept, merely me fiddling around a bit (as I am wont to do).

One point worth bringing up is that the old users of DC might not like this idea too much, having grown accustomed to the current way it functions.

Yes. While this would be sad, I would also point out that the usual DC system of semi-permanent slots, slot hammering and so on are not practices that are beneficial, and that I will create a DC++k client with abusable features such as those if DC++ is threatened by such stupid arguments. Since, at this time, my version is hard to detect, they would have a problem. A big problem. A problem that, by sheer happenstance, would be solved by using queues. While I do not like the image I would have as "Saviour of the Leechers", I dislike people that are against necessary progress even more - and to stop people from thinking "well, let's implement queueing when we need to, right?".

And I can imagine scenarios when even the uploader would want to override any slot transfer limit or time limit.

Of course - the first thing that springs to mind are granted slots, which should automatically bypass these restrictions.

This might be a topic to restart in the haven.

Probably.

Sarf
---
Most people do not know how to behave in a massacre.

[volkris]

I agree, I think it's one of the features that people who've tried other P2P applications look for. However, doesn't a queue lose a lot of effectiveness when someone can stay on it for days? You can integrate a ratings system and have people wait based on all sorts of interesting criteria, but if the slots are semi-permanent, what does it gain you?

One point to consider is that just because you have a queue doesn't mean it's particularly long. I'd say a single slot queue would be pretty all around good. I mean, such a thing would basically just be a way to notify of the availablility of an upload slot without polling. More of a information passing thing than anything else.

A single slot queue would also hopefully not sit there unchanged for days.

Perhaps, though, instead of a straight queue this thing should be seen as a pool. Continuing the paradigm of just an information passing structure, this pool would be people registering their interests in attaining an upload slot. When an upload approaches completion, the uploader could decide which pool member it wants to give the next slot to (based on ratings, reported speed, length in the pool (a queue), or even file requested, if implemented).

But all of this is kind of obvious. The whole point is to increase efficiency here. If nothing else a queue/pool would allow the next transfer to begin immediately while also lessening the worth of hammering. At best it will allow the client to optomize its upload strategy to most effectively serve DC.

[GargoyleMT]

"Well, then, what do you think we should stop doing?" (sem-changed quote from Futurama).
Slots should not be permanent. "Idling" of slots should be a bannable offense. FYI, "idling" is when someone starts a connection and does small requests on it to keep it from timing out (I think requesting file sizes would do the trick, but I've heard people using the "redownload filelist" trick).

Very well, I think that even a user gets a slot, an algorithm should still apply to see if they should continue to get the slot. Without the rating system, this would have to be pretty simple, as in a time or size limit. I think in any case there should be set a minimun reasonable length of stay in the queue, much like there are 3 mini slots and 16kb is the small file threshold. As far as what to do when they're no longer transferring large files, I think there are a number of ways to try to keep a slot, and they should be thought of and fixed or counteracted. Beware this "banning" thing, though, as this is not measurable to the hub, so it seems natrual that you mean a client side ban, which comes with a ton of dangers.

Yes. While this would be sad, I would also point out that the usual DC system of semi-permanent slots, slot hammering and so on are not practices that are beneficial, and that I will create a DC++k client with abusable features such as those if DC++ is threatened by such stupid arguments. Since, at this time, my version is hard to detect, they would have a problem. A big problem. A problem that, by sheer happenstance, would be solved by using queues. While I do not like the image I would have as "Saviour of the Leechers", I dislike people that are against necessary progress even more - and to stop people from thinking "well, let's implement queueing when we need to, right?".

Well, wouldn't we likely be the ones playing with and implementing the queues, anyhow? But I agree, this is similar to the upload throttling debates already.

This might be a topic to restart in the haven.

Probably.

Except Volkris doesn't have access there. And isn't the features forum supposed to be for controversial features? Hmmm.

On a side note, have you looked at the BCDC code at all? It seems to have a rudimentary queue already. The majority of the features could be done client side, with no modifications to the remote side. Just track entry into the queue, mean frequency of checking for open slots (which should be 60s for th first two tries, 50s every try after - from the ConnectionManager code), and whatever you want to weight them on. Just hold the slot open for someone, until they're past their checkin time plus a margin of error, and then designate the slot for the next person in line.

Of course, you can make anything sound simple by talking about it just right.

Cheers!

[bozo]

I think this idea wasn't worth bringing up in the first place. ANy system like this would be beat by folks hacking the data.

[GargoyleMT]

I think this idea wasn't worth bringing up in the first place. ANy system like this would be beat by folks hacking the data.

Er, hacking the ratings server? How would one do that? The ratings are all stored remotely, there's no local data to hack.

[sarf]

Very well, I think that even a user gets a slot, an algorithm should still apply to see if they should continue to get the slot. Without the rating system, this would have to be pretty simple, as in a time or size limit. I think in any case there should be set a minimun reasonable length of stay in the queue, much like there are 3 mini slots and 16kb is the small file threshold. As far as what to do when they're no longer transferring large files, I think there are a number of ways to try to keep a slot, and they should be thought of and fixed or counteracted. Beware this "banning" thing, though, as this is not measurable to the hub, so it seems natrual that you mean a client side ban, which comes with a ton of dangers.

What dangers? Coupled with the rating server this is not a problem. If we don't have a rating system... well, then client-side bans are the least of our problems, aren't they?

Except Volkris doesn't have access there.

Too bad for him. Neener neener neener!

And isn't the features forum supposed to be for controversial features? Hmmm.

It sure is, but that is not what it is used for. Unfortunately.

On a side note, have you looked at the BCDC code at all? It seems to have a rudimentary queue already. The majority of the features could be done client side, with no modifications to the remote side. Just track entry into the queue, mean frequency of checking for open slots (which should be 60s for th first two tries, 50s every try after - from the ConnectionManager code), and whatever you want to weight them on. Just hold the slot open for someone, until they're past their checkin time plus a margin of error, and then designate the slot for the next person in line.

I agree. This should not be hard to implement. Just implement a min/max time for connection hammering. Max time would be the timeout value and should be rather high, min time the least time acceptable between connection attempts and if the min time is violated Y times the client is removed from the queue (and has to reconnect and is then placed last in the queue).

Of course, you can make anything sound simple by talking about it just right.

Better than making it sound very hard to do.

Sarf
---
Mine is longer than yours.

[NoFiX]

This is a rediculous idea. You've got newbies coming to DC on a regular basis. This would do nothing but put a shunt on their activeness in the community. Not only that but the current DC protocol is so easily defeated, it would be rediculously simple to create something to thwart your ratings high while at the same time bringing down the ratings of others.

[GargoyleMT]

This is a rediculous idea. You've got newbies coming to DC on a regular basis. This would do nothing but put a shunt on their activeness in the community. Not only that but the current DC protocol is so easily defeated, it would be rediculously simple to create something to thwart your ratings high while at the same time bringing down the ratings of others.

What you see here is just a small echo of the thread in the Protocol forum. If you can make such accusations after reading it, please be my guest.

[NoFiX]

I'm sorry the problems with this idea arn't obvious.

"Hey cops! look at me, I have the highest ranking in supporting piracy! BUST ME FIRST!"

Fuckin idiots.

[mo]

seems that you have yet to figure out that all the information held on this server is anonymous

but way to show your great language skills...

[NoFiX]

Is it held anonymously? Really? Wow. Could you please convert that to English for me? You're in effect saying, what? That anyone would have access to the ranking information, without question, just like I already suggested.

Let me put it this way; if DC++ would be able to discern users from each other and rank them accordingly(for the que), anyone that downloads the DC++ source code could alter it so those same rankings could be requested at will and used accordingly.

Greedy people use DC++, it's obvious enough already, isn't it? I mean you guys want to implement a system that gives someone with more bandwidth a better chance at getting a slot before someone that's already waited in line for days(this happens enough as it is, let alone with this silly method of ranking).

Greedy fucks.

[GargoyleMT]

Greedy people use DC++, it's obvious enough already, isn't it? I mean you guys want to implement a system that gives someone with more bandwidth a better chance at getting a slot before someone that's already waited in line for days(this happens enough as it is, let alone with this silly method of ranking).

Now that's a constructive point. At least one of the measures, of uploads, can be abused by people with fast connections, even if they don't stay around to "contribute" to the community. Volkris wanted some other measurements, like connection stability, or time spent serving, which could work to couter that imbalance.

Another valid question is: Iis the new "broken as designed" system (to paraphase you) better than the current broken as designed system?

[mo]

Is it held anonymously? Really? Wow. Could you please convert that to English for me?

What I'm saying is... the information is held using hashes.
I'll stop using developer's language and tell you what a hash is.

It's a one way encryption method, like CRC or MD5.
once the hash is created it can't be reversed.

If person A wanted to know person B's rating, he would generate a hash of person B using some known user information (ip, nick, connection speed, etc...).

for this example well say the result is 1234ABC

The user askes the server what the rating for 1234ABC is
The server returns the rating cooresponding to the user

pretty useless information if you were looking at the tables of data trying to figure out who user 1234ABC is

[volkris]

I hope nobody looks at the direction of this thread and considers it as the state of the proposal. In particular all of NoFiX's concerns expressed here are entirely unfounded, but it's been covered in Protocol Alley.

In short, there is nothing illegal about transferring raw data, which is the only thing the ratings server would know about. The Feds would still have to use other methods to figure out WHAT you're sharing, which is the only grounds on which you'd be breaking the law by sharing illegal things on DC.

Any "bad guys" could get the entire logs of DC and even your entire share list but still would be unable to prove that you made a single illegal transfer. They could still bust you for making illegal transfers available, but this would be discoverable through your share lists, part of the DC protocol right now having nothing to do with a ratings system.

Next is the issue of newbies on DC. This system would be completely transparent to newbies and anyone else who just doesn't want to think about it. The tremendous increases in efficiency in sharing and transferring would affect everyone, from newby without a rating to the highest rated person in the hub.

Finally, the rating system would make it useless to try to defeat the DC protocol (which is itself not easy to defeat at all... a very uninformed comment from NoFiX) by focusing on the actual goals of the system. If done properly it will be impossible to defeat the system of ratings, and this has nothing to do with the infrastructure but rather internal server structures, meaning that it will be easy to calibrate for maximum effectiveness.