Lotus

So what ? If a hub owner allows min share of only 1 Gb, then it's his decision not yours. The only network that will be "destroyed" will be his hub. But why are you taking decisions for him ? If an owner will see that all his users are sharing the bare minimum, he has the simple option to increase that minimum. This will produce an interesting hub stratification. Users will have the option to connect to hubs with more share, if they want to. Serious users will gather on those hubs... kids or whatever will join hubs with 0 Gb share. If I want download, I will only connect to large share hubs... what would be the purpose of setting a small share on hub X and connect to it, if on hub X there is not much share at all ?... Instead, this option will allow to share *different types of file* on different hubs, making possible hubs oriented on specific materials. Nice idea from my point of view.

Yesterday I connected to hubs where I have share visible, for downloading purposes. Today I only connect to hubs where I have OP account and hidden share, in order to only chat with my friends. But they can still download from me... Why it is impossible to implement for this particular case ? Because my share is hidden in every hub where I am now connected. Not like yesterday... I read that when the first DC client was made, it was capable to connect to only 1 hub at a time. I think that this was the basic idea behind the DC protocol. Now things evolved but you still build and improve and build on the old concept of the "1 hub only". And probably the protocol hasn't changed also in this regard. Since now I can connect to N hubs, it would be very nice to have different share for each one of them, according to each particular hub specifics. Because hubs have different share requirements, not only in share size, but also some recommend or even forbid sharing certain material. For example, on a "music" hub I would love to share only music files. And on my own hub I would probably have the idea to require the users to share only music... but this is impossible with the current clients if they are connected on more then just my hub. I agree that this would be not as simpler as it is now and probably "fake feature", not fully supported by the protocol. But I still think it would be a step forward.

So, finally, we are getting somewhere... You are correct. That option exists. And it has a bug... The option is under Appearance tab and is called: "Hide Hub Topics". But note that it is *disabled* in my client. So, being disabled, the topic should not be hidden... isn't it ? And everything should be and look normal... only it isn't. If I enable that option, it works as expected. The hub name is correctly shown and the topic is hidden. If I disable that option, apparently the topic is shown... until I change the hub name and description in favorite list.... :crying: Mek: please disable that option and do that experiment again... Crise: there is another option that I don't know about and is interfering with this ? If not, it is pretty clear to me that this is a bug... please check again carefully. Why if I disable that option the hub name is taken from the favorite list, instead of being taken from the string sent by the hub in $HubName ? If you still can't figure out the problem, I will give you another hint: 1. Option "Hide hub topics" disabled - so topic should be seen. 2. Connect to a new hub. 3. Type /fav => the hub data is stored in favorite list. 4. Exit the hub and ask an operator from that hub to change the topic. 5. Reconnect the hub again. The topic shown is NOT the new topic, but the one that was when you first connected to the hub... the old one... Still thinking it is ok ? No kidding... Suggestion: I might be wrong, but I think that the first $HubName sent by the hub (just after validating nick) is the hub name alone, with no topic appended. The second $HubName, however, contains the hub topic appended to it. If i am right than you could use that very easy to implement this feature correctly...

Sometimes it seems so difficult to explain something as simple as that. But I assume this is partially because of my bad english. Please note that I was not talking about $HubTopic. I was talking about $HubName. When admin types !topic <new topic>, most of the hubsofts send $HubName to the users, not $HubTopic... By the way, $HubTopic support is enabled and works fine. Please make the following experience: 1. Press Ctrl+F to open favorite hub list. 2. Select the first hub. 3. Click Propreties. 4. Set the hub name to: "Lotus Is The Best" 5. Delete the eventually hub description also (!!!) 6. Click Ok. 7. Reconnect on that hub... :)

The name ABC is shown instead of the hub name. I *do not* see the hub name when I connect to the hub... When someone changes the topic, I *do not* see the topic... the title of the mainchat window is ABC... :unsure:

But if I am connected only on hubs where I have OP account and the share hidden... :unsure: