Lotus
Member-
Content count
81 -
Joined
-
Last visited
Posts posted by Lotus
-
-
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 can understand your frustration but your aiming it in the wrong direction most users dont pay attention forums so go out on hubs and correct the errors there instead of trying to teach us stuff here cause we been there we done that..
thats my 2 cents
p.s if a hub promotes malware abuse report the hub so the dns gets shutdown cause its not legal to try and get people infected.
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 2 slots
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 ?
-
Today, while I was browsing a hub, a new one (for me), I received 2 mass messages (!bc from the same operator) in only few minutes, asking me to download some yahoo password cracker, in reality a trojan, a botnet. Two mass messages, from an OP... about 2000 users online on that hub.
This is the quality of the DC today, I'm afraid. I don't know if this is the proper place but I would like to start an open discussion about how can this things change and what features can be implemented from client side in this respect. A comparison between various p2p protocols, and how to safeguard dc in particular. Perhaps some ideas could be incorporated into the new adc. Perhaps some ideas could emerge from the audience. For example, BM is trying something I guess with his DHT idea. So I provoke all of you that have something to say to a discussion on this things. This will enlighten other not so advanced or beginner DC users, like myself.
-
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... :)
-
I never once said something is inferior (or superior) to to Apex nor vice versa. I didn't even raise a real argument... I just asked a simple question. I'm not so cheap as to neglect valid reasons, like you seem to think... but I have yet to see any other reason, from you, besides "just because".
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.
-
Lotus: No, it's not what we are doing. We just follow protocol specification and update user's description according to user's choice. Since there's no tag in NMDC, we give user a choice whether to attach "core version" (ApexDC++'s core is still only DC++ 0.xxx) or "client version"
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.
-
Emulation lets you enter hubs which have banned ApexDC++. The reasons are silly - such as segmented downloading or upload limiting capabilities -
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.
-
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.
-
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 ?
-
Also people should realize that there's no emulation. Since original NMDC client doesn't have any tag, it's a bug in NMDC hubsoft implementation if it detects clients by tag. Tag is only a part of description where user with original NMDC client can write what he wants.
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:
-
You know, Apex can be spotted even when emulating... and it will even more so when we merge some changes from SDC. If the hub owners are too lazy to figure out how, then sorry no cookie for them
You say emulating is cheating if that is the case then do something about it, don't expect us do it for you. Because we obviously do not think that emulation is cheating (since if we did that option would have been removed ages ago).
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?
Anyways, could you perhaps give me a list of reasons why DC++ 0.75 (since that is the version we "emulate") should be allowed in a hub and Apex shouldn't... I am more than interested in hearing these reasons. If you are unable to do this then the whole discussion about emulation going on in here is pointless (since I don't even consider changing anything if the reasoning behind it is "just because").
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.
-
this way we'll get rid of emulation on new protocol. also ADC doesn't have problem "Turn on your tag" which in most cases forces me to use emulation [;
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.
-
Since ApexDC++ isn't anything more than DC++ with added features, it still has the right to identify itself as DC++.
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.
It's extremely difficult to persuade hub owners to allow clients in hubs too, they are too ignorant in many cases.
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.
-
There are way too many hubs that don't allow ApexDC++, and that would cause problems for users who don't know how to enable emulation.
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++"... :)
-
if it can be implemented, it could be useful to allow a short pause but controlled.
for example, we are not allowed to pause more than 10-15 minutes / day ...
in case we need a short pause to upload something faster using other software.
why not if it can be done properly and i can not cheat ?...
"Ignore all PM" feature?
in Support
Posted
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.