Introduce METADATA soju.im/alert #73

amk commented 2025年10月20日 13:36:33 +02:00

This introduces a new metadata option that when set by a user will
inform the client that all messages sent on that buffer should display
a notification to the user.

This introduces a new metadata option that when set by a user will inform the client that all messages sent on that buffer should display a notification to the user.

sentriz commented 2025年10月20日 13:43:20 +02:00

related https://todo.sr.ht/~emersion/soju/107

at least for the usecase of always receiving notifications for some channels

related https://todo.sr.ht/~emersion/soju/107 at least for the usecase of always receiving notifications for some channels

emersion commented 2025年10月23日 22:23:29 +02:00

How does this interact with:

• soju.im/muted: it seems a bit weird to set a channel as muted and to ask to be notified each time a message is sent. Not sure we want to add dependencies between metadata keys though...
• The existing -relay-detached=message setting for channels? It sounds pretty similar? I'm not sure we want to introduce two knobs for the same thing.
• Instead of a boolean, would it make more sense to add a tri-state, e.g. soju.im/notify=none|highlight|message? Hm, but still wouldn't let us get rid of soju.im/muted or else we'd break existing clients... (Also as discussed above not sure all values make sense for users...)

How does this interact with: - `soju.im/muted`: it seems a bit weird to set a channel as muted _and_ to ask to be notified each time a message is sent. Not sure we want to add dependencies between metadata keys though... - The existing `-relay-detached=message` setting for channels? It sounds pretty similar? I'm not sure we want to introduce two knobs for the same thing. - Instead of a boolean, would it make more sense to add a tri-state, e.g. `soju.im/notify=none|highlight|message`? Hm, but still wouldn't let us get rid of `soju.im/muted` or else we'd break existing clients... (Also as discussed above not sure all values make sense for users...)

amk commented 2025年10月24日 12:53:07 +02:00

@emersion wrote in #73 (comment):

How does this interact with:

* `soju.im/muted`: it seems a bit weird to set a channel as muted _and_ to ask to be notified each time a message is sent. Not sure we want to add dependencies between metadata keys though...

Yeah I thought about this, as it stands muting a channel will take precedence and notifications wont come through which I think is as one would expect. Having soju toggle muted when alert is set and vice versa and broadcast the METADATA SET for the automatically toggled entry might be an okay solution, but I'm not sure if that's a good behavior

* The existing `-relay-detached=message` setting for channels? It sounds pretty similar? I'm not sure we want to introduce two knobs for the same thing.

I'm not sure how this works, does it basically operate as BouncerServ sending a DM that there was a message in channel x? I think that does have some overlap but with this it does make it easier to build UI and also not require setting channels as detached, I havent used that feature of soju though so dont know much about it.

* Instead of a boolean, would it make more sense to add a tri-state, e.g. `soju.im/notify=none|highlight|message`? Hm, but still wouldn't let us get rid of `soju.im/muted` or else we'd break existing clients... (Also as discussed above not sure all values make sense for users...)

Yeah I think this would be ideal but the process of migration seems like itd be fairly painful. We could keep soju.im/muted and have it exist as a deprecated front for soju.im/notify maybe?

@emersion wrote in https://codeberg.org/emersion/soju/pulls/73#issuecomment-7873721: > How does this interact with: > > * `soju.im/muted`: it seems a bit weird to set a channel as muted _and_ to ask to be notified each time a message is sent. Not sure we want to add dependencies between metadata keys though... Yeah I thought about this, as it stands muting a channel will take precedence and notifications wont come through which I think is as one would expect. Having soju toggle muted when alert is set and vice versa and broadcast the METADATA SET for the automatically toggled entry might be an okay solution, but I'm not sure if that's a good behavior > > * The existing `-relay-detached=message` setting for channels? It sounds pretty similar? I'm not sure we want to introduce two knobs for the same thing. I'm not sure how this works, does it basically operate as BouncerServ sending a DM that there was a message in channel x? I think that does have some overlap but with this it does make it easier to build UI and also not require setting channels as detached, I havent used that feature of soju though so dont know much about it. > * Instead of a boolean, would it make more sense to add a tri-state, e.g. `soju.im/notify=none|highlight|message`? Hm, but still wouldn't let us get rid of `soju.im/muted` or else we'd break existing clients... (Also as discussed above not sure all values make sense for users...) Yeah I think this would be ideal but the process of migration seems like itd be fairly painful. We could keep `soju.im/muted` and have it exist as a deprecated front for `soju.im/notify` maybe?

