OSNR - Only Send No Read

Ideas for ADC may be presented here for others to review and point out flaws or further improve the idea.
Forum rules
If you have an account on the wiki, remember to update the ADC Proposals page for new ideas.

Posts: 53
Joined: 10 Jan 2008, 19:56

OSNR - Only Send No Read

Post by blastbeat » 10 Oct 2014, 11:59

Hi all,
here an extension idea, i call it OSNR - Only Send No Read.
It is designed for bots, which stay in a hub only to broadcast news, for example a RSS feed bot or a release announcer.

- client adds a ADOSNR to its support in protocol state; hub adds it to indicate support (if not, client has to handle possible incoming data from hub/clients)
- standard login procedure; client adds OSNR to its SU flag in INF, to indicate that it ignores every communication attemp by another client;
this should also be done in case the hub does not support ADOSNR
- if hub wants the client to login, hub sends ONLY the clients INF to indicate login. nothing more. that will be the last message from hub to client
- if hub does not want the client to login, hub sends some STA and disconnects the client
- other clients in hub should respect the SUOSNR flag in INF (if they understand it) and should not try to send any data in any form to the client, no pms, search results etc

I experimentally implemented this extension in luadch (https://sourceforge.net/p/luadch/code/H ... unk/luadch)
and announcer_bot (https://sourceforge.net/p/luadch/code/H ... ouncer_bot).

Posts: 5
Joined: 27 Dec 2007, 15:52

Re: OSNR - Only Send No Read

Post by Night » 13 Oct 2014, 09:09

The idea is nice, for other clients its just visual changes that can be done based on it.

But, I propose this to be hub handled so it can be done only if hub supports it.
The hub would send OSNR clients flags to other clients in INF like "NR1" ( same way as bots "BO1" ) and the OSNR client could have its own client type CT value also.

Kind of setting the feature on/off by supports does'nt feel right to me.
I think this kind of clients should be only handled by the hub since its mostly "Spam bots" that would use it and wouldnt really want those bots entering without the hubs permission anyway so if the hub doesnt support this feature, it should not be possible to use it.

Site Admin
Posts: 214
Joined: 21 Jul 2009, 10:21

Re: OSNR - Only Send No Read

Post by Pretorian » 13 Oct 2014, 15:55

Here's what I wrote in the dev hub:
- [2014-10-10 14:08:05] <Pretorian> I think "OSNR" can just be solved by allowing clients to send CT<bot>.
- [2014-10-10 14:08:28] <Pretorian> That's far easier than implementing support for another feature.
- [2014-10-10 14:08:38] <Pretorian> Although, sure, requires that hubs allow that form of management.
- [2014-10-10 14:09:33] <Pretorian> The "OSNR client" will still need to deal with hubs that doesn't support the new feature, so there is still a requirement for hub modification.
- [2014-10-10 14:10:17] <Pretorian> I don't know if clients respect CT<bot>, but it's definitely more general in that respect.
- [2014-10-10 14:11:01] <Pretorian> The feature is otherwise basically WNFT.
- [2014-10-10 14:11:32] <Pretorian> (Not WNFT verbatim, but the flipside of it.)
- [2014-10-10 14:11:46] <Pretorian> (That I address in the bottom section of WNFT.)
- [2014-10-10 14:12:45] <Pretorian> I think WNFT has a greater flexibility than OSNR as the latter only deals with one type of information flow direction.
- [2014-10-10 14:14:15] <Pretorian> The former is surely more advanced and complex, but has the flexibility of being able to differentiate between different types of information and the direction.
- [2014-10-10 14:17:13] <Pretorian> CT<x> is a way for the client to request the x feature from the hub. I can imagine a CT for bot and hidden to be quite useful.
- [2014-10-10 14:17:32] <Pretorian> Hidden may indeed be better for such bots as it won't even be seen in the user list.
- [2014-10-10 14:17:55] <Pretorian> Especially if the bot is doing things that aren't supposed to be visible for mere mortals.
- [2014-10-10 14:18:18] <Pretorian> I can't think of anything right now, but I'm sure there's some functionality I'm not thinking of.
All in all, I think WNFT provides a greater flexibility and is generally better suited to manage these type of restrictions.