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✎
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 ✏
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 ✏
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.
flowi mean, we could have a stream feature that says "i-will-archive-messages-unless-flaged" ✏
HolgerYes that would work as well.
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)
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
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
Ge0rGjonas’: your suggestion would lead to an OOM crash with all the messages getting lost eventually
ZashWhat if you can't archive the archiving failure notification?!!??!!!!?‽!!?
Ge0rGZash: what if you generate an archiving failure notification for each archiving failure notification?