TobiasAs messages of type error are usually not persistent in MAM, are there other mechanisms for persisted delivery errors?
stpeterhas joined
atomicwatchhas joined
singpolymaProbably should patch MAM modules to store the errors :)
Andrzejhas left
Ge0rGbut you need to store the "good" errors and not the "bad" errors
Marandaexample of "good" errors?
Ge0rGMaranda: recipient account doesn't exist
stpeterhas left
marc0shas left
marc0shas joined
atomicwatchhas left
marc0shas left
marc0shas joined
debaclehas joined
singpolymaGe0rG: what is a "bad" error?
adiaholichas left
Ge0rGsingpolyma: e.g. a client resource going offline, bouncing messages that were sent to a full JID
Ge0rGephemeral and permanent errors
singpolymaGe0rG: 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?✎
singpolymaGe0rG: 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? ✏
harry837374884has left
xnamedhas left
adiaholichas joined
neshtaxmpphas left
neshtaxmpphas joined
krauqhas left
adiaholichas left
krauqhas joined
Fishbowlerhas left
Fishbowlerhas joined
stpeterhas joined
stpeterhas left
Marandasingpolyma: archives exploding for one
singpolymaMaranda: 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?
adiaholichas joined
harry837374884has joined
Dele Olajidehas left
Samhas left
Samhas joined
Marandayes 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
rubihas left
rubihas joined
marc0shas left
marc0shas joined
neshtaxmpphas left
singpolymaI 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
neshtaxmpphas joined
singpolymabut errors seem important
marc0shas left
marc0shas joined
MarandaXMPP 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.
*IM*has left
Ge0rGsingpolyma: 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
singpolymaGe0rG: right. that sounds like a good baseline
rubihas left
rubihas joined
Fishbowlerhas left
Fishbowlerhas joined
MarandaAlso 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.
Ge0rGYeah.
singpolymaif you use sortable ids you can tombstone without having to actually store anything probably. but that's all implementation detail
MarandaMeaning 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.
Calvinhas joined
Ge0rGwe also have ephemeral messages like chat states that shouldn't go into MAM at all
Ge0rGbut 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)
MarandaSo I don't pick how "sortable ids" would help.
neshtaxmpphas left
singpolymaOh, I guess you need to know all the ids still unless they are fully sequential, not just sortable
*IM*has joined
neshtaxmpphas joined
MarandaGe0rG: FWIW I for example never stored chat states (only markers)
pasdesushihas left
moparisthebesthas left
Danielhas left
moparisthebesthas joined
Paganinihas joined
rebeld22has joined
marc0shas left
marc0shas joined
pasdesushihas joined
Danielhas joined
marc0shas left
marc0shas joined
neshtaxmpphas left
Dele Olajidehas joined
pasdesushihas left
derdanielhas left
pasdesushihas joined
adiaholichas left
chipmnkhas left
adiaholichas joined
debaclehas left
debaclehas joined
krauqhas left
mimi89999has left
adiaholichas left
krauqhas joined
adiaholichas joined
eevvoorhas left
antranigvhas left
krauqhas left
krauqhas joined
Dele Olajidehas left
raghavgururajanhas joined
Skull Fuckerhas left
papatutuwawahas left
mimi89999has joined
adiaholichas left
Ingolfhas left
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
*IM*has left
Dele Olajidehas joined
marc0shas left
marc0shas joined
adiaholichas joined
marc0shas left
marc0shas joined
Skull Fuckerhas joined
eevvoorhas joined
*IM*has joined
eevvoorhas left
harry837374884has left
eevvoorhas joined
goffiHi, 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
goffiThanks!
harry837374884has joined
Skull Fuckerhas left
Skull Fuckerhas joined
antranigvhas joined
marc0shas left
marc0shas joined
adiaholichas left
antranigvhas left
Skull Fuckerhas left
antranigvhas joined
adiaholichas joined
antranigvhas left
adiaholichas left
SteveFhas left
antranigvhas joined
Half-Shothas left
uhoreghas left
homebeachhas left
Matthewhas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
atomicwatchhas joined
adiaholichas joined
marc0shas left
marc0shas joined
bunghas joined
adiaholichas left
adiaholichas joined
eevvoorhas left
antranigvhas left
antranigvhas joined
adiaholichas left
adiaholichas joined
antranigvhas left
antranigvhas joined
*IM*has left
bunghas left
*IM*has joined
Calvinhas left
Calvinhas joined
raghavgururajanhas left
adiaholichas left
xnamedhas joined
eevvoorhas joined
Dele Olajidehas left
chipmnkhas joined
debaclehas left
antranigvhas left
Ray22has joined
FXTIAhas left
marc0shas left
marc0shas joined
FXTIAhas joined
antranigvhas joined
marc0shas left
marc0shas joined
antranigvhas left
antranigvhas joined
antranigvhas left
eevvoorhas left
antranigvhas joined
MSavoritias (fae,ve)has left
eevvoorhas joined
antranigvhas left
MSavoritias (fae,ve)has joined
marc0shas left
marc0shas joined
Andrzejhas joined
adiaholichas joined
Calvinhas left
antranigvhas joined
florettahas left
marc0shas left
marc0shas joined
MattJThere 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.