Extension idea: chat channels

Just had a random thought about implementing chat channels in ADC. Since the PM attribute in the MSG action allows for a group SID, the hub can arbitrarily assign SIDs that act as the host for chat channels. Below is a rough idea of a potential implementation. Supporting clients would broadcast the CHAN feature in the SU field.

  1. An operator (SID=ABCD) creates a chat channel, for which the hub assigns a SID e.g. a hub command like !join “Movie Chat”. The hub would internally allocate a SID, such as DCBA, to an identity named ‘Movie Chat’. It would also add the operator to a list of users in that channel.

  2. Another user, CABD, attempts to join the channel via the !join hub command. If the hub recognises the channel name, and authorises their entry to the channel, it sends an INF JCDCBA to the members of the DCBA channel, except CABD, where the JC parameter stands for Join Channel. I’m not sure which type of INF would be best, but the CABD SID must be sent as part of the message, so perhaps an Echo since CABD is indirectly the source.

  3. CABD receives an INF CNMovie\sChat, where CN is Channel Name. CABD’s client creates a new chat window, similar to a hub window (with chat area and user list), which has the title from the CN parameter.

  4. CABD receives an INF JCDCBA identifying each member of the channel, including itself.

  5. The user CABD decides to leave the channel, by closing the chat window. Their client sends INF PCDCBA i.e. Part Channel, which the hub forwards to all other members of the channel.

Additionally, if a group SID is registered by a bot (CT1 in the INF message when it connected) then the hub will forward all messages to that bot. This is sketchy in my head, but the benefit is that, for example, you can run a trivia bot in a seperate window from main chat, and still see all the users interacting with the bot.

The protocol doesn’t offer any guidance on the rationale for group-SID in the PM parameter of MSG, but I thought this might be a decent use of it. Thoughts?

Very good idea :slight_smile:
Yes, mainly this is the idea behind the group-sid feature, to make easy chatrooms.
But I don’t think it’s necessary to actually add a new extension.
Here is how I created operator chat in DSHub:
On operators login, they get something like
BINF ABCD NIOperator’s\schat

This means that the operator’s chat looks exactly like some user.
When the sid ABC5 sends some PM to the chat, it will look like this:
EMSG ABC5 ABCD here\sis\sthe\smsg PMABC5
However, the hub modifies the PM flag into
EMSG ABC5 ABCD here\sis\the\smsg PMABCD
In this way, the message looks like coming from ABC5 ( the client displays the nick accordingly), but the return SID is in fact ABCD, so all the replies go back to the chat, instead of going PM with that particular user.

To make join/part commands, the hub actually can send BINF ABCD for joining and IQUI ABCD for parting.

How does my solution sound ?

Oops, delayed response…

I have some concerns with having the chat channel show up as a user.

Firstly, it’s an information disclosure vulnerability, because everyone can see that such a channel exists. This means you can’t create truly private channels using this approach, though you can still control who is able to talk and view chatter in those channels. For this reason, I think a channel should be seperate from a user, but if the channel is a public one then it can be associated with a bot type of user to aid discoverability.

Secondly, the user interface in most clients allows the user to ‘send a private message’ to another user, but in this case the message is to a channel which is not necessarily private at all. I think this can be misleading to users - and it’s conflicting with the end of my previous point - maybe a ‘channel’ type of user in the CT parameter . A related note from the software side is that for the client to show an interface with a list of users, like the main public chat channel, it would need some indication that this is what is required of it, as opposed to a one-one private chat.

With the join/part commands, I know the hub can send the BINF and IQUI messages, but this only identifies that the user has left the hub, not just the specific channel. This would enable seperate ‘XYZ has left the channel’ and ‘XYZ has gone offline’ messages. I thought perhaps a parameter on IQUI would be better than my Part Channel parameter idea on the INF message, but if clients that don’t support the channel feature receive an IQUI and don’t know what to do with the parameter, they are likely to just process the message as an ‘XYZ has gone offline’ message and ignore the parameter; despite this being completely inappropriate behaviour for the situation, because the user is still online.

I think there are a few areas of the protocol, such as this one, where an accompanying guide outlining the spirit of the protocol would be beneficial. In this way, an implementor can read the reasoning behind different elements and better see what their nature is intended to be.

The big advantage of your solution though, is that it requires minimal additional work for the client code, beyond the existing public chat and one-one private message code. My solution is a bit more involved, and requires more work in both hub and client support.

As far as I can tell, there is nothing that says that information about a user must be sent to all users in the hub, i.e. having ‘hidden’ users is quite possible, even if it confuses the hell out of some clients :slight_smile:

Whether an extension is needed or not I dont know, but I think it would be very good if its documented somewhere how a chatroom is supposed to be handled.

As en_dator says, yes, the hub can send BINF and IQUI whenever it wants for the channel, and only for specific users.
Also, one could try the HI1 flag although some clients may use the information inappropriately.