Lotus

A RAW command (dc message) sent on joining specific hubs.. For example: raw1 is sent when the client find a fake user raw2 when the client joins the hub etc

First, if you only use DC for share (no chat), then why do you connect to hubs that keep sending you "Search disabled unless you share xx gb's" ? On those hubs you can not search and download. Second: Settings -> Appearance -> Windows -> Ignore private messages from the hub & Ignore private messages from bots. Hope this helps.

What are you saying, Ophite, is only valid for a small percent of users. But most users join hubs because they want to download, and they want to download as fast as possible. On some big hubs, often there are only 10-20 posts to mainchat in all day... and mostly like: "hi" or "how can i get this file". Sometimes even less. They say DC is dying, and I think this is the reason why people are switching to torrents. DC is less effective from this point of view (download speed). If a user really join a hub because of your reasons, because he want to chose, because he wants privacy, he can always disable this option. So nobody has to lose. If you have a small private hub, you can disable DHT along with all the rest of hub users. But please admit that an average user who chose to join one hub versus another is choosing that hub because he thinks he can download faster or he has better chances to find what he seeks... Or please tell me that those 5000 users joining hub X are all close friends and want privacy... About the DDOS issue, I agree it should be carefully analysed. DHT has been implemented. I think we should give it a try and see how it works. And I also think it is better to try to do something then to do nothing. In respect to DC.

BM: you have a point too. After rethinking a bit, and considering other posts on this forum and your's, I think I understand now that SDC is meant for share and implemented this way. While, instead, some hub-owners are anti-share and anti-DC... so this is why SDC does not meet their needs all the time. Indeed DHT is creating a virtual huge public "hub". But that hub is only meant for share. It has no chat, mainchat, op-list or something like regular hubs have... so the "DC spirit" is not broken even if this option is enabled by default without user knowing. Everything is the same as before, DC is the same, only download speed is boosted. One particular effect of DHT, however, is that you no longer need to connect to big hubs to be able to download fast. This is a change. But this seems like a positive change from the user perspective. I don't know how hub owners would react to this, because I think it will somehow decrease hub's hegemony and increase DC decentralization. Hub X will not be so popular and attractive as before, because I will no longer need to connect to it to download fast. Because of DHT I can connect to any hub, even small, and still download fast... But again, it seems like a positive to me. In my opinion DHT is much better then not DHT. BM: some of us try to understand and just express our opinions. No need to be upset...

I tend to agree with Ophite. But if DHT is OFF by default then 99% of the population will not use it. Imho, the correct way is when someone install StrongDC++, a pop-up window appears and explains him what is DHT, giving him the option to enable/disable it (!) This window is configurated in such a way that if the user skips this window, not choosing anything or not reading, DHT will be set to ON. And thank you BM for this huge step forward, imho.

I try to do the best I can. But I think the problem is at a higher level. Yes, it is ok to have a good police force, but is even better to have no crimes and need no police. Why DC protocol allows so much 'noise' ? Why torrents for example are much better in this respect ? What can be incorporated from other protocols and what can be left behind from the current DC protocol ? It seems the new ADC everyone talks about is the solution to DC. But then, I see no ADC hubs. Why hubsoft authors still update their NNMC versions, instead of switching to ADC ? Ok, you have talked and you know. But me and others are new to DC. You said yourself that most of DC operators today have no clue what client should they use. I include myself in this category. Then, what can we expect from regular users ? But you don't want to talk to us, because you already talked this... Well, thank you very much. I think informations are very good, and you have to start from somewhere, for example top-down. I would gladly join a forum or a hub that has this purpose. But I can not even find a decent help system in DC clients (other then DC++)... I just use DC from 2 years. I want to know what is DC. I thought to ask here. Sorry if I was impolite or something. And thank you for your answer, because you did answer and it is appreciated.

Default is indeed 2 slots and 0 slot ratio, while in StrongDC++ default is 2 slots and 1 slot ratio. I think I can prove you that if you set a restriction like min 3 slots on some regular hub, this will 'drop' more then 95% of ApexDC++ users. Try it and see the result, because some of us have already tried this. This means the vast majority of users just use the default settings. This also means you almost never find a free slot on dc... Having 20 users uploading from you with 75 kbits/sec each is much better imho then having 2 users downloading at 750 kbits/sec each. However, apart from setting a slot ration of at least 1, my suggestion was to change the default color for uploads (because red suggests danger, alarm, wrong etc and is not the best choice, it makes people think uploading is bad) and to make an option to not show uploads at all... Is this very costly ?

As I noticed, many people have horror seeing so many uploads in their client and they tend to reduce upload slots to 1 (if they know how). Some suggestions: 1. Change the default color for uploads from red to blue or green. Red means danger, alarm... 2. Make an option to NOT SHOW AT ALL uploads (only download progress). 3. If someone tries to decrease the upload slots, pop up a window explaining him that slots are necessary for the DC to work well and that no matter how many people is uploading from him, this has very little or no impact on his download speed. Thank you.

