Groupchats

PapaTutuWawa commented

2022-11-29 18:53:36 +00:00

Owner

It's still unclear as to whether we should bet on MIX or just go with MUC. If we go with MUC, however, the issue would be how do we deal with clients that cannot be constantly online?

👍 1

PapaTutuWawa added the

labels 2022-11-29 18:53:37 +00:00

MattJ commented

2023-01-20 14:06:36 +00:00

My opinion is that you should just go for MUC. Widespread implementation and deployment of MIX on the public network is not likely to happen any time soon and it still has unresolved issues. If you're working on a fresh closed system that maps well to MIX, it's a fine choice though.

I'm not sure I understand exactly what you mean by "how do we deal with clients that cannot be constantly online". There are a few aspects to this:

Presence: Modern clients should display the list of affiliated users in preference to the list of currently-connected occupants. This is possible in the currently-deployed protocol, but XEP-0463 will make it considerably easier and I'd like to implement it in Prosody soon.
Push notifications. Typically users want notifications when they are mentioned, or possibly on every message (private groups). There are two approaches in use today, and I wrote about them here.

If you have any more specific questions, I can provide advice or pointers :)

My opinion is that you should just go for MUC. Widespread implementation and deployment of MIX on the public network is not likely to happen any time soon and it still has unresolved issues. If you're working on a fresh closed system that maps well to MIX, it's a fine choice though. I'm not sure I understand exactly what you mean by "how do we deal with clients that cannot be constantly online". There are a few aspects to this: - Presence: Modern clients should display the list of affiliated users in preference to the list of currently-connected occupants. This is possible in the currently-deployed protocol, but [XEP-0463](https://xmpp.org/extensions/xep-0463.html) will make it considerably easier and I'd like to implement it in Prosody soon. - Push notifications. Typically users want notifications when they are mentioned, or possibly on every message (private groups). There are two approaches in use today, and [I wrote about them here](https://github.com/snikket-im/snikket-ios/issues/145#issuecomment-951967852). If you have any more specific questions, I can provide advice or pointers :)

PapaTutuWawa commented

2023-01-20 16:41:42 +00:00

Poster

Owner

By "cannot be constantly online" I mean the following example:

Client goes online, enables SM with resumption, enabled push notifications
Client gets killed by OS
SM resumption interval times out
Groupchat receives message

As far as I know, vanilla MUC would not send the message to the client's JID and thus, even with enabled push notifications, not trigger a notification. Reading the linked issue, muc_offline_delivery is what takes the worry off my mind but as that is not standard behaviour (or a standard XEP), it feels hacky.

The thing with the list of affiliated users instead of the currently online users also seems very interesting. That's good to know.

By "cannot be constantly online" I mean the following example: - Client goes online, enables SM with resumption, enabled push notifications - Client gets killed by OS - SM resumption interval times out - Groupchat receives message As far as I know, vanilla MUC would not send the message to the client's JID and thus, even with enabled push notifications, not trigger a notification. Reading the linked issue, `muc_offline_delivery` is what takes the worry off my mind but as that is not standard behaviour (or a standard XEP), it feels hacky. The thing with the list of affiliated users instead of the currently online users also seems very interesting. That's good to know.

RogueRen commented

2023-01-20 16:51:02 +00:00

By "cannot be constantly online" I mean the following example:

Client goes online, enables SM with resumption, enabled push notifications

Client gets killed by OS

SM resumption interval times out

Groupchat receives message

As far as I know, vanilla MUC would not send the message to the client's JID and thus, even with enabled push notifications, not trigger a notification. Reading the linked issue, muc_offline_delivery is what takes the worry off my mind but as that is not standard behaviour (or a standard XEP), it feels hacky.

The thing with the list of affiliated users instead of the currently online users also seems very interesting. That's good to know.

Would existing MUCs be converted to MIX and function correctly in Moxxy? If so then wouldn't that be a non-issue?

> By "cannot be constantly online" I mean the following example: > - Client goes online, enables SM with resumption, enabled push notifications > - Client gets killed by OS > - SM resumption interval times out > - Groupchat receives message > > As far as I know, vanilla MUC would not send the message to the client's JID and thus, even with enabled push notifications, not trigger a notification. Reading the linked issue, `muc_offline_delivery` is what takes the worry off my mind but as that is not standard behaviour (or a standard XEP), it feels hacky. > > The thing with the list of affiliated users instead of the currently online users also seems very interesting. That's good to know. Would existing MUCs be converted to MIX and function correctly in Moxxy? If so then wouldn't that be a non-issue?

MattJ commented

2023-01-20 17:00:22 +00:00

As far as I know, vanilla MUC would not send the message to the client's JID and thus, even with enabled push notifications, not trigger a notification.

There are a couple of solutions for this (e.g. XEP-0452), but you're right that we've not yet settled on one as a community. Both MUC and "Push 2.0" are on the agenda for the XMPP summit in a few weeks, so I'm hoping the community can come to some agreement on which solution to proceed with then.

Would existing MUCs be converted to MIX and function correctly in Moxxy? If so then wouldn't that be a non-issue?

MUCs won't just upgrade overnight, as that would lock out all the MUC clients (which is basically... all of them).

One approach would be a MIX<->MUC bridge on the server. I'm only aware of one, in Tigase, and I think it only works with MUCs hosted on the same server. I tried to implement one in Prosody, but there are various places where MUC and MIX are very different and hard to bridge transparently.

My opinion is that MUC already works, and we have been improving it continuously for a long time. There is no reason we can't continue to do so - we don't need to break everything and spend years transitioning to an entirely different group protocol with its own set of problems.

> As far as I know, vanilla MUC would not send the message to the client's JID and thus, even with enabled push notifications, not trigger a notification. There are a couple of solutions for this (e.g. [XEP-0452](https://xmpp.org/extensions/xep-0452.html)), but you're right that we've not yet settled on one as a community. Both MUC and "Push 2.0" are on the agenda for the XMPP summit in a few weeks, so I'm hoping the community can come to some agreement on which solution to proceed with then. > Would existing MUCs be converted to MIX and function correctly in Moxxy? If so then wouldn't that be a non-issue? MUCs won't just upgrade overnight, as that would lock out all the MUC clients (which is basically... all of them). One approach would be a MIX<->MUC bridge on the server. I'm only aware of one, in Tigase, and I think it only works with MUCs hosted on the same server. I tried to implement one in Prosody, but there are various places where MUC and MIX are very different and hard to bridge transparently. My opinion is that MUC already works, and we have been improving it continuously for a long time. There is no reason we can't continue to do so - we don't need to break everything and spend years transitioning to an entirely different group protocol with its own set of problems.

PapaTutuWawa commented

2023-01-20 18:25:54 +00:00

Poster

Owner

However, XEP-0452 does not provide the kind of "notification experience" users, expect, i.e. a notification for every message. That is why I feel like most of the "solutions" are more like workarounds until they are standardized and deployed in the wild.

Both MUC and "Push 2.0" are on the agenda for the XMPP summit in a few weeks [...]

I am curious to see what will come out of it.

However, XEP-0452 does not provide the kind of "notification experience" users, expect, i.e. a notification for every message. That is why I feel like most of the "solutions" are more like workarounds until they are standardized and deployed in the wild. > Both MUC and "Push 2.0" are on the agenda for the XMPP summit in a few weeks [...] I am curious to see what will come out of it.

PapaTutuWawa commented

2023-06-14 17:54:32 +00:00

Poster

Owner

Relevant first PR: moxxy/moxxmpp#46

PapaTutuWawa commented

2023-08-07 14:37:05 +00:00

Poster

Owner

Moxxy PR: moxxy/moxxy#300

Groupchats #174