Modern XMPP project discussion - 2021-08-22

Sam in you sync strategy it says

after: <last message time>

I don't think you can pass a time here

After needs an index in the dB, which should be the mam id

That's after-id, different thing

No I don't think so

There is no after in the mam spec

oh, it's called "start", not "after", right.

You mean after from the rsm spec

Rsm needs an index

I think I call it "After" in code, so I'll go fix it.

That's different and I leave that unset

Thanks for the catch!

That's not a good approach

Using start you will always get one duplicated message

Using rsm after is better

Yah, you'd have to do both. A single duplicate is the least of the problems with MAM though, but that does seem like a good idea to filter out the duplicate that way

I should convert this to a graphic, it's hard to read these bullet points.

Hmm, somehow the bullets don't work right on the page either, I thought they were working when I previewed it.

4 spaces apparently. Oops. Anyways, fixed both: https://github.com/modernxmpp/modernxmpp/pull/43

just to throw something meta in here: shouldn't the current room name here actually be the room description, and the title be something shorter, like e.g. only "Modern XMPP"?

lovetox: just added before/after to the current strategy; thanks. Not exactly the biggest change in the world, but nothing wrong with speeding this up by having one message less each time!

I am struggling to explain in the docs what they're for and why they're different from before-id and after-id, but if you don't have before-id and after-id available this is at least a practical use for them.

Also what it should be called; I made it a single field (since you can't set both <before/> and <after/>), so the unified ID field I called "PageID". I'm not sure if that actually makes sense.

Context?

Zash: lovetox suggested an improvement to my MAM sync strategy. I was just using start/end, but this results in a single duplicate message (the one we got the time from). Using RSM's "before/after" you can filter out that message though. However, in code I don't know what to call it (it's a single ID field since you can't set both, which one gets set is controlled by a boolean that already existed)

FWIW in Prosody there were always `before` and `after`

Internally

Direction is specified with a different field

So in MAM, `before-id` is just like the RSM `before` but without implying a reverse direction. Maybe it makes sense to do that at a higher level in the client too?

That's what I'm doing, I just don't know what to call the before/after field. There's already "BeforeID", "AfterID", and "PageDirection" or something. I called the thing that gets turned into <before/> or <after/> based on PageDirection "PageID" for now, but that seems unclear.

That seems weird and confusing to me

I guess I didn't understand what you were saying then, because I thought that's what you were describing.

I could have After and Before, but that seems more confusing because only one of them will actually be used and you have to know which one to set based on the direction bool.

Or I could get rid of the direction bool, but then what happens if you set both After and Before?

Turn one into before-id or after-id 🤷️

But that may or may not exist, as far as I know nobody supports mam#extended yet

Prosody (trunk) does, modulo storage backend support

Oh nice, I was looking for that and couldn't find it, that's good to know anyways. Amend that to "many people don't and they may or may not work"

But anyways, this is specifically for the case where that's not supported.

Hm, probably not directly relevant for Modern XMPP what your internal naming is like

Sure, we were just discussing the sync strategy and I said "what would I call that?"

Maybe in the doc it can just be "before or after"