This days the clients evolve with more and more advanced and op options, instead of getting closer to the common user, which barely succeeds to connect to a hub and have little or no knowledge about dc. I know you are all busy, but I think an integrated help (like most applications have) where the bases of the dc and the program menus (File, Settings, etc) will be explained in details, I think this kind of integrated help is justified to ask for. It is already and advanced program and the help is very low, considering how many Apex users read the forum. Once created, this help would be easily updated as changes in Apex versions will not necessarily require a change in help. Thank you.

Yes, hard to find a free slot. And yes, most of people does not change default settings. Above them, there is a class of users who learn how to set up their client. Most of them are trying to set it as much restrictive as they can. If possible, join hubs which allow no share, and use fake/cheating clients. Only few users are actually acting responsible using the simple principle: you have to give in order to get. If every dc users would carefully select his share and slots then things will become much better in dc. But educating is one of the keys. And the red color for upload slots it does not send the right message... More then this, perhaps a simple message window to show at first run, or some time (like after 5 minutes online - because the first messages are almost never red). This window can inform the user about some simple guides, in 2-3 words... why not ?

Ok, you have convinced me. I eagerly await the version of StrongDC that will allow me to change slots and other info also... :)

If Strong and Apex will no longer allow emulation, this will have some interesting (generally positive) effects on the DC network itself. Hub operators will start to think. Some hubs that are ruled by stupid people will probably lose users. ApexDC and StrongDC will not not lose users in the long time. It is a long time since ApexDC and StrongDC started and you should state your position. This is not a secondary position. It is a top position, for both Apex and Strong. Sooner or later, this step must be done, imho. It will also make things more clear, like each user what client uses. If it does not happen, you can emulate again. Worth to try.

Why do you give the user such a choice ? Who came up with this idea and why ? Why not just use Apex ? What is it's purpose ? Of course you know protocol better then me and technically speaking, you are correct. But of course you know that the interpretation of this TAG is as it is, and knowing this, you use this interpretation to gain access to more hubs. No, it's not your fault, it's hubs fault they interpret TAG the way they do. But then, what was the purpose of this dual description ? And if it is not a rule, if there is no specification... what about the other fields from the TAG ? What about share, slots etc ? There is no specification there either. So you don't let me to change that parts because I would disrupt the DC very badly (and I 100% agree) but on the other part, you change the "client" description in tag as you like. You say the hub should not interpret that part of the tag as the client, since there is no proper specification for this anywhere. So I am asking you: what do you think about the other parts of the tag (slots, share etc) ? Should the hub take them into consideration and for example ban a user because the tag shows he has no share at all ? Or not ? The tag is the same but you are interpreting it differently depending on how do you like.

If I ban Apex in my hub, silly or not, *it is my decision* and it is my hub and I SHOULD BE ALLOWED TO BAN WHAT I WANT. You should not force your way in. This is where you are not playing straight. You say it is silly but since when do you decide for me ? This is how the political leaders are listening to my phone and mail... for my own good. Let me rule my hub as I want, considering I do nothing wrong (like flood or something). Lol, I can't even tell how many people in my hub are using one client or another... It's a mess.

Personally I think the more help, the better. Contextual help will be very good for beginning. A more advanced help will be even better. It also should be simple and easy to read, meant for average users.

No. But I am saying that the way this "tag" evolved, you are using it today to identify yourself in different modes, in order to gain access to hubs that don't want to let you in. This is not fair. There is no technical specification, but this is what you are actually doing. If you mean what you say, why don't you let me change the tag *ANYWAY I WANT* ? And why DC doesn't let me do this also ? What was the purpose of the tag when it was created ?

This are technical things. You can use technical specifications but the reason of emulation remains. You are not playing unfair because you are violating the DC protocol. Not because of this. As it seems, you have found a "legal" way to do it (to play unfair)... There is no emulation, but we still emulate. Or at least, use 2 alternatives for the tag... with the effects they have... :blink:

I want to be clear about this. I like Apex (and Strong and RSX actually). I allow all clients in my hubs. But my sincere opinion is that you use emulation, at least partially, to override some client bans. This is a simple point. Now, there might be other ways to ban Apex, but still emulating will make ApexDC shown in more hubs than the alternative to not emulate. From curiosity, in the beginning, why was this option ever created? You are wrong. You are saying: the client we emulate is inferior so this means we don't emulate. But your logic is faulty. And if I give you a reason as you ask, will you then change the emulation to DC++ 0.69 for example ? This way you can skip any of my reasons, according to your logic presented here... The real issue is this, imho: it does not matter if you emulate something better or worse. And, for God sake, if DC++ is not better, why do you still emulate it ? Please just answer this question. You all argument that emulating is not wrong, but until now, nobody gave me a direct answer WHY emulating. Just why ? The point is not that DC is superior or inferior to Apex. The point is the purpose of emulation. And I think this is to gain access to more hubs. At least BM argumentation that ApexDC is DC++ with some extended features is better then yours and I can accept it to some degree. But still the question remains: why emulate ? Toast also admitted somehow, only said that this option is necessary for future development of the DC. But your argumentation, that DC is not better then Apex, don't stand. You don't cheat to look better. You cheat to gain access. I like your clients and I think you are doing a great work for the DC community. Not words. I do think this. But this does not mean that I will not sanction you where you are not playing fair. And I think you are not here.

