This should be closed since it was completed. I must have not gotten the comment on the commit correct to close automatically.
Maybe on a mouse click, unminimize the join/part to show the part message or join details.
What are the use-cases for this feature here?
Right, that is why I was asking the question. I'm not sure why you would detach a network unless you were using multi-upstream. If you were using single upstream, I assume you would just disconnect your client from that network. That way you aren't removing the network from every client.
Is the network portion of this still relevant with the removal of multi-upstream and should there be
channel detachcommands for the service in addition to what currently exists?
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.
Another attempt is here. https://lists.sr.ht/~emersion/soju-dev/patches/33206 May need more cleanup.
Add display of configuration to status commands when a specific channel or network is specified. For example
server status libera
First pass should be the configuration in the database, for future display current and database configuration if they differ.
Another future improvement add an
-allflag to show all the configuration for the channel or server, even if it is the default values.