Followers of the Redirect

Site Announcements
Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Followers of the Redirect

Post by Pietry » 04 Feb 2010, 20:20

Today we had a great drama discussion on the hub, about whether to disable the auto follow redirects option or not by default in DC++.

At first glance, this issue is quite insignificant, but looking deeper I can see really big issues behind it.
Poy's idea is to auto disable the auto follow redirect. This means the option can be enabled somewhere in the settings, if the user wants it. First of all, is it clear to me that this option will not be altered by the vast majority of DC++ users. They will leave it as it comes with the fresh installation of the program.

I will first present poy's arguments to this decision:
  1. The option is annoying, makes you go to some hub you did not wish to connect
  2. The hub will be placed in the recent hubs tab ( will be available in next version ), which in the case of multiple follow redirects will make the list "dirty".
  3. It solves a priori a bug in ynhub where users could be redirected by some weird chat messages.
  4. Favorite hubs will be actually some start hubs for a chain of redirects that will eventually lead to the same hub, and it's useless to pass through all those hubs to reach the same hub ( also waste of time and space connecting to all those hubs ), and the favorite hubs list will actually be a ghost list. It's possible to actually have the same hub in the favorite list, but under different ghost. ( same goes for recent hubs list ).
If there were more arguments, I kindly ask people to reply to this post.
  1. Users on DC want mainly to download. They open up the client, connect to their hubs, or some hubs picked randomly and their first priority is to have a place to search and download. They are not interested if the hub name is Blacky the monster in the bathroom or Toast's hiding place. That is irrelevant. They actually are pleased if they get somewhere in case they don't have enough share or they are banned. I for one would rather get in some other hub instantly , rather than look for it somewhere else. This applies to the vast majority of leechers on DC.
  2. The recent hubs tab's purpose is to show the recent hubs. What is wrong with that? In the case of a chain redirect, one can either count Recent hubs as only fully connected hubs ( personally i want to remember the hubs I was trying to connect too ), or keep them all and in this case there is no sense in calling the list dirty.
  3. Solving a bug in ynhub is not why you modify a feature in some other program. And, this doesnt solve the bug, ynhub still has it. The problem with redirecting is because of bad software and/or misused software.
  4. Indeed, but counting in balance: a) chain connect until you get to some hub b) hammer connection forever , i strongly suggest the first variant. Eventually, user will just hammer every hub with no place to connect to, which can lead to a disaster per total in the world of DC.
Beside this arguments, removing the default value of the option can bring the following problems:
  1. users have no place to go after being banned or restricted, like not fulfilling the minimum share requirements. This means more stress on the user to find another hub, also leakage of users around the network.
  2. hammering connections on all hubs will significantly increase load and bandwidth and will kill the servers.
  3. waste of resources on the client as well as more and more hubs user is trying to connect to will get to the hammer state.
  4. no more redirect possibility for the hubowners, user balancing between hubs will be gone, networks of hubs will be gone.
  5. level of trust in DC++ will go down because users will not know what is going on, instead of becoming user friendly and take the best decision for the users, DC++ will make the exact opposite, this way the ease of usage of DC++ will get lower.
Indeed, the experienced user may/may not disable this option , but the vast majority of users will not and will not care. I agree that auto redirects is annoying sometimes but here it's not about you and me want, its about what the majority of users do. They need to be redirected so that everything works in the network. Otherwise the consequences are severe. Personal opinion has nothing to do with this.

I am asking you whether the option should be on in DC++ or not.
Just someone

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: Followers of the Redirect

Post by poy » 04 Feb 2010, 22:21

hi,

thanks for the write-up and nicely presenting my arguments, i was starting to feel bored of re-stating them... :D

first of all i want to remind that all the change means for the user is that when his DC++ gets a redirect demand, the client won't blindly follow the redirect request but invite the user to push one button. i doubt this is the end of the world.
and for the people who have too many hubs on redirect and can't be bothered to update them, the option is still there, one check-box to check to enable it.

