jdev - 2020-04-28

they dont need to be closed

they are restarted

ah, that was the concept, "restart" https://xmpp.org/rfcs/rfc6120.html#streams-negotiation-restart I was probably falling asleep already

thanks 🙂

but this is mentioned again under https://tools.ietf.org/html/rfc6120#section-5.4.3.3

explicitly client MUST not send </stream> ✏

How do other servers behave is there's some database error when adding archiving a message? (context: MAM)

Zash: should be configurable and default to retry-panic

send a message error?

question is, what the 'ignore' behavior should be? send one message (per day?) to the user stating that his messages are not archived? ✏

panic = kill the server?

I didn't ask what they should do. I asked what they *do*.

good question if the message type should be error, but probably the answer is yes

as long as there is a <body/>, and not just some error code that is often not shown to the user

Zash, I know. But I expect some (most?) devs don't know, as error code paths are often not well tested

or even not well known to the devs

hmm another nice settings to have would probably be retry-notify-admin-ignore

I know what Prosody does as I've written a bunch of that code. No idea what ejabberd or Openfire or others do.

Holger, any idea about ejabberd?

Guus, any idea about openfire?

Unsure. Probably silently ignore after writing the error to the logfile

So it's about a DB error on writing the MAM message? Then it's the same for ejabberd.

And Prosody too, ignore and carry on trying to deliver the message.

and write something to the error log

Holger, DB error is the DB returning an error and/or the DB connection lost?

Both (if re-establishing the connection fails).

i find it weird that you want to inform a user if something database wise happens on the server

why not send a message to the admin?

User cant do anything about it, but informing the administrator

well the user's experience is degraded, doesn't strike me as the badest idea to inform him ✏

so that at least he knows that there is a reason his other clients do not show the same messages as he is used too

A Adminstrator can also inform the users?

note that I am talking about MAM archival not working, for whatever reason

is this not his job if the service is degraded?

lovetox, sure, that is why is also considered retry-notify-admin-ignore as setting

I would not send messages to users they can do nothing about other than notifying the admin.

often database errors are simply returned to the requesting entity. for example, think if pubsub publish: if the item could not be persistet, then a service would probably return an IQ error

I think the options are "just notify the admin" vs. "bounce the message with an error".

Holger, bounce the message to whom?

The sender.

but the message stil gets delivered?

why should the sender care that the recipients MAM archive does not work?

I think this all depends on whether you want to have a store-and-forward system or not.

bouncing an error to the sender if the message got delivered is going to be confusing

flow, well the question is whether MAM is considered critical or not.

although, an excellent use-case of @type='continue'

I've assumed that delivery is the priority.

but still, the sender can use that info even less

also careful with notifying the admin on a busy server. don't do that for every message :p

Zash, the alternative to store-and-forward is potentially-store-and-forward?

If so, I lean towards potentially-store-and-forward

for all server errors, inform admin, admin can decide if he informs his users

elitistly, I may say: logging as error should be enough. You should have monitoring which picks up on that.

jonas’, if a message is not delivered the sender does need an error message to be aware of the issue.

but all those log monitoring stacks are insane

Holger, 100% agree

I’m reading backlog and replying ;)

jonas’, true, but it's kinda right there to have your xmpp server notify the admin about issues ;)

Users (other devices) do get a hint that messages aren't stored, at least Prosody only adds the stanza-id if it successfully archived the message, which shows up in carbons.

flow, sure

mod_error_to_message which hooks into logging and rate-limitedly forwards error log messages to the admin?

ideally rate-limited by message template ✏

"error: %s (and %d more instances)" | format("foo %s bar %d baz" | format(original_logging_arguments...), number_of_logentries_in_ratelimit_bucket)

I see why a service with thousands of users may not be keen on users to be automatically notified about a MAM outage, but I could imagine I would run my personal family service with such a setting enabled ✏

do servers still assign a stanza-id on inbound messages if archiving fails?

if not, a client could detect that passively and display an inline warning about that

i'd assume that you can not assign an archive ID if your archive is unavaible

it’s perfectly possible

well unless you do the ejabberd thingy

if you uuidgen all your IDs, you can do that before storing and only later realize that you did it

I think '313 should specifically forbid that; it’ll cause pain once the archive service is restored

it is still kind of odd that you assign an archive ID without being sure that this message will ever hit the archive

flow: But you're just adding a `<stanza-id/>` which you may well want to do independently of MAM, no?

flow: Didn't the XEP-0359 author consciously make this an independent XEP?

uff, but then you’re in fun trouble

because a client may have to do a full archive download because MAM will tell it that it doesn’t know that ID

maybe set the hostname as issuer of the id instead of the account?

ejabberd doesn't add a `<stanza-id/>` if the message wasn't archived, but I would've thought doing so would be perfectly fine. And I considered doing so in the past as some client dev(s) had some non-MAM related use case.

Holger, true, but in this case the 'by' attribute of <stanza-id/> is typically known to be an address of an archive too

cc @ MattJ

but yes, there is nothing in xep359 which would prevent you from adding a stanza-id even if the archive is currentlyd own

and I would not want it any other way

If that's not fine I don't see why 0359 would be a separate XEP at all. Given that 0313 hard-depends on it.

Holger, there are other use-cases for stanza-id besides MAM, aren’t there?

So if clients need to know whether a message was archived we need a separate flag besides the <stanza-id/>.

yeah, there is also the possibility that an alternative to MAM emerges that could also re-use xep359

Holger, or, maybe better, a flag that the message was not archived ✏

Or both.

is there an advantage in having both? seems unnecessary to me, compared to simply flag the unexpected/unusual case

flow, both allows a client to passively detect the support for setting the flags on the server

no flag present -> no support; one flag present -> support && clear statement; both flags present -> ????

The client can't deduce a message was archived from the absence of a wasn't-archived flag, no? Except we add another feature.

That.

i mean, we could have a stream feature that says "i-will-archive-messages-unless-flaged" ✏

Yes that would work as well.

History: XEP-0313 originally had <archived id='...'/> and that certainly conveyed meaning that we have lost with the current protocol

I have considered bringing it back (we really have to make the decision now)

I can't commit any brainpower to this today, but if the question is "do clients need to be told that a stanza was archived, and by whom", I think the answer is 'yes'.

What about the inverse?

What's the inverse?

Do clients need to be told about failure to archive?

Kev, what does M-Link do if archiving fails?

Part of the reason I was hesitant, is because with the IM-NG approach, I'm not sure there is much need for the additional signalling

MattJ, signalling is useful in case of errors

like the other day on yaxim

It's questionable what should happen in that case

if a client knows that a stanza was, contrary to expectations, not archived, then you can avoid querying that stanza-id on next connect, leading to fun issues

Should the stanza even be delivered? :)

Great, let's re-add `<archived id='...'/>` into MAM and kill 0359.

that’s a good question and should probably be configurable, but orthogonal, I think.

Pre-MAM, failure to store an offline message would generate an error bounce

if you ask me, the server should assign IDs and queue messages for archival and try it’s best to do it later

MAM is basically per-device offline, and what we're saying is that partial delivery (i.e. only to currently online devices) counts as delivery, so it's ok

what if the message was delivered to one of three clients, stored in offline store, but not MAM-archived?

while havnig the message delivered with a flag indicating that it may not have been archived

but that’s expensive to do, resource wise

jonas’: your suggestion would lead to an OOM crash with all the messages getting lost eventually

What if you can't archive the archiving failure notification?!!??!!!!?‽!!?

Zash: what if you generate an archiving failure notification for each archiving failure notification?

🤯️