XSF Discussion - 2023-01-25

emus: I can be backup

Daniel: Awesome, thanks!

I will invite you. You dont need a googlemail to register, just seoct to use your own mail

My regular email address is a Google account anyway

Daniel: ok sure, last time dev refused to participate because of this. Thats why I put on my list to clarify

For GSoC I am still looking for volunteers to support the creating of an XMPP quiz, I collect valuable and educational questions here: https://yopad.eu/p/XMPP-Quiz-365days It should help new developers to ask guiding questions and ensure in the end they have a basic understanding of the technology (maybe kinda impossible, but you know what I mean)

Are messages of type=error typically stored in MAM if the message they are "replying" to was stored in MAM?

larma: it depends. I think there was a hacky change in prosody to store all (or at least most) error messages in MAM, but I'm pretty sure there is no implementation that will query archives whether the original message was stored, or keep a list of in-flight messages.

I was just wondering, because not storing errors in MAM would mean that only the sending entity learns about something being wrong with the message, but all others (that retrieve the sent message from MAM) won't know and thing everything worked as intended

larma: yes

Context: MattJ made me look into XEP-0334 which says "A message containing the <store/> hint that is not of type 'error' SHOULD be stored by the entity." - and thereby making it not possible to mark an error as important for MAM

larma: yes, but errors are also generated by servers generally, and those don't know about MAM in that place of the code

Related: https://xmpp.org/extensions/xep-0280.html#recommended-rules

larma: if the message was stored in the recipient's MAM, should an error be returned at all?

so many questions.

Well, for MUC cases, I expected it to be very logical (even if not properly specified) that - Only the MUC itself can error, not participants - If the MUC errors to a message, that message is neither reflected, nor sent to other occupants in the room, nor stored in the MUCs MAM

Why would an occupant not be able to send an error?

> If the MUC errors to a message, that message is neither reflected, nor sent to other occupants in the room, nor stored in the MUCs MAM All of that seems like the right thing.

Kev, because it's sending that error to the MUC, which typically causes the MUC to just kick them, no?

Only for some errors, but yes - I was thinking of DMs.

One occupant can error to another in a DM legitimately, I think.

Ah, yeah for DMs that would work (but they're also not stored in MUCs MAM, but both occupants MAM, so situation is similar as direct chat) ✏

Indeed.

(Although carbons and MAM for DMs is itself contentious)

Beside that, I'd think it makes sense if MAM stores between sender and recipient that do not error have the following rule: if the intermediate entity sees an error in reply to a message stored in MAM it should store the error message in MAM as well (just like the carbons ruleset proposes)

Knowing that such an implementation isn't trivial 😉 ✏

I see a summit discussion looming. Hopefully the trains don't prevent UK folks getting there.

Are they on strike or something?

On Wednesday, when both Matt and I are travelling, yes.

At least they're announcing that a week in advance

I think that for the thin client approach, you probably don't even want messages that didn't get delivered to appear in your standard MAM query.

> At least they're announcing that a week in advance More, even. Oh! The luxury!

In Germany I remember them at a press conference around noon being like "Oh btw, starting today 6pm until tomorrow EOB, we'll be striking"

And then obviously all trains until 6pm are unbearably full

I'm coming back on Saturday, and they're striking Friday as well, so trains back are likely to be screwey.

I'm going to have a great time.

Damn, I totally missed the approaching deadline.

(and of course I just booked a complex series of trips for the whole second half of next week)