now allow me to present a few counter-arguments...
Pietry wrote:Today we had a great drama discussion on the hub, about whether to disable the auto follow redirects option or not by default in DC++.
"drama"? it didn't even reach the point of "heated discussion". ;)
Pietry wrote:Users on DC want mainly to download. They open up the client, connect to their hubs, or some hubs picked randomly and their first priority is to have a place to search and download. They are not interested if the hub name is Blacky the monster in the bathroom or Toast's hiding place. That is irrelevant. They actually are pleased if they get somewhere in case they don't have enough share or they are banned. I for one would rather get in some other hub instantly , rather than look for it somewhere else. This applies to the vast majority of leechers on DC.
i prefer a client that caters to fair users by default than leechers. said leechers can still turn the option on if they want to...
Pietry wrote:The recent hubs tab's purpose is to show the recent hubs. What is wrong with that? In the case of a chain redirect, one can either count Recent hubs as only fully connected hubs ( personally i want to remember the hubs I was trying to connect too ), or keep them all and in this case there is no sense in calling the list dirty.
i don't see why one would want to keep hubs one has been rejected from in the recent hub list. and when one hubs redirects you to 4 different hubs down the pipe, it does create a visual mess in an otherwise nice function. i don't want first-time users who may get used to this feature and dragged away from having to /fav every hub to have their recent hub list polluted in these cases.
redirection has to be a conscious decision that a different hub is going to be joined, be it by asking the user to press a button or by making him turn on a potentially polluting setting.
Pietry wrote: Indeed, but counting in balance: a) chain connect until you get to some hub b) hammer connection forever , i strongly suggest the first variant. Eventually, user will just hammer every hub with no place to connect to, which can lead to a disaster per total in the world of DC.

hammering connections on all hubs will significantly increase load and bandwidth and will kill the servers.
this is wrong, one simply has to disconnect the user with a QUI message that contains a TL param (may be combined with RD in case of a redirect). DC++ will respect this time-out.
Pietry wrote:no more redirect possibility for the hubowners, user balancing between hubs will be gone, networks of hubs will be gone.
if networks are based on one particular implementation of a feature that can be disabled to run correctly, this might be the right time for them to start valuing users and not bounce them around wherever they see fit. by default, i want the user to have control on this; if the user wants to give away some of this control by enabling the option later on, so be it.
Pietry wrote:level of trust in DC++ will go down because users will not know what is going on, instead of becoming user friendly and take the best decision for the users, DC++ will make the exact opposite, this way the ease of usage of DC++ will get lower.
ease of usage might get a bit lower (pressing one button is so complicated) but at least, the trust users have in their DC++ will become higher because they will know that their client won't connect to some random place without them having be noticed about it before hand.
Pietry wrote:I am asking you whether the option should be on in DC++ or not.
the option is still here, you are asking what default value it should have? i vote "no"! :)

thanks for providing me with a place to write my arguments that won't disappear in long lines of log. :)

Pietry
Senior Member
Posts: 328
Joined: 04 Dec 2007, 07:25
Location: Bucharest
Contact:

Re: Followers of the Redirect

Post by Pietry » 04 Feb 2010, 22:55

poy wrote: i prefer a client that caters to fair users by default than leechers. said leechers can still turn the option on if they want to...
This isn't about fairness, what I said applies to all users.
poy wrote: i don't see why one would want to keep hubs one has been rejected from in the recent hub list. and when one hubs redirects you to 4 different hubs down the pipe, it does create a visual mess in an otherwise nice function. i don't want first-time users who may get used to this feature and dragged away from having to /fav every hub to have their recent hub list polluted in these cases.
If I connect manually to some hub and it rejects me, it means I'm polluting the recent hubs list ? Or that that hub should not be placed in there ?
poy wrote: redirection has to be a conscious decision that a different hub is going to be joined, be it by asking the user to press a button or by making him turn on a potentially polluting setting.
Users dont want to be conscious of everything that happens with their client, some things are managed by computers this is why we use them. DC++ should ask every time it adds a new source for some file it found ? The program must be simple and easy to use and serve it's purpose. To be asked each time i get a redirect would be only nagging and it would surely piss off very fast.
poy wrote: this is wrong, one simply has to disconnect the user with a QUI message that contains a TL param (may be combined with RD in case of a redirect). DC++ will respect this time-out.
It currently does? What about NMDC which is 99,99 % of all hubs ?
And what is the point in adding a TL param to a redirect ? Client should connect to the given address not try to reconnect to the same hub it was disconnected from in the first place.
poy wrote: if networks are based on one particular implementation of a feature that can be disabled to run correctly, this might be the right time for them to start valuing users and not bounce them around wherever they see fit. by default, i want the user to have control on this; if the user wants to give away some of this control by enabling the option later on, so be it.
I think you're acting like an irrational parent to a not so naughty child in here. This is not about teaching ethical lessons to some people.
As I said in my first post, this is not about bouncing users around wherever they see fit, it;s about moving users to places where they can use the network, eg share and download. They are thankful to the hubowners for providing alternatives to "youre banned " or " not enough share" messages keep repeating endlessly.
poy wrote: ease of usage might get a bit lower (pressing one button is so complicated) but at least, the trust users have in their DC++ will become higher because they will know that their client won't connect to some random place without them having be noticed about it before hand.
Their client will be a nagger and trust will surely fall when they see DC++ doesn't connect to any hub anymore ( this will be the end result ).
Just someone

LadyStardust
Newbie
Posts: 2
Joined: 01 Jun 2008, 17:28

Re: Followers of the Redirect

Post by LadyStardust » 05 Feb 2010, 00:10

Indeed it is a matter that everyone can discuss for weeks. My opinion... as an operator and everyday DC user:
Pietry wrote: The option is annoying, makes you go to some hub you did not wish to connect
Untill i can get files i want, i dont care which hub i am connected to, DC is mainly for downloading.
Pietry wrote:Favorite hubs will be actually some start hubs for a chain of redirects that will eventually lead to the same hub, and it's useless to pass through all those hubs to reach the same hub ( also waste of time and space connecting to all those hubs ), and the favorite hubs list will actually be a ghost list. It's possible to actually have the same hub in the favorite list, but under different ghost. ( same goes for recent hubs list ).
This is natural state of connecting to hubs, user get redirect for many reasons, it is better to follow the chain of redirects and end up in some other hub then just be disconnected and end up with no hubs (in case where user will be banned/redirected in all of 10 hubs he is connecting to with autostart, at the end he ends up being disconnected and won't be able to download - where most of user will just turn off DC++ and won't come back to it)
Pietry wrote:no more redirect possibility for the hubowners, user balancing between hubs will be gone, networks of hubs will be gone.
Well... hubowners and networks are surely based on redirects. Here it would cause many more problems then we can think of at the moment. Few scenarios:
- in times when hubowners rent place on outside servers for a hub and hubsoft then is restricted with max users allowed per hub, what will happen with all the rest of users who could not "fit in" those restrictions?
-hubowner have to start hosting his own hub on his own connection but his bandwidth won't handle 2000 users, he will set up max users in a hubsoft to 1000 ... so what will happen to all clients that wont follow redirects. Users choose to connect to big hubs from hublists, nowdays our "big hubs" are getting smaller and smaller, it is not about how big the hub owner has but how many sources of download is there for a user.
-hub with min share 100Gb will redirect everyone below that share, share can be 80Gb and perflectly "clean" but user is not following a redirect and ends up nowhere.
Pietry wrote:level of trust in DC++ will go down because users will not know what is going on, instead of becoming user friendly and take the best decision for the users, DC++ will make the exact opposite, this way the ease of usage of DC++ will get lower.
This is very true and i see it everyday, register users manually every day, helping to set up clients etc... Users are lazy, sometimes stiupid, sometimes dont have enough knowledge about computing, never read "help" files etc. They leave for torrents and other p2p, they compare DC with other p2p. Old users won't understand why their updated client is not following redirect/not connecting to hubs it used to, and will leave. New user won't be able to connect to hubs , will leave to other p2p.
poy wrote: ... for the user is that when his DC++ gets a redirect demand, the client won't blindly follow the redirect request but invite the user to push one button. i doubt this is the end of the world.
The end of the world for me is when user can't properly type /fav in a hub he wants to add into favorites, i don't think that user will know which button to press to follow redirect, will there be any information for this user what to do to be connected to hub where he was redirected to? or he has to read "Help" content to find out? (of course i mean users who actually check what is going on in hub tabs).
poy wrote: i prefer a client that caters to fair users by default than leechers. said leechers can still turn the option on if they want to...
I agree but... p2p is a world of leechers and we can't do much about it. Unfortunetely all those first time users wont share, because they dont know how. Human's nature is to leech... how many users actually start DC++ with share? When i got my first DC client i had no share, but i was banned and redirected to another hub where i got simply warned and i was tought how to add share. In other p2p there is no need to share most of the time, and first time users are sometimes too lazy to figure out what went wrong just by reading "ban reason".
poy wrote: if networks are based on one particular implementation of a feature that can be disabled to run correctly, this might be the right time for them to start valuing users and not bounce them around wherever they see fit. by default, i want the user to have control on this; if the user wants to give away some of this control by enabling the option later on, so be it.
Managing hubs by hubowners is based on all DC features; clients and hubsofts. Hubowners, netowners build systems based on what was given to us by devs. Please dont take away from us something you gave us few years ago and something we work on/with because it works well. Multisource changed face and system of running hubs few years ago, so as you can see some features are importand and the one we are just talking about certainly is. Well these says hubowners cant affort to bounce users "wherever they fit", because they simply can't affort that because hubs are smaller and smaller, it's even opposite - restictions are so low in hubs (comparing to few years back).

