soju doesn't have plugins, and I'd prefer to keep it that way. However some users may still want to extend soju with custom logic.
I think using IRC as a a plugin IPC could be a good idea. This is also what the pounce IRC bouncer recommends.
One part of this is support for causal.agency/passive, which allows scripts to connect to the bouncer without changing the away status.
I think another part would something to allow snooping in the detached channels, without actually re-attaching. This would allow to implement a custom message watcher, similar to the ZNC watch module maybe.
Another piece of the puzzle could be a command to trigger arbitrary BouncerServ notice broadcasts. Need to think how to handle disconnected clients (some scripts may want to send the NOTICEs on client reconnect).
Thinking of what other bouncer's plugins can do and what clients scripts/plugins can do. I think the general types of things are as follows.
- Modify incoming messages
- Modify outgoing messages
- Filter incoming messages
- Filter outgoing messages
- Trigger on incoming messages
- Trigger on outgoing messages
- Send outgoing messages
- Send incoming/private messages to the user
From the issue, I'm guessing that modifying messages and filtering messages is a non-goal. Both because IRC doesn't have a good way of handling that and if it has to round trip to another process it will probably add too much lag time.
As for triggering on incoming or outgoing messages, that seems easy to do with this format, as would be sending public messages to channel/people. But not sure how we could accomplish sending messages just to the user that appear in a channel using normal IRC messages. Was wondering if it made sense to use a more flexible system for interchange. Partially because it would be far easier to deal with writing scripts if you didn't have to support the IRC spec, it would mean that simple scripts would more or less need to be IRC bots.
Could be accomplished using something like JSON or BARE or something else entirely, but wondered about having the connection not maintain state, just use tokens to authenticate each message and each script having an end point that soju hits per message? This would allow the scripts more flexibility as far as functionality and reduces the complexity of writing them in the first place, in my opinion.
Obviously there are countless different approaches, but those are my two cents worth.
- Modify incoming messages
- Modify outgoing messages
- Filter incoming messages
- Filter outgoing messages
This can be achieved with a small proxy.
- Trigger on incoming messages
- Trigger on outgoing messages
- Send outgoing messages
Yeah, this was what I had in mind when writing this issue.
- Send incoming/private messages to the user
A user can message themselves. With channel-context the message can appear in the context of another channel.
Was wondering if it made sense to use a more flexible system for interchange.
I'm not sure what this will buy us, apart from adding extra dependencies. IRC wire format parsers are widely available in all languages/platforms. You don't really need to maintain any state in a script. Even more involved tasks remain simple to implement, e.g. see chathistorysync.
IRC is the lingua franca for soju, I'd rather not invent a new thing here.
allows scripts to connect to the bouncer without changing the away status.