Multiple channels, multistreams, and the Permissions manager.

[joelaw9]

Something I noticed earlier: the permissions manager will handle multiple channels, but it doesn't handle multistreams. Duplicates of the same message id are discarded, which means only the first socket that receives the message will have its permissions reflected.

The only solution that comes to mind is to set up a multistream detector that hooks into the permissions manager to cycle through any streams in a multistream, expressing the combined permissions.

What are your thoughts?

[Tschrock]

I've never worked with multistreams before, so I don't know how those messages are handled. If I could get some clarity on how multistream chat works I may have some insight.

[joelaw9]

As far as Picarto is concerned, it's handled exactly the same. An instance of the bot running on Channel 1 that is a multistream with Channel 1 and Channel X will run fine. If a bot is running on Channel 1 and Channel 2 and they go into a multistream, then both sockets will receive the same input. So "userMsg" would receive both of the Examples from a single input.

Example 1
{
msg: "Test message from Channel 1 owner",
username: "Channel 1",
...
channel: "Channel 1",
id: "1111",
}
Example 2
{
msg: "Test message from Channel 1 owner",
username: "Channel 1",
...
channel: "Channel 2",
id: "1111",
}

Duplicates are discarded within "userMsg" via the inputLog check. If it isn't discarded, then a !request response will be sent twice, because it was received on both sockets.

This, however, means that if Example 1 is received first, only Channel 1's permissions are reflected for that message. There's no guarantee which would be received first so it'd be entirely inconsistent.

This would also affect any custom commands, since they depend on the channel.

AFAIK Picarto doesn't trigger any event for the chat to indicate a multistream. There's no way to tell if any particular channel is multistreaming aside from getting multiple messages with the same id. I think anyway, I've been experimenting around and haven't been able to find anything.

[joelaw9]

An option I just thought of would be to use the admins as an indicator. There's only 1 admin per stream, so if there's multiple admins then it means there's a multistream.

[Tschrock]

Assuming ChannelName == AdminName that is a viable option. We are already keeping track of a user list for each channel.

[Tschrock]

^ That will work to merge permissions during multistreams, but there's still other problems. All stored data for commands/etc will act as though it's from whoever's socket got the message first. Maybe concat the multistreamed channels' names and use that as the channel/storage key? This would mean that multistreams would use completely separate settings, but would be consistent no matter which socket received the message.

[joelaw9]

If multistream detecting is set up then the data variable could get an additional 'multistream' property that contains an array of the participating channels. Then it can be handled on a per plugin basis.

I can't think of a one-size-fits-all that would hit every plugin and still retain each channel owners personal modifications without leaving it up to the plugins to handle. And ideally retaining each channel owners settings would be best to my mind. Permissions automatically handling it should be good enough.