marc0sah, that was the concept, "restart" https://xmpp.org/rfcs/rfc6120.html#streams-negotiation-restart I was probably falling asleep already
marc0sthanks 🙂
lovetoxbut this is mentioned again under https://tools.ietf.org/html/rfc6120#section-5.4.3.3
lovetoxexplicitly client MUST not send </close>
Meta Bergmanhas joined
lovetoxexplicitly client MUST not send </stream>
Marchas joined
Alexhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
debaclehas joined
wurstsalathas joined
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
lovetoxhas left
asterixhas joined
goffihas joined
pulkomandyhas joined
pulkomandyhas left
lovetoxhas joined
pulkomandyhas joined
lovetoxhas left
lovetoxhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
debaclehas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
asterixhas joined
larmahas left
larmahas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
pulkomandyhas joined
sonnyhas left
sonnyhas joined
sonnyhas left
sonnyhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
ZashHow do other servers behave is there's some database error when adding archiving a message? (context: MAM)
flowZash: should be configurable and default to retry-panic
flowquestion is, what the 'ignore' behavior should be? send once message (per day?) to the user stating that his messages are not archived?
Ge0rGsend a message error?
flowquestion is, what the 'ignore' behavior should be? send one message (per day?) to the user stating that his messages are not archived?
Ge0rGpanic = kill the server?
pulkomandyhas joined
ZashI didn't ask what they should do. I asked what they *do*.
flowgood question if the message type should be error, but probably the answer is yes
flowas long as there is a <body/>, and not just some error code that is often not shown to the user
flowZash, I know. But I expect some (most?) devs don't know, as error code paths are often not well tested
flowor even not well known to the devs
flowhmm another nice settings to have would probably be retry-notify-admin-ignore
ZashI know what Prosody does as I've written a bunch of that code. No idea what ejabberd or Openfire or others do.
flowHolger, any idea about ejabberd?
flowGuus, any idea about openfire?
asterixhas left
jdevhas joined
GuusUnsure. Probably silently ignore after writing the error to the logfile
asterixhas joined
HolgerSo it's about a DB error on writing the MAM message? Then it's the same for ejabberd.
ZashAnd Prosody too, ignore and carry on trying to deliver the message.
Zashand write something to the error log
flowHolger, DB error is the DB returning an error and/or the DB connection lost?
HolgerBoth (if re-establishing the connection fails).
pulkomandyhas left
lovetoxi find it weird that you want to inform a user if something database wise happens on the server
lovetoxwhy not send a message to the admin?
lovetoxUser cant do anything about it, but informing the administrator
flowwell the users UX is degraded, doesn't strike me as the badest idea to inform him
flowwell the user's experience is degraded, doesn't strike me as the badest idea to inform him
flowso that at least he knows that there is a reason his other clients do not show the same messages as he is used too
lovetoxA Adminstrator can also inform the users?
flownote that I am talking about MAM archival not working, for whatever reason
lovetoxis this not his job if the service is degraded?
flowlovetox, sure, that is why is also considered retry-notify-admin-ignore as setting
HolgerI would not send messages to users they can do nothing about other than notifying the admin.
flowoften 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
HolgerI think the options are "just notify the admin" vs. "bounce the message with an error".
flowHolger, bounce the message to whom?
pulkomandyhas joined
HolgerThe sender.
flowbut the message stil gets delivered?
flowwhy should the sender care that the recipients MAM archive does not work?
ZashI think this all depends on whether you want to have a store-and-forward system or not.
jonas’bouncing an error to the sender if the message got delivered is going to be confusing
Holgerflow, well the question is whether MAM is considered critical or not.
jonas’although, an excellent use-case of @type='continue'
ZashI've assumed that delivery is the priority.
jonas’but still, the sender can use that info even less
pep.also careful with notifying the admin on a busy server. don't do that for every message :p
flowZash, the alternative to store-and-forward is potentially-store-and-forward?
flowIf so, I lean towards potentially-store-and-forward
lovetoxfor all server errors, inform admin, admin can decide if he informs his users
jonas’elitistly, I may say: logging as error should be enough. You should have monitoring which picks up on that.
Holgerjonas’, if a message is not delivered the sender does need an error message to be aware of the issue.
jonas’but all those log monitoring stacks are insane
jonas’Holger, 100% agree
jonas’I’m reading backlog and replying ;)
flowjonas’, true, but it's kinda right there to have your xmpp server notify the admin about issues ;)
ZashUsers (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.
jonas’flow, sure
jonas’mod_error_to_message which hooks into logging and rate-limitedly forwards error log messages to the admin?
jonas’ideally rate-limited by type
jonas’ideally rate-limited by message template
jonas’"error: %s (and %d more instances)" | format("foo %s bar %d baz" | format(original_logging_arguments...), number_of_logentries_in_ratelimit_bucket)
flowI see why service with thousands of users do not like the 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
kikuchiyohas left
flowI 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
kikuchiyohas joined
kikuchiyohas left
jonas’do servers still assign a stanza-id on inbound messages if archiving fails?
jonas’if not, a client could detect that passively and display an inline warning about that
flowi'd assume that you can not assign an archive ID if your archive is unavaible
jonas’it’s perfectly possible
flowwell unless you do the ejabberd thingy
jonas’if you uuidgen all your IDs, you can do that before storing and only later realize that you did it
jonas’I think '313 should specifically forbid that; it’ll cause pain once the archive service is restored
flowit is still kind of odd that you assign an archive ID without being sure that this message will ever hit the archive
Holgerflow: But you're just adding a `<stanza-id/>` which you may well want to do independently of MAM, no?
Holgerflow: Didn't the XEP-0359 author consciously make this an independent XEP?
jonas’uff, but then you’re in fun trouble
jonas’because a client may have to do a full archive download because MAM will tell it that it doesn’t know that ID
Zashmaybe set the hostname as issuer of the id instead of the account?
Holgerejabberd 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.
flowHolger, true, but in this case the 'by' attribute of <stanza-id/> is typically known to be an address of an archive too
jonas’cc @ MattJ
flowbut yes, there is nothing in xep359 which would prevent you from adding a stanza-id even if the archive is currentlyd own
flowand I would not want it any other way
HolgerIf that's not fine I don't see why 0359 would be a separate XEP at all. Given that 0313 hard-depends on it.
jonas’Holger, there are other use-cases for stanza-id besides MAM, aren’t there?
HolgerSo if clients need to know whether a message was archived we need a separate flag besides the <stanza-id/>.
flowyeah, there is also the possibility that an alternative to MAM emerges that could also re-use xep359
flowHolger, or, maybe better, a flat that the message was not archived
flowHolger, or, maybe better, a flag that the message was not archived
HolgerOr both.
flowis there an advantage in having both? seems unnecessary to me, compared to simply flag the unexpected/unusual case
jonas’flow, both allows a client to passively detect the support for setting the flags on the server
flowi mean, we could have a stream feature that this "i-will-archive-messages-unless-flaged"
jonas’no flag present -> no support; one flag present -> support && clear statement; both flags present -> ????
HolgerThe client can't deduce a message was archived from the absence of a wasn't-archived flag, no? Except we add another feature.
HolgerThat.
flowi mean, we could have a stream feature that says "i-will-archive-messages-unless-flaged"
HolgerYes that would work as well.
Martinhas left
Martinhas joined
pulkomandyhas left
pulkomandyhas joined
pulkomandyhas left
MattJHistory: XEP-0313 originally had <archived id='...'/> and that certainly conveyed meaning that we have lost with the current protocol
MattJI have considered bringing it back (we really have to make the decision now)
kikuchiyohas joined
kikuchiyohas left
pulkomandyhas joined
KevI 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'.
ZashWhat about the inverse?
MattJWhat's the inverse?
ZashDo clients need to be told about failure to archive?
ZashKev, what does M-Link do if archiving fails?
MattJPart 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
jonas’MattJ, signalling is useful in case of errors
jonas’like the other day on yaxim
asterixhas left
asterixhas joined
MattJIt's questionable what should happen in that case
jonas’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
MattJShould the stanza even be delivered? :)
Ge0rGGreat, let's re-add `<archived id='...'/>` into MAM and kill 0359.
jonas’that’s a good question and should probably be configurable, but orthogonal, I think.
MattJPre-MAM, failure to store an offline message would generate an error bounce
jonas’if you ask me, the server should assign IDs and queue messages for archival and try it’s best to do it later
MattJMAM 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
Ge0rGwhat if the message was delivered to one of three clients, stored in offline store, but not MAM-archived?
jonas’while havnig the message delivered with a flag indicating that it may not have been archived
jonas’but that’s expensive to do, resource wise
jdevhas left
Ge0rGjonas’: your suggestion would lead to an OOM crash with all the messages getting lost eventually
asterixhas left
kikuchiyohas joined
kikuchiyohas left
asterixhas joined
ZashWhat if you can't archive the archiving failure notification?!!??!!!!?‽!!?
asterixhas left
asterixhas joined
Ge0rGZash: what if you generate an archiving failure notification for each archiving failure notification?