XSF Discussion - 2022-07-25


  1. Tobias

    As messages of type error are usually not persistent in MAM, are there other mechanisms for persisted delivery errors?

  2. singpolyma

    Probably should patch MAM modules to store the errors :)

  3. Ge0rG

    but you need to store the "good" errors and not the "bad" errors

  4. Maranda

    example of "good" errors?

  5. Ge0rG

    Maranda: recipient account doesn't exist

  6. singpolyma

    Ge0rG: what is a "bad" error?

  7. Ge0rG

    singpolyma: e.g. a client resource going offline, bouncing messages that were sent to a full JID

  8. Ge0rG

    ephemeral and permanent errors

  9. 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?

  10. 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?

  11. Maranda

    singpolyma: archives exploding for one

  12. 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?

  13. 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

  14. 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

  15. singpolyma

    but errors seem important

  16. 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.

  17. 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

  18. singpolyma

    Ge0rG: right. that sounds like a good baseline

  19. 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.

  20. Ge0rG

    Yeah.

  21. singpolyma

    if you use sortable ids you can tombstone without having to actually store anything probably. but that's all implementation detail

  22. 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.

  23. Ge0rG

    we also have ephemeral messages like chat states that shouldn't go into MAM at all

  24. Ge0rG

    but chat states should have been presence anyway

  25. 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)

  26. Maranda

    So I don't pick how "sortable ids" would help.

  27. singpolyma

    Oh, I guess you need to know all the ids still unless they are fully sequential, not just sortable

  28. Maranda

    Ge0rG: FWIW I for example never stored chat states (only markers)

  29. 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

  30. goffi

    Thanks!

  31. 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.