Page 1 of 1

WNFT - Will Not Forward This

Posted: 12 Nov 2012, 20:30
by Pretorian
I have recently been thinking if it is possible to reduce the amount of data clients are sending that they expect the hub to forward: search requests and connection attempts in particular. Some hubs (including the dev hub) only allow users to chat (use the MSG command) but not RCM, CTM or SCH etc. There is currently no way for a hub to say "I will not forward this stuff" but instead must rely on a STA to be sent each time a client attempt to use that particular command/parameter (or swallow the message). The following proposal/topic of discussion is the ability for the hub to say "I will not forward these messages if you send them" thereby allowing the client to aid the user without having to resort to a STA. For example, if CTM/RCM is disabled, the client can display "Get file list" as a grey option "Get file list (disabled by hub)".

Basically, the idea is that the hubs signals support for WNFT (Will Not Forward This) to the client, the command "WNF" (Will Not Forward) will specify the commands (potentially parameters within commands also) that it will simply not forward. The client can signal support for this extension also, which essentially means it will abide by the contact that the WNF command entail. If a client doesn't advertise support for WNFT, it isn't required to filter on its own. (Of course, hubs will probably still have to make sure that rogue clients don't do stuff even if they claim they support WNFT.)

The client would send WNFT in its SUP. The hub would then send WNFT in its SUP. In NORMAL (I'm not sure which state is better suited), the hub sends "WNF CORCM,CTM,SCH" (where CO is the parameter for the commands). Potentially, as I said, also a field for individual parameters within a command. For instance, some hubs omit forwarding of the EM parameter (e-mail) in the INF. I am not sure myself if the command would be "WNF COINF,EM,DE COCTM" where each CO is the command and the fields that are going to get filtered (in this case, EM and DE from INF and the entire CTM). I'm not sure if there should be a revokation of a filter, so potentially there should be "add" and "remove" parameters to WNF (something like "WNF ADSCH RMCTM" to denote that SCH is added to the filter and CTM is removed from the filter (this would follow the convention of the SUP, so I'm more leaning toward this).

Certain commands, such as SUP, STA, INF etc that are required for basic connectivity within the hub must always be allowed and shouldn't be filtered (the client would need to ignore that anyway).

I am considering also whether the client should have the ability to say "don't forward me these messages", such as CTM/RCM and SCH, if the client is chat-only. (Potential case for abuse here, I'm aware, but the client would of course handle any filtering as well.)

Note that the above suggestion is a blacklist and not a whitelist. A whitelist would mean "I will only forward these commands", but that would violate one of ADC's core principles, extendabilty. A blacklist is "I know what this command does, and I will filter it out, I thought I'd just let you know" and still allow unknown commands to be forwarded.

I am potentially seeing thinking of a "I will not forward D-type SCH" or something similar (filtering on type) but I am slighly hesitant, especially since I think it might be too wasteful and the syntax would be really strange..

Re: WNFT - Will Not Forward This

Posted: 12 Nov 2012, 21:51
by poy
DC++ currently relies on code 25 STA messages to build such a blacklist, since these messages contain the FOURCC of the forbidden command. it's working quite well; the benefits of this new WNF message over code 25 STA messages would be:
1) no need to provoke an error / to send a potentially-forbidden message to check whether the hub allows it.
2) more customization abilities, such as the proposed "WNF COINF,EM,DE" or maybe re-enabling some messages (eg after the user has registered).
on the first point, it wouldn't bother me much if clients were to send a few simple probe messages when they connect.
the second point is more interesting, but these features would have to be added to this extension to make it worth it. alternatively, code 25 STA messages could be enhanced to support them (for ex "FCINF,EM,DE").

why is this an extension signalled in SUP? couldn't hubs simply send WNF to whoever they want to, knowing that clients that don't know about this message would just ignore it?