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:
- The option is annoying, makes you go to some hub you did not wish to connect
- 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".
- It solves a priori a bug in ynhub where users could be redirected by some weird chat messages.
- 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 ).
- 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.
- 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.
- 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.
- 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.
- 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.
- hammering connections on all hubs will significantly increase load and bandwidth and will kill the servers.
- 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.
- no more redirect possibility for the hubowners, user balancing between hubs will be gone, networks of hubs will be gone.
- 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.
I am asking you whether the option should be on in DC++ or not.