Direct Connect: Just These Guys, Ya Know?

ADC as an open messaging protocol

Szabolcs Molnar’s recent post advocated hub-side command filtering, specifically on BMSG PMs. I believe this, and obvious generalisations, to be mistakes. They sap the openness of a protocol capable of routing arbitrary messages between users, subject to bandwidth limits on involved hubs and clients.

NMDC, as that post observes, implicitly provides such limitations. One cannot send a broadcast message but it will be interpreted as intended as a mainchat message for display by the receiving parties. Similarly, private messages under NMDC as widely interpreted exclusively contain user-visible messages, leaving those who attempted protocol innovation to either seek quirks of buggy parsing or overloading such messages as $SR to achieve their ends. These limitations don’t ultimately help those using a protocol, instead pushing it towards a choice of ugly kludges or stagnation.

ADC, among other goals, includes the means to obviate the need for those workarounds and instead to directly implement unanticipated protocol features. To shut this down, as the previous blog post suggests, would merely invite the same harmful cycles seen in NMDC. Instead, an ADC hub should function essentially to authenticate identity, ensuring registered users are who they claim and that messages sent between users contain a correct source CID.

That stated, the motivation behind desiring hub-side filtering of BMSG PMs is real, and a rejection of centralised limitations on them should include a response to that impetus. Rather than specifically targeting BMSG PMs, a both freer and more robust system allocates a certain portion of a hub’s bandwidth each user can consume and under conditions of stress prevents or prioritizes as low traffic beyond that allowed.

Clients, meanwhile, can simply ignore BMSG PMs if they so desire; someone in control of a hub who desires equivalent functionality can use DMSG PMs instead. This allows her to retain a more general bandwidth allocation regime whilst simultaneously allowing free use of the ADC protocol with the ability for individual clients to choose to ignore BMSG PMs. Such a system, of course, represents a compromise in itself (why should a hub have to lie about BMSGs being DMSGs just so those who control it can get their mass messages displayed?), but unlike the alternatives doesn’t collapse with smallest gaming.

Legitimate uses of hub-side filtering do exist, primarily where the those administering a hub have unique knowledge of a pattern of abuse undetectable via static structural analysis. For example, URL spam tends to be both more dynamic and harder to detect a priori than the BMSG PMs, and therefore more worthwhile of hub filtering. The general principle involved I’d identify is that when a DC client can do something autonomously with negligible loss of functionality over what an ADC hub could do, the hub should refrain from performing that functionality.

Summary : don’t stunt ADC by reducing it to NMDC’s capabilities when alternatives exist.

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Thoughts about an ADC-hubsoftware

As you might already know, on clientside, ADC does work more or less. You can chat, you can download, you can search, you can browse other user’s file lists. Sure it has bugs, but it works.

But what about ADC-hubs? There are several, but none of them are mature yet, it lacks services which nmdc hubowners already got used to. And there are differences which the developers need to think about. Well, I collected some of them. Not to be wise or whatever, just because I think someone shall start it :)

Ok.. Well, let’s see:

1. Hubsoftware must ensure that the CID matches the PID and not allow users entering the hub if they couldn’t provide a valid CID for their PID
2. Hubsoftware must not store, broadcast or make available anyone’s PID to someone else including hubowners and scripts too. This would weaken the security of the system. People should not use or install hubsoftwares which does this to protect their operators and users.
3. It’s a good option to register users using their CIDs, but the hub should note the users that their registration will lost if they modify or lost their PID/CID. Moreover, it’s a good idea to store the last nick for every registration to disallow other users to connect and talk in the name of someone else while that other user is offline. This protects the users’ reputation.
4. Filtering commands is the hub’s job, not the client’s. So hubs must ensure that regular users are not allowed to send mass messages to other users for example by adding a PM flag to their BMSG.

Sure there is a lot more, but I think it’s enough for now. Feel free to comment.