Lotus

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 ?...

You still miss the point, but perhaps my english is not too good too. I am *not* talking about the # of users / ip in hub X. Read again what i proposed. Consider that I am connected to 10 hubs. And you also, on 10 hubs. And in the same hubs like me. Now, I start downloading a file from you, and the client finds 9 alternative sources... but it is you all the time, only in 9 different hubs... Hubsofts can not prevent this, you are connected only once to each hub... If i limit the max <user> / ip to 1 (where <users> = users from which i am currently downloading something) then the client will close 9 connections to you, leaving only one active... So, in other words: do not identify the "clones" based on CID, because it will not be implemented soon, use users IP for this purpose. Allow me to set a limit for users / ip in case i download from more users all heaving the same ip...

I don't even know if it is a good idea. But I hope yes. An option to not be able to share files with doubled extension ending in exe (*.avi.exe, *.mp3.exe etc). And a filter for them - so if someone else using other client shares them, I will not be able to download/see them in search result or file list. This option should be enabled by default but I should be able to disable it if I am OP in some hub and I want to search for ".avi.exe" files... Please note that many of this viruses are ddos tools and they affect everybody, not only their hosts... Thank you.

until then, i was talking about something else, not allowing more then x users per ip... that is easy to implement compared to cid. i don't have anything about user identification in nmdc hubs but every time i requested it i hit a wall... :)

That's why it is an option... disabled by default. But perhaps in my network or hubs where I am connected, shared IPs are not such a problem... so I can enable it, right ? Or perhaps I just want to enable it knowing the consequences.. On the other side, this would help me to make sure that I am not downloading multiple times from the same user (on different hubs) even if NMDC protocol doesn't offer me the tools to properly detect this... What can happen if I download from user A and B and they have the same IP ? Two cases: Case 1 - they are the same user but connected on 2 hubs Case 2 - they are 2 different users using a rooter for example. If I enable this option, the client will cut off one connection, leaving only one user. Depending on the situation, this may prove useful for me. But note this is an option so most people (probably 80-90%) won't enable it, those who knows what are doing may enable it but they will do it on their own risk. And if I enable it, even if it is the wrong case, I am the one that gets penalized eventually (because I lose one download source) and I am not damaging the network...

I also posted this idea in "Suggest features for ApexDC++" thread by Toast, but I think it is so important that I started a new thread for it. In my case, I get sometimes THOUSANDS results for .something.exe on the hubs where I am connected to. Keep banning those users is not the best solution as some of them have dynamic IP and even so they end up by going on other hubs by redirects where I don't have access... And I noticed that PROBABLY NO ONE OF THEM is removing the virused files from share. I think that treating this problem at client level and implementing such filters would cut the "infection" from the root. And besides that, suffice to say that I know how relative easy is to make a simple yet very powerful ddos tool spreading this way...

I don't see why. If I am downloading from BigMusscle, Toast and Crise, I also have all 3 IPs of you, isn't it ? Because the client knows from what socket and IP is currently downloading... If <max sources per IP> is set to 1 and somehow your IP is equal to Crise IP then the client will close one connection (you or Crise) so that only ONE user from your IP will remain in use. Why is not possible ?

Option: max download sources / ip. Default is 0 (no limit). If it is 1 and i am currently downloading from 3 users (A, B and C) then I am sure each of these 3 users has a different (unique) IP. If the limit is 2 then it is possible that 2 of them have the same IP, but not all three.

Feature: option to collect all private messages into a single private window, global for all hubs. If enabled, every private message from every hub will be shown into that window, of course, indexed or prefixed by the hub name and source, like this: <hub><from><nick> message, where "from" is for example the name of the private chatroom (actually, the "from" field taken from "$To" command).

I would extend this idea a little bit by displaying the search statistics per hub, like how many search results each hub provided. Or a simplified version of this, count 1 to a hub that return ANY search result an 0 if no search results are returned. Keep the statistics between sessions. If after one week a hub has 0 search results and no download then Apex will make a suggestion to the user to remove that hub from favorites. The owners that are "cheating" by disabling search and download will loose users in this way. Notice that when you search for something, it is most common to search on all connected hubs and few are noticing if one hub provides no search results... Also regarding statistics, perhaps an idea is to report them to the number of users on that hub, because it is normal that a big hub will offer more search results or activity/downloads...

