jdev - 2022-10-21

I'm thinking about adding a "message history backfilling" for 1:1 chats in my gateway. is there anything wrong with the following flow? 1. query the XMPP user's message archives (with "privileged IQs") 2. send missing messages with a "delay" tag (incoming messages from "puppet" JIDs, and outgoing messages with the privilege thing again) 3. profit (?)

nicoco: have a look at MAM, that's what you want I guess

it is what I want indeed, but for 1:1 chats the gateway component does not manage MAM, hence my idea to "privilege query MAM data" and only send "missing" messages

i dont understand what you want to do

1:1 messages are in the users archive on the server

the client querys that archive when it comes online

PSA: if any of your code does SHA3 please check the implementation immediately https://mouha.be/sha-3-buffer-overflow/

lovetox: when the gateway comes online, I want it to fill the archive with messages exchanged while it was offline. But I'd like these messages to be correctly timestamped. I believe. about the gajim #11048. what does it look like when the "delay is added by the server"? cause a component is "sortof a server" so I might be able to add this delay at the right place...

No it's not a server

Simply send the messages with a delay timestamp that's it

To the user

This has nothing to do with mam or archives

Some clients will show the delay others not that's nothing you can control

You should add all information that clients can do the right thing

Wouldn't that be better if people could just use MAM instead of being shoved messages whenever the gateway decides

No it's easier we follow what we did always, if someone wants to write me a message he needs to send it to my server

Why would we change that fundamental process?

you're mistaken lovetox, I don't want to change any fundamental process and it's perfectly fine if you don't want the UI to reflect the delay added by the gateway, I can fork if I'm not happy (I won't ^^)

You misunderstood, I replied to pep.

hmm, there are clients (mobile mostly?) that send delayed messages if they weren't connected when the user sent them

And also I never said I don't want ui for displaying delays

I try to help you implement the gateway, and I'm trying to tell you that you overthink the whole process, you add a delay and send the message to the server , there is not more to do

great then :) >you add a delay and send the message yes that's what I do for incoming message (legacy→XMPP) for "outgoing messages sent from $legacy_client", I use https://xmpp.org/extensions/xep-0356.html#sending_mess and I was wondering if it made sense/was OK to put the <delay> one level up (in <forwarded> instead of <message>) because of your comment.

How can you send forwarded?

That's business of my server to forward something or not?

just following this syntax: https://xmpp.org/extensions/xep-0356.html#example-6 (and it works)

nicoco, yeah no I agree that's weird to use MAM. Does that mean you do that for every message you send?

Ah it's not MAM here? ✏

Ok I have no experience with that xep sorry

nope, and I don't do it (yet?), that's why I'm asking for opinions to the wise XMPP gurus here :)

Oh no, do we need sync between MAMs?

Plz no

But if I register at your component I doubt my server would consider you privileged

pep.: nope, no MAM here, and no direct filling the MAM or anything that weird. However, with this: https://xmpp.org/extensions/xep-0356.html#iq_stanzas I could query MAM for a user

Yo dog I heard you liked MAM so I put some MAM into your MAM

and *IF* there are some missing messages, up to XXX days (which would be a parameter exposed to the user and/or the server admin), I just send them. I think that should work.

> Oh no, do we need sync between MAMs? I actually think MAM-aggregation might be quite handy.

there are several reasons why I'd like to do that: - the bad one, sorry: matrix bridges do that. but it's actually quite nice to have a conversation context when you start using the gateway

nicoco, I guess it would be weird if, whenever your gateway reconnects it fills MAM archive for messages that were sent while it was disconnected, and for new live messages it would just send them as usual. If the account using the bridge has been connected this whole time, they may not think about requesting MAM and they'd miss part of the chat

pep. there's no filling MAM directly, the gateway just sends messages, the server handles carboning and MAMing if appropriate

Ok

So yeah do that, send delayed messages :)

As your gateway

Well as your bridged user

now the good reason for wanting to do that: on some legacy networks, for instance mattermost, facebook messenger, skype (AFAIK) the socket for receiving incoming messages is sometimes dropped for a few seconds (or worse). when it reconnects, the client does not get messages that were sent while disconnected. I have 2 options to ensure that no message was dropped during this lapse of time: - keep track of which messages were not sent on my side - take advantage of MAM to know which messages needs sending I was contemplating option 2 because why reimplement message history when the server takes care of it? I also thought this might work for "backfilling" ✏

now the good reason for wanting to do that: on some legacy networks, for instance mattermost, facebook messenger, skype (AFAIK) the socket for receiving incoming messages is sometimes dropped for a few seconds (or worse). when it reconnects, the client does not get messages that were sent while disconnected. I have 2 options to ensure that no message was dropped during this lapse of time: - keep track of which messages were sent on the component side - take advantage of MAM to know which messages needs sending I was contemplating option 2 because why reimplement message history when the server takes care of it? I also thought this might work for "backfilling" ✏

Is that a requirement of your bridge? That the server supports MAM

Zash: don't worry, you don't have to do anything, and there's a single MAM, no need to sync multiple MAMs

(even though it's probably a rare thing by now, not supporting it)

pep.: not at all, but well, if I choose to implement option#2, MAM would be the way to ensure that you don't lose any message

you have a valid point, implementing option 1 is actually needed to ensure no message are dropped without MAM, *for some networks*. it's just a lot of hassle to keep track of all sent messages, and probably write them to disk to persist in case of component upgrade/host restart/whatever, and it seems to be double use

Yeah I may also choose #2

why reinvent the wheel right?

I did not even thought about that before the latest XEP0356 update that allows sending IQ on behalf of users, so blame "jp" :P

You can issue MAM requests just as a client would?

I think, yes, it's just an IQ, right?

>Yeah I may also choose #2 I'll probably do that, and if MAM is disabled for this user/server/whatever, notify the user every time the connection is dropped, "you're offline on the legacy network, messages may be lost", or something like that.

nicoco, what bridge are you developing, if that's not a secret?

selurvedu, https://git.sr.ht/~nicoco/slidge

pep., oh, right, I've got a tab open with https://duckduckgo.com/?tq=slixmpp+slidge open, forgot about it