Smaller hubs that are build up by redirects will fall, all users will be those who saved hub addy in their favorites and users with old clients (where the second group of users will be larger in time). Disconnected user is a user lost for in everyday DC life. If users won't like client's new behaviour they will not update DC++ and i guess we don't wont that (this is my presumption of course).
Pietry wrote:I am asking you whether the option should be on in DC++ or not.
I would rather ask: how removing it is going to help DC? Because that is all i am con

FlipFlop™
Junior Member
Posts: 23
Joined: 17 Apr 2009, 08:29

Re: Followers of the Redirect

Post by FlipFlop™ » 05 Feb 2010, 10:13

I agree with Pietry and LadyStardust on this, there are a lot of reasons why not enabling autofollow redirects would be a bad idea. I think if this 'feature' gets pushed into the clients, it will dramatically reduce dc-traffic and usage, and people will indeed put dc++ aside much faster.

Improving user-friendlyness and less need for fiddling by users in their settings to make things work properly is the only way to go forward.

To comment on the only advantages stated by poy:
1. The option is annoying, makes you go to some hub you did not wish to connect
'Annoying' is a very personal view on this, and not shared by a lot of users.
2. The hub will be placed in the recent hubs tab ( will be available in next version ), which in the case of multiple follow redirects will make the list "dirty".
Since this feature isn't in the current clients yet, it can be made not to include hubs from followed redirects, so the list can stay 'clean'.
3. It solves a priori a bug in ynhub where users could be redirected by some weird chat messages.
Same argument as Pietry on this, a good clientfeature shouldn't be disabled by default to solve a bug in some hubsoft.
4. Favorite hubs will be actually some start hubs for a chain of redirects that will eventually lead to the same hub, and it's useless to pass through all those hubs to reach the same hub ( also waste of time and space connecting to all those hubs ), and the favorite hubs list will actually be a ghost list. It's possible to actually have the same hub in the favorite list, but under different ghost. ( same goes for recent hubs list ).
Disabling auto-follow redirects won't change this if users can still choose to follow redirects, disabling redirecting completely would be the only 'fix' for this.

poy
Member
Posts: 78
Joined: 26 Nov 2008, 17:04

Re: Followers of the Redirect

Post by poy » 05 Feb 2010, 17:41

in light of some of the comments, in particular LadyStardust's that have reminded me of the fun i used to have way back with redirecting poor leechers, i have turned it back on.

that doesn't change the fact that i still despise this feature from a user point-of-view.

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: Followers of the Redirect

Post by Quicksilver » 07 Feb 2010, 01:02

my 5 cents: (currently not perfectly sober so sry..)
1. Disabling redirects will break existing working solutions/processes ... software should never do such changes without really good reasons (a either or is ok with different arguments is not such)
2. if you change standard behaviour now we will have different client behaviour for years to come. Especially as some ops might one day want to move to adc it might be helpful to have reliable redirects working.
I am really against this change simply because it will result in even less clients bein g able to survive a redirect to some other address.

Quicksilver
Member
Posts: 56
Joined: 17 Aug 2009, 21:32

Re: Followers of the Redirect

Post by Quicksilver » 09 Feb 2010, 19:34

on a sidenote: if DC++ wanted to do something about the redirect bug of ynhub:
checking hubaddresses received and validating them would already be more than helpful ..

i.e.

some.hub.address.hu:411AJDHAJSKL

should not be autofollowed even if autofollowing is enabled... I know this is no real help for ynhub and ynhub should fix this asap ... though Input validation should also be done in a DC-client..

Toast

Re: Followers of the Redirect

Post by Toast » 10 Feb 2010, 11:09

imho we should warn ynhub users about the bug instead since the developers don't do that!

Delion
Newbie
Posts: 8
Joined: 21 May 2008, 08:27
Location: Moscow
Contact:

Re: Followers of the Redirect

Post by Delion » 10 Feb 2010, 15:13

Oh god, this bug is too easy to fix.

Locked