If you upgraded correctly then all settings from the old Apex will be preserved so no hashing is needed. If you reinstalled from scratch then it will hash the shared files only once... and by the way, it will take much more then 40 seconds to do that. After that it should run normally... so I think the problem lies somewhere else. One more thing: the shared folder is the same folder where your downloaded files are stored ? If so, then it is necessary to rehash them as new files are added... You can always check the hashing status under menu: View --> Indexing progress.

Hello all. First, congratulations for how Apex looks and does. My humble list of suggestion, at least those that pop up into my mind right now: 1. In last versions StrongDC does not allow to share Windows/Program Files folders. Extend this option to files ended in .avi.exe, .mp3.exe etc because there are a lot of botnets/ddos tools spreading this way... 2. I noticed StrongDc react to (some) CTM floods notifying the user. However, I propose to do more: if a CTM exploit is detected automatically notify the major public hublists about it. This, of course, requires cooperation from the hublist side, but I think it is a good idea. If the exploit happens again, auto-remove that hub from the favorite list... The hubs that are used for ddos will remain with no users. And it does not matter the fact that the owner is flooding or the hub is miss-configured, just remove it from fav... 3. I would like an option to group more hubs into categories. Then, i can for example display only the tabs from one category... and switch between categories as I like. That is because if I am connected to many hubs, there will be many tabs, and I want to group them somehow... The option of "mini-tabs" is great, but this is more. And, of course, the RSX option of category into fav window can not hurt... 4. Make a more decent "search for" into mainchat / prv window. Options like search up/down, case (in)sensitive etc. See ODC 5.31 for an idea, although it is primitive, it is much more then what apex have... 5. Make a profile --> minimal with low ram consumption, in case i only want to download and i don't care about chat/userlist. If i enable that profile, no hubs window, mainchat, prv or whatsoever... and of course no userlist. Or something like this, my idea is that sometimes i only want to download, and perhaps i could gain some memory/cpu if not using mainchat etc. 6. Animation in mainchat Although you may laugh, somehow this is the future, ppl want to look to a movie / play a game when on pc and not type to a console... You can start with animated emotions. This idea has some potential and cpu/mem is not a problem for this... 7. Lol. Shortcuts for menus, at least for basic ones... if possible, configurable per hub. For example, as an idea, when I press F1 the client send to the active mainchat +help... 8. If I do a general search like for ex. ".avi" I will get a lot of results... I know the nmdc protocol doesn't allow complex searches. But I would like to be able to use some more complex filtering on the reported results and perhaps save them into a file. As I said, this is all I have in my mind right now. But perhaps more will come ) Thank you and keep the good work on this client, actually one of the greatest dc clients ever made.

In ApexDC when I reconnect to a hub (Ctrl+R) all ignored users from all hubs became unignored. Same problem noted in RSX.

Of course, the words can be manually edited... so you may chose "hello", "please help me", "can I ask something?" etc instead of f***... Now, seriously. Then forget about +report or +kick. But I don't like the way you talk, and you don't like what I proposed... so different opinions. So, I think it is very good to be able to ignore your remarks... as well as for you to ignore my nice and polite questions on the hub... isn't it ? Thus, you will remain in my eyes a nice and polite (also rather quiet) operator... And, of course, as I forget to mention, the settings should be per hub.... not global On a second thought, perhaps it is a bad idea because I may chose whatever I want to ignore, and the operators and the bub will start to lose their centralized power, because no one will know who what ignores and what sees... so the scanner part should be left upon the hubs shoulders and the client should just obey... I think this is the way, yes...

What do you think about implementing a simple but robust chat scanner like most hubsofts have, only this will be a client scanner ? For example if someone say f*** in mainchat/prvivate, his message will be ignored and eventually a +report will be generated... or, if I have OP on that hub, a "!kick <nick> Behave yourself!"...

Yes, but you use it. And most hubs does. I don't follow your logic. You don't want to improve it because it is dead. But you have no problems using it, with all the problems it has, dead as it is...

