I do agree with you in a way, in that it does seem appealing in terms
of simplicity. However, I don't think that kind of simplicity is going
to hold, since the broadcast commands still often require some
individual intelligent processing by the hub. For example, the only
two commands in ADC that truly benefit from broadcasting are, as far
as I can see, the SCH and INF commands. These already differ in my
mind, in that if the hub receives to SCH commands too close in time to
each other, it should reject the second one with an error. However, if
it requires two INF commands within one "allowed broadcast period", if
you see what I mean, it shouldn't deny the second one. It should wait
until the broadcast timer expires, and accumulate all succeeding INF
commands and then re-broadcast the final data once the client is
allowed the broadcast bandwidth again, right?

As a bit of background, the idea comes originally from irc client-to-client
copy, and it's been used there with success afaik...on flooding, again irc
has a good model with their sliding timer - in fact, that's what dch++ uses
for the moment as flood protection, and it seems to be working ok...(if(now

flood_timer) flood_timer = now; now += 2; if(flood_timer - now > limit)

kick();) that is...which works regardless of command, and allows for a
number of commands coming one directly after the other...

Further, hub processing on commands needs to be done mainly for limiting
purposes - shares, slots, etc. Clients should do their own sanity checking
on messages that arrive, and should never trust what they get from the hub
anyway, so -specially for new commands- it is mainly up to the client to
decide whether to trust a command or not...
Besides, a simple allow list in the hub config brings us back where no
bandwidth is lost on funny commands...but the hub owner can easily allow a
new one should one emerge...and it's not like the commands themselves are
unspecified...

/J