I'm not expert at protocol and this, but I've noticed you send: "$MyINFO $ALL Nick <RSX++ 1.00> <++ V:0.707,...>" while StrongDC (and other clients) send: "$MyINFO $ALL Nick <StrgDC++ V:2.22,...>" in tag. I don't know what is the correct syntax, RSX looks better imho, because is sends both the "core" and the "rsx" version, however hubs have problems with it. For example: Verlihub ask you to turn on the tag, as you mentioned, YnHub lets you in but uses <RSX++ 1.0> as the nick description. Now, this may be mecause poor hubsoft implementation, as BM said. But until hubsofts will provide support for this tag format, why don't you use something like "$MyINFO $ALL Nick <RSX++ V:1.00,...>" ? Isn't this better then emulation ? One more time, this is more like a curiosity for me, I'm sure you have your reasons and as I mentioned before, my protocol knowledge is that of a beginner. Thank you.

If Apex *IS* DC, then how can Apex *EMULATE* DC ? You can not emulate yourself. And if APEX = DC + FEATURES, then let the name "Apex" as it is... because it means just this. Why use 2 names ? Why this option: emulate / not emulate ? The question is: what is the purpose of emulation ? And I think this is clear for everyone. If I am a hub owner and I don't want to allow ApexDC in my hub, you can override this with emulation. And you keep this option just because of this. So, if they don't want to allow your client, you override their decision. Because they don't know what they are doing and they are ignorant. The only problem is that it is their hub. Not your's. And they should be left to rule it as they want. Dumb or not dumb, ignorant or not, according to your criteria. You can play with words as much as you like. As I said, emulating is cheating.

Lol. So you do it for us... ApexDC++ users... Thank you very much. But I don't think so, because we can change the client and get access... If a hub owner does not allow ApexDC++ client in his hub, his will should be respected. I don't say that ApexDC++ is inferior or the decision to ban ApexDC is a good decision. I say if this happens, you should respect it. Emulating is nothing more nothing less then cheating. You emulate DC++ and you enter that hub ILLEGALLY. This type of cheat does not have a direct bad influence on DC network (like fake share does), however it helps your client to become more popular, or at least this is it's purpose. Emulating is a fake option that help ApexDC++ to grow. But it does this by disregarding (and breaking) hub rules. Each client that emulate other client is faking, in the behalf of his users, but ultimately for himself. The alternative is to not emulate anything. If someone wants to ban this client, he should be allowed to do so. Doing this will have some repercussions over the client and/or the hub... For example, I don't like the "crash client" option that hex hubs implement. If a hub is not very well configured, you may be "crashed" often. Now, if I would have a client that has some anti-flood incorporated, like allowing max 5 private messages / second, probably I will enter hex hubs... but because I DON'T have such a client, I DON'T join hex hubs... So, who has to loose from this situation ? My client, or hex ? You get my point... So basically, the current state is this: the hub is the master and the client is the slave. As long as you will accept this state of fact, emulating is your choice... when you will no longer allow emulation, probably this raport of forces (hub vs client) will be reversed... And for the hub owners that wants to ban ApexDC++, I give you a small hint: just set min slot ratio to 1. Because more then 95% of the population use the default client settings, and because the default ApexDc++ settings is 2 slots and 0 slot ratio, you will get rid of 95% of ApexDc++ users, while in the same time improving the performance of your hub... :)

I second to that. It will save me the time to search and copy/paste from the log, because it seems the only way to preserve emotions... :)

3 more suggestions. 1. often it happens that i am away and somebody writes something in private to me but when i came back, he already went offline and i am unable to see what hub he was connected to... because all i can see is: Nick - offline... please correct this 2. because the userlist is already so big in some hubs, i want some advanced filters for it. for example: i want to filter (show or not show) all the users sharing less then 5 Gb and using oDC 5.31 as client. 3. a "search user" feature. search on: all hubs | op hubs | specific hubs, nick pattern, use regular expressions etc.

don't worry: soon DC++ will implement a new feature: "emulate ApexDC++"... :)

Option per hub (in favorites): time (in seconds) after which the client will connect to that hub. Let's say I have 3 favorite hubs: A, B and C, and I set the auto-start time for A: 0, for B: 20 and for C: 40. After I start Apex, it takes 0 seconds to connect to hub A, 20 seconds to connect to hub B and 40 seconds to connect to hub C. This means that Apex will NOT connect to all hubs immediately but only after that time. This will prevent the client (and system) freezing and some connection problems when I start Apex and I have many favorite hubs.