jdev - 2026-02-14

singpolyma, regarding link previews https://xmpp.org/extensions/inbox/link-metadata.html#inject Does Cheogram already send multiple `<image>` tags in order to have inline image previews? ``` <og:image>https://link.to.example.com/image.png</og:image> <og:image>cid:sha-256+e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855@bob.xmpp.org</og:image> <og:image>ni:///shai-256;47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU</og:image> <og:image>data:image/jpeg,...</og:image> ```

btw what is ni:// ?

No. I'm not sending multiple like that yet. But I know you were interested in that so I included as an example

ni:// is https://www.rfc-editor.org/rfc/rfc6920.html basically a more generic version of the Cid uris that Bob uses ✏

What are all the mechanisms currently in use for handling chat history in a MUC (and in which precedence), from a client standpoint? Client-side cache (in the application itself), MUC history (per XEP-0045), and MAM, or?

> btw what is ni:// ? According to IANA from: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml https://datatracker.ietf.org/doc/html/rfc6920 ↺

Use MAM if available, otherwise there is an automatic recent history dump when joining (that the client opts limit when using MAM); in both cases you are limited to as much as the room will provide, which may or may not be everything, or even necessarily anything at all

So if you want to keep a long history, you'll want the client to maintain its own cache of received history

Understood, I just mean perhaps the more specific procedural steps, e.g.: * [Re]Join room, automatically receive a few of the recent messages (if the chatroom has it enabled); * If the last message you have in your local cache is in the provided backlog (or messages of the same time frame), then stop here, you're already have the whole history. * If not, keeping querying back in the MUC-provided backlog (up to a fair point; don't just automatically query the whole history, if the user hasn't scrolled up to even see past that point, otherwise it's wasteful), to match up to the last message in local cache * If MUC-provided backlog runs out, query MAM to fill the gap after

most clients seem to if they support mam ignore legacy history all together

The MUC-provided backlog is limited, usually to 50-100 messages; these days you would suppress that entirely and just use MAM, paging back as needed

when i get there with my client the plan is to request like enough messages to fill a screen with chats, and then defer fetching mam until everything has calmed down, preferring whatever chat the user opens or has mentions

oh gerp, I hadn't realized MUCs can also provide a MAM archive itself; I thought MAM was strictly user-managed or something (having just crossed https://xmpp.org/extensions/xep-0313.html#archives_muc ) ✏

in prosody they even recently changed it so you can load it globally as a module and it will implicitly create mam for all the (module supplied, not external) muc components ✏

> when i get there with my client the plan is to request like enough messages to fill a screen with chats, and then defer fetching mam until everything has calmed down, preferring whatever chat the user opens or has mentions This is an interesting idea. Trouble with syncing that direction is if anything goes wrong you get a hole... ↺

It's a good idea to represent holes in your history anyway, so you can potentially (re-)request them, rather than always trying to get full history just in case it's wanted

Sure but I'm not sure if anyone actually does that because it's rather annoying

Also in this case i meant allowing like say 10-20 messages from legacy history and then just wait for mam until after

I've come up with a few designs for it but never implemented one

I also think we discussed in the past the ability to sync mam without connecting to a chat, which could be interesting for fetching notifications

I suppose I could fetch the last page and mark it as not a sync point then sync forward from the actual point after. No holes then

Yes I always sync before fully joining

tbh just trying to think through muc notifications on mobile

since your server likely wont know so cant send you a push

I guess fetching the most recent page first it makes sense to do only if most recent messages are old also

Use mod_push2 and it'll give you pushes for MUC based in mentions

Tracks your nick etc and you can tell it if you want just mentions or everything

I mean this only matters on iOS but that's my current focus

IG you could just come online enough to fetch mam when you get a push

If push is enable I never go offline

im not sure what monal does but i remember it being obscene with making the device hot and like overnight my phone battery would be fully flat

Push = online imho

> If push is enable I never go offline ah ↺

> Push = online imho i meant as a device ↺

like the device connecting/disconnecting

also imo xa might be the most sensical for "able to be delivered to, but app not open"

Sure on iOS the device loses TCP but that doesn't affect onlineness

Yes I plan to use xa for this

> No. I'm not sending multiple like that yet. But I know you were interested in that so I included as an example singpolyma: thanks!