Beowulf

If the DHT setting isn't going to be touched from here forward after being disabled once from 1.3.5 onward, then we'll simply package a version of Apex that runs with it disabled by default and use that instead of linking to the official distro. The only reason this is an 'issue' is that I'm attempting to protect people from themselves when we're using the client.

Hah, agreed, but most users don't touch the other settings anyway. One of my Ops is messing with the setup now to possibly do that. I'm still meh on it because I don't enjoy the concept of anyone hosting one of those on our available hardware where anyone can get it and see the address if the link proliferates. The IP range bans we function on are fun enough, but still, I don't like to broadcast and I know how that stuff travels. The first rule of private hub is you don't talk about private hub, naturally. The second rule of private hub is MAKING SURE THE FIRST ONE ACTUALLY IS FOLLOWED. The 1.3.5 overwrite (of the .xml settings) also bothers me because if there's another update where DHT is enabled again (or rather, each update enables it again, so on and so forth) it means there'll be a lag between our release and the dev release each time, which is even more time sunk.

You're sending the information to the hub, and now the hub gets to decide how we're going to handle it, just like everything else. And in the end this change meant (for on my end) having to add on another something to have to handle or explain to people, many of them fresh or new to the whole concept of DC every year. DHT is simply not a viable option in any way for us. /Even if it is simple, these are users which can get discouraged or confused very easily./ And Lee: This has nothing to do with the 'Holy Grail' awaiting them at the end of their journey, else I wouldn't find emails about it each week with people having problems connecting and attempting to walk them through the process or what could be wrong. No. On my end, it means that the client isn't worth the effort. It means I'll run it because it's useful to me but the client is not useful to others in the same way when all they care about is getting that file in a way that is relatively safe and secure. The client is something that I enjoy having so we have a standardized process when it comes to walking people through things or that I know that there is this feature available and can point to it. Users should opt in to putting themselves on this DHT or at the very least be very clearly informed what is going on with this one, as I had three people separately send me messages asking why people in Romania were touching their files and none of us had any idea why until I looked through the changelog myself and balked. I... I guess I'm just at a loss for words where this feature became an assumed 'this should be enabled by default' when it seems to be an option that should be a conscious decision to want to run with DHT. It simply means we'll swap out clients en masse when it comes to an out of the box solution and Apex won't be it anymore.

Speaking quickly as an owner. I am amused because I used much the same language in my message that skasowitz referred to but I doubt he's one of mine. Apex has been our preferred client of choice, espoused by our operators and made reference to in our MOTD for at least two plus years now and it was with a fair amount of annoyance that I placed the block across the board on 1.3.5. The addition of DHT being enabled by default causes issues -- DHT is innately threatening for our users' circumstances due to bandwidth restrictions (namely any connections that are outside of our intranet). Our userbase is typically a constant 1k, peaking at 1400 and we serve probably at least 8-10k people over the typical course of our functional year. Summer is our downtime. Apex saturation on the hub is probably 50% of currently connected clients at any time. And because not everyone is technically able (regme eludes 40+% of these people) I can't expect them all to be able to understand what DHT is or how to turn it off. And yes, I am well aware of how easy it is. I still attempt to provide the service to these users however. And in this case it meant playing down to the most common denominator here, where they either won't bother or won't understand what we're attempting to tell them to do when it comes to disabling the option. If 1.3.4 was a stable hold I was more than comfortable having 1.3.5 blocked across the board and skip the problem entirely. It was a quick fix to block the version while I'm away for a time before I could setup handling the support route. More than likely with 1.3.4 being shoved off, it'll mean that the technically-able people will use 1.3.5 (~40-50 users) and turn off DHT on their own/with direction but we'll most likely have the others (the typical 800+) swap to DC .770 instead.