emersion commented 2025年10月28日 18:55:27 +01:00

Having soju toggle muted when alert is set and vice versa and broadcast the METADATA SET for the automatically toggled entry might be an okay solution, but I'm not sure if that's a good behavior

Yeah, it's a bit annoying to implement. (If we go for soju.im/notify, we'd need to do something similar.)

does it basically operate as BouncerServ sending a DM that there was a message in channel x?

Detached channels are hidden from clients but still joined. Enabling -relay-detached=message means that the user is interested in being notified about all messages in the channel, which results in BouncerServ relaying these messages. I think we could have a single setting notify=none|highlight|message which works when the channel is attached and when it's detached, instead of two separate knobs. I'm not suggesting that we re-use that setting as-is, I'm suggesting that we could generalize it for attached channels.

Yeah I think this would be ideal but the process of migration seems like itd be fairly painful. We could keep soju.im/muted and have it exist as a deprecated front for soju.im/notify maybe?

Yeah, with some work (as hinted above), it can be a solution I think.

If we make this new setting a channel thing DB-wise, then we'd need to store the metadata value differently depending on whether it's a channel vs user.

> Having soju toggle muted when alert is set and vice versa and broadcast the METADATA SET for the automatically toggled entry might be an okay solution, but I'm not sure if that's a good behavior Yeah, it's a bit annoying to implement. (If we go for `soju.im/notify`, we'd need to do something similar.) > does it basically operate as BouncerServ sending a DM that there was a message in channel x? Detached channels are hidden from clients but still joined. Enabling `-relay-detached=message` means that the user is interested in being notified about all messages in the channel, which results in BouncerServ relaying these messages. I think we could have a single setting `notify=none|highlight|message` which works when the channel is attached and when it's detached, instead of two separate knobs. I'm not suggesting that we re-use that setting as-is, I'm suggesting that we could generalize it for attached channels. > Yeah I think this would be ideal but the process of migration seems like itd be fairly painful. We could keep soju.im/muted and have it exist as a deprecated front for soju.im/notify maybe? Yeah, with some work (as hinted above), it can be a solution I think. If we make this new setting a channel thing DB-wise, then we'd need to store the metadata value differently depending on whether it's a channel vs user.

amk commented 2025年10月30日 13:50:34 +01:00

Okay I think this all make sense to me, the plan I'll go for is to

• add a column to MessageTarget called notify that uses the existing MessageFilter semantics
• Maybe rename the relay_detached column and usage to be notify for consistency?
• migrate the muted column to use the new notify column in MessageTarget as well as migrating the existing values to the relay_detached column in Channels
• keep current relay_detached behavior on detached channels, for attached channels send notifications as configured
• when listing metadata include notify metadata retrieved from Channels in addition to MessageTarget
• For clients subscribed soju.im/muted set it to true only if notify is set to None, when modifying muted send metadata notifications to clients subscribed to soju.im/notify that its been updated

Okay I think this all make sense to me, the plan I'll go for is to - add a column to `MessageTarget` called notify that uses the existing `MessageFilter` semantics - Maybe rename the relay_detached column and usage to be notify for consistency? - migrate the `muted` column to use the new `notify` column in `MessageTarget` as well as migrating the existing values to the `relay_detached` column in `Channels` - keep current `relay_detached` behavior on detached channels, for attached channels send notifications as configured - when listing metadata include notify metadata retrieved from Channels in addition to MessageTarget - For clients subscribed `soju.im/muted` set it to true only if `notify` is set to None, when modifying muted send metadata notifications to clients subscribed to `soju.im/notify` that its been updated

This pull request has changes conflicting with the target branch.