-
Tobias
As messages of type error are usually not persistent in MAM, are there other mechanisms for persisted delivery errors?
-
singpolyma
Probably should patch MAM modules to store the errors :)
-
Ge0rG
but you need to store the "good" errors and not the "bad" errors
-
Maranda
example of "good" errors?
-
Ge0rG
Maranda: recipient account doesn't exist
-
singpolyma
Ge0rG: what is a "bad" error?
-
Ge0rG
singpolyma: e.g. a client resource going offline, bouncing messages that were sent to a full JID
-
Ge0rG
ephemeral and permanent errors
-
singpolyma
Ge0rG: what would it be bad to store that? My client should be able to interpret it on replay the same way it interpreted it live, now?✎ -
singpolyma
Ge0rG: what would it be bad to store that? My client should be able to interpret it on replay the same way it interpreted it live, no? ✏
-
Maranda
singpolyma: archives exploding for one
-
singpolyma
Maranda: you mean getting "too big"? Is that a real fear? Are people receiving so many of these errors compared to the number of messages they send?
-
Maranda
yes depending what gets included in the archive and the implementation that could be a real fear, when I implemented MAM I always heavily filtered and sanitized the content and payloads getting archived
-
singpolyma
I my ideal implementation every inbound <message> stanza of any kind would get archived, but I could see why some might want to exclude typing indicators or sometning like that
-
singpolyma
but errors seem important
-
Maranda
XMPP never been light on dishing out transient errors, modern xmpp tends heavily relying on 'em (e.g. SM resending) so archiving all those ephemeral payloads can turn out into being explosive on higher scales, I guess.
-
Ge0rG
singpolyma: my rule of thumb would be: if a message is stored in MAM, then a delivery error related to that message needs to be stored as well
-
singpolyma
Ge0rG: right. that sounds like a good baseline
-
Maranda
Also there should be a mechanism to dump certain archive entries that aren't useful after they have been delivered, and MAM doesn't have a way yet to delete or purge entries, the spec mandates there shouldn't be holes in the archive so at most you can tombstone entries.
-
Ge0rG
Yeah.
-
singpolyma
if you use sortable ids you can tombstone without having to actually store anything probably. but that's all implementation detail
-
Maranda
Meaning that if you don't filter what you put into an archive properly you can have pretty easily situations where it becomes *too big*, because tombstones have to stay there and still occupy space.
-
Ge0rG
we also have ephemeral messages like chat states that shouldn't go into MAM at all
-
Ge0rG
but chat states should have been presence anyway
-
Maranda
> <singpolyma> if you use sortable ids you can tombstone without having to actually store anything probably. but that's all implementation detail I'm not sure I understand, when you tombstone an entry you can basically delete any element inside the forwarded payload (except the stanza attributes) but you can't omit all the rest e.g. whatever stays on the forward payload (SID and all the rest)
-
Maranda
So I don't pick how "sortable ids" would help.
-
singpolyma
Oh, I guess you need to know all the ids still unless they are fully sequential, not just sortable
-
Maranda
Ge0rG: FWIW I for example never stored chat states (only markers)
-
goffi
Hi, note to editors and council menbers: as I've mentioned a couple of days ago, I've update my protoXEP "pubsub attachments" to update the "reactions" feature so it is similar to XEP-0444. I've also fixed a case issue with "SHOULD NOT" instead of "SHOULT not" and updated business rules. PR is at https://github.com/xsf/xeps/pull/1191
-
goffi
Thanks!
-
MattJ
There is an IETF BoF meeting about messaging interop (MIMI WG) today at 20:00 UTC. I'm hoping to attend, but I'd appreciate it if anyone else is interested and available. Remote participation is via WebEx and I can dig up the details on request.