I have not checked but it is possible that, during the hashing process, the client sends more MyInfo strings to the hub. Most hubs will ignore or delay these MyInfo changes for a certain amount of time because allowing to many MyInfo updates will greatly increase the upload rate of the hub. Thus, it is possible sometimes that even after more Ctrl+E the new files or folders added to share are still not fully updated on the hub... in which case you need to reconnect to solve this. The fact that you only have to Update File List one more time seems fine for me, but however I might be wrong.

Do you mean: start SDC, disconnect all hubs, add new files to share, wait until hashing is complete, refresh file list, then connect to a new hub and your share size is wrong ?!? But if you are connected to a hub, BM is right, most of hubs(ofts) implements a sort of flood-protection, ignoring your new MyInfo strings if they are too fast. The DC protocol states that when a myinfo changes the hub must send the new myinfo to all the users to keep them up to date. But doing so opens doors to flood as you may connect with a bot and send countless myinfo... and the hub must send each of them to all users. So, some hubs kicks you if you change myinfo too fast, most of them simply ignore you or wait for a certain amount of time expecting more myinfo changes, and only after an interval of time send to all users your last myinfo. The easy solution if you want to make your new shared files accessible right away is to simply reconnect... or perhaps to tell your friend(s) to reconnect himself... but I'm not so sure about that...

Okay, so this means that my Find_User_Ip bot will continue to work properly in the future... no worries... :)

I would love the following options in apexdc (also posted on strongdc forum): 1. An option to allow max n private messages from different users / x seconds from a hub. This will prevent a hub to flood the client. If you think that flooding a client is stupid and does no good to the hubsoft (which I totally agree) then you can "hide" this option somewhere on advanced settings and make it disabled by default. 2. An option that, instead of ignoring private messages from the hub/bot, to collect all of them in a single separate private window. Better then just ignoring because I can study them if I want, but they still don't harass me because it is only 1 window for all the hubs... 3. Also, it would be even nicer if this settings (ignore private messages from the hub/bot) would be hub-wise (i can enable or disable them for each hub in particular).

Where did I say it does ? I just revealed my default setting. I don't know if other settings are still "affected" by this behavior because I didn't check all the cases. I think a bug report should include a minimum description of whatever you may think it can be related to the bug. I don't like this. Why do I have to be forced to move Apex to tray ? It is not logic from my point of view. I think the correct solution is to correct this 'misbehavior'.

My ApexDc Settings: open new PM message in the background. I switch (Alt+Tab) to another Windows program, but i let ApexDc maximized (only it is now not focused, it is sent to back). For example, I have say notepad or something in front of apexdc. When receiving a new pm message on some hub, apexdc instantly get focus and move itself in front of the active Windows program (notepad in my example). Hope I explained clearly, sorry for my poor english.

Sorry for the old topic, I'm pretty new here. Do you think a modification in the protocol so that when a peer connects to me he must also send me a reference to the hub from where this connection was initiated... do you think such a protocol modification could be supported and would be welcome by the hubsoft developers ? Or useful ?

Found the setting. Still, there is a small bug left. When option "Hide Hub Topics" is checked, enabling "Use details in favorites to identify hubs" does not act as it sounds. The hub name is still taken from the $HubName and not from the favorites list data, as expected. Last experiment. Enable both options ("Hide Hub Topics" and "Use details in favorites to identify hubs".) Rename a hub in favorite list to "xyz" and reconnect. The name of the hub is still taken from $HubName and is not "xyz" as expected. (When "Hide hub topics" is unchecked, the name of the hub is indeed xyz as in favorite list). I assume the bug is in the "hide hub topics" implementation: the code that is executed when this option is enabled does not take into account the other option with fav... My apologies, however, the bug is much smaller then I thought and the tone of my voice was much louder then it should... :crying:

If I add a hub to favorites and change his name to ABC on my favorites list, ApexDc displays ABC instead of what he receive in $HubName. If I add a hub to favorites and his name is X and after a day the owner changes the hub name to Y, Apex still shows X instead of Y when I connect to the hub.