Modern XMPP project discussion - 2022-06-02

Good morning :) I am currently embarking on the adventure of writing an xmpp client and have a question about MAM and carbons or history. I want my client to be able to fetch unreceived messages from the server and to allow other clients to also receive them independently. Did I understand correctly that this is only possible with MAM?

That’s exactly what MAM is for, yes. :)

If not, what is required to make this work?

Okay, good to know I at least got that part 😄

Is it necessary to implement carbons too, or would MAM be sufficient since it is supposed to replace carbons if I understand correctly?

No, Carbons is also useful for the time when more than one clients are online at the same time.

Carbons gets you messages sent by your other clients, along with all incoming regardless of priority settings

I see, I just saw that section on the modernxmpp.org site, sorry for asking prematurely :)

In the Multi-device section it mentions the problem of IDs of outgoing messages not being known. Do I understand correctly that these IDs are always assigned by the server and that the server does not tell the client the ID when sending?

It seems like strange design so I want to make sure I actually understood it

And can somebody explain what is meant by this sentence? It would be great to have this explained more practically: "Solving this issue may happen through an extension of Carbons (to reflect sent messages back to the sender with the ID added and any other additional info), or through a new MAM subscription protocol."

Can carbons already do this? Do I have to deviate from the specifications for this? And what is meant by "a new MAM subscription protocol"?

The server assigns IDs for use with (MAM) archives. Due to how messages are historically fire-and-forget, you don't know what these are and nobody has implemented a way to report this back yet.

Zash: Thanks for explaining :) So how do clients actually deal with this? Do clients just have to manually deduplicate the duplicate messages they would receive from the server when they ask for the history?

Not a client dev so can't answer, but I imagine you can use the message id attribute (separate from the archive id set by the server) to deduplicate. Are there any client devs around who can comment on what their implementations do?

I also had this thought of using the sender-assigned message ID, but yes, it would be good to see what other client devs have done :)