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!”

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: