jdev - 2026-03-10

I need a little on how this msg works

I want to know the benefits of Octo browser

So I found out some irc bridges dont attach message ids at all apparently. what do clients do about such messages to prevent duplicates?

I guess just content+timestamp based deduplication?

How can there be duplicates if mam is not supported?

> How can there be duplicates if mam is not supported? perhaps they mean the echo-back? in which case you just keep track of your sending jids and dont bridge back any of the messages from that ↺

or you know just throw any cryptographically random id in the id atribute and ignore it if it has that

best case scenareo you do both

Mam requires stanza IDs on all messages

If there is no archive I don't see how you can receive duplicates

> Mam requires stanza IDs on all messages sure, i think im confused perhaps im confused ↺

well if im writing my messages like that i definitely am

maybe time to go to bed lmfao

anyways, im confused what they mean by duplicates

do they mean recieving another users message multiple times? or recieving their own messages back (their as in the bridge puppets)

for the former, at least with koishi, my technique so far is that mucs without stanza-id are simply incompatible with bridging, since both ejabberd and prosody include mam with the recommended module set

(i also cheat a little, and just have a sql constraint and then let psycopg throw an error when it tries to add it again) ✏

i mean when you join such an muc it sends you a few of the last messages

You should disable the history request

Only use mam

^ depending on the library youre using this is pretty easy

slixmpp (what im using) disables it by default, and for now im just letting that be

how do you disable the history request? it seems to just be sent automatically when I join if im not mistaken

See the MUC spec

> how do you disable the history request? it seems to just be sent automatically when I join if im not mistaken what library are you using, or are you writing the xml manually? ↺

manually ofc

> See the MUC spec then this should set you right ↺

you can also set a default within the muc, at least on prosody

https://downloadable.pain.agency/file_share/019cd745-97e5-7411-8497-a7d08fb4586d/8a41e118-97a4-4a9b-85d1-b50c76b7277b.png

it could be labeled better, but this is traditional history, what is served to you on join

you dont have to worry about mam, as thats something the client has to expliclitly fetch

generally if you dont set a value in the join, it follows that

but what does e.g. gajim do? is there explicitly this logic written down: "if this room doesn't add stanza-ids, set the maximum number of messages returned by room to 0"?

i think prosody also lets you configure a maximum and default config in the congif file

> but what does e.g. gajim do? is there explicitly this logic written down: "if this room doesn't add stanza-ids, set the maximum number of messages returned by room to 0"? lovetox can answer better, but to my knowledge it always requests 0 history, then fetches history from mam ↺

I think I should just stick with timestamp+content dedup as fallback and still request back messages, less messages would be missed that way

You will have a very inconsistent UX then

> I think I should just stick with timestamp+content dedup as fallback and still request back messages, less messages would be missed that way at that rate just hash the entire stanza ↺

You cannot influence how much data you get from muc history ✏

> You will have a very inconsistent UX then also this, to my knowledge legacy history these days is legacy only, and enabling/disabling mam is semantically enabling or disabling offline history alltogether ↺

> You cannot influence how much data you get from muc history isnt it literally a number of messages youre requesting? ↺

But MUC config can be set to X

ah yeah, its a whatever is lowest

Also you can not page or abort the request

It's a very very bad API form a long time ago

it also can cause issues with bots, as usually bots are meant to be simpler and not keep track of messages

I would not know why anyone writing a new client would use this

i thought of a very particular ux case, but even in that you could just issue a small mam request while the join request is still in flight

(my case is about being very clever with how much history is fetched on connect and deferring more history until things settle down)

I would like to clarify once again about message ids in general: 1. For incoming I should store only the stanza-id assigned by the mam server 2. Only for my own messages I should get a separate db column and store an attribute id (<message id="...">) and then deduplicate based on that, particularly my message that muc sends back That's basically it? Any pitfalls I should keep in mind?

make sure the muc advertises support for stanza-id before you trust it, also i personally would show to the user the version that gets echoed back, which will reflect changes such as that by mod_pastebin

otherwise that sounds right to my very tired head

lol: no you need to store stanza id and message id for all messages

ok turns out yet something else exists <archived by='...' id='1773138931690509' xmlns='urn:xmpp:mam:tmp'/> tf even is this

> lol: no you need to store stanza id and message id for all messages why? ↺

lol, mam:tmp is an extremely old thing. Is there no stanza-id in that?

You should just ignore mam:tmp, and if there is no stanza-id alongside it, tell the server operator it's beyond time to update their software

lol: because some processes reference message IDs and some stanza ids

For example corrections use message IDs

I don't think I see ID attributes in archive results.

You will, on the inner message

snit, Cynthia, theTedd, I once wrote a module to cache BoB on MUCs: https://modules.prosody.im/mod_bob

That was usable for the past seven years, in case you want to share custom emoji in MUCs in an efficient way.

oh nice :D

Cynthia, in poezio I implemented XHTML-IM in less than 600 lines of Python, a third of which being the definition of colours. I’m sure you’ll manage to support enough of it in your client or library, even with no prior XHTML or CSS support: https://codeberg.org/poezio/poezio/src/branch/main/poezio/xhtml.py

Link Mauve: a parser is half of the work. The other is translating this to whatever your GUI framework needs

lovetox, in poezio we use ANSI escape codes, in GTK we use Pango markup, in other toolkits I hope this isn’t much more difficult.

As you can see I called that a parser but we do generate the escape codes we need.

I dont plan to use it for my client anymore for other reasons, but iirc fyne prefers markdown

jjj333_p (any pronouns), XHTML-IM is the only wire protocol that is compatible with Markdown: you let the user type Markdown, and then convert that to XHTML-IM when sending the message.

it may be worth looking into what the nheko matrix client does, it seems to be able to render a very wide spectrum of html formatting within qt, ik the dev talks about including whatever webkit bindinggs

You can use any input method you want, Markdown, but also buttons, or even bbcode or XEP-0393, and then convert to XHTML-IM on the wire.

> jjj333_p (any pronouns), XHTML-IM is the only wire protocol that is compatible with Markdown: you let the user type Markdown, and then convert that to XHTML-IM when sending the message. ig the hard part is converting back, but perhaps xhtml-im is 1:1 ↺

that was more what i was referring to

Converting back, for message edition you mean?

like the gui element takes in markdown

oh you can use segments too https://docs.fyne.io/api/v2/widget/richtext/

this is kinda irrelevant, i decided not to go with fyne because it has bugs and is kinda turning into a slopcoded toolkit owned by a slopcoding company

it somehow is broken on both x11 and wayland

I only brought it up as an example

How do clients behave when they haven't been online in a long time? Let's say I've been away for a year, so the last locally stored message is a year old - obviously there's a ton of new messages to fetch, and I suspect a client would put a limit on that, right? What if it reaches the limit before reaching the latest message already in cache?

Are the old messages erased? If not, what's gonna happen is the user scrolls up and sees what - ol messages before the "break" happened, mssing a chunk of history?

It Depends™

different clients do different things. Dino only ever gets 3 days and there's no way to fill the hole. Some clients will try to fetch the whole year

Different clients implement different strategies. For example, putting a limit on how far back they will automatically sync.

most servers won't actually store the whole year

Whether old messages are erased in your archive depends on the retention policies of your server. If it's a public server, this is usually documented in their privacy policy

If it's your own server, you have full control over that

Also note that group chats are separate to direct messages, and may have different retention policies to your own account

For example, the Prosody support channel has a retention period of 2 weeks, and if you're offline for a year you'll only be able to fetch the last 2 weeks when you return

^ group chats the retention policy is set on the server hosting the group, not yours if those are different

and servers can set separate policies for groups vs. users' direct messages

and the way to inquire how far back a server stores is <metadata> and the servers I tried so far don't support it. splendid. Keep the users guessing.

Note that doesn't necessarily tell you how far it will store, it just tells you about the first entry.

what's a good XEP to reference for seeing how room configuration extension should work?

0045 ?

btw singpolyma, what xep is cheogram using for stickers again? or is it just sims

im not yet ready to deal with custom emojis but i did realize stickers would be pretty trivial to bridge between matrix and xmpp

sims/oob yeah. they're just image attachments after all

fair, just didnt know if you did any indication of them being a sticker or if there was anything on top of that

thanks

No. I don't think "a sticker" exists it's just a concept in people's minds so there's no benefit to indicating in the protocol that it is or isn't one

but i guess that means im probably already bridging xmpp stickers to matrix just as media (greedily look for oob media)

> there's no benefit to indicating in the protocol that it is or isn't one the only one ive seen is controlling autoload, and displaying the name differently which is dubious at best

either autoload is safe or it isn't. being a sticker doesn't change that

> 0045 ? yeah i was looking at that but for some reason i'm having trouble wrapping my head around the form-related stuff, hence why i was looking for how other xeps extend 0045's forms. do i just like, take the `muc#roomconfig` form and stick my new fields at the bottom? ↺

> btw singpolyma, what xep is cheogram using for stickers again? or is it just sims are these stickers different from the existing sticker xep? 0449 ↺

0449 doesn't specify anything for stickers

it's a sticker store/pack distribution xep

with no implementations

>> 0045 ? > yeah i was looking at that but for some reason i'm having trouble wrapping my head around the form-related stuff, hence why i was looking for how other xeps extend 0045's forms. do i just like, take the `muc#roomconfig` form and stick my new fields at the bottom? yes. just specify the new fields and the implementation can add them wherever in the form ↺

> either autoload is safe or it isn't. being a sticker doesn't change that yeah im just remarking what ive seen other protocols do ↺

> yes. just specify the new fields and the implementation can add them wherever in the form okay epic thank you :D ↺

anyways thanks

>> either autoload is safe or it isn't. being a sticker doesn't change that > yeah im just remarking what ive seen other protocols do I mean I guess if the room/server/space/something-trusted has a list of trusted images, it'd be safe to autoload these and not random others, right? ↺

sure, though i suppose thats irrelevant to if its a sticker

isn't that what they call a "sticker pack" though? I don't actually care about the name

it is, im talking specifically about whether or not you indicate in the message stanza whether the image is a sticker

ig im currently talking in the hyper-specific application of a bridge where media autoload is irrelevant

i also implement xmpp -> matrix media with just a trivial db lookup and redirect

up to everyone else to serve and cache the media

Well I sort of have that also. That's why I started using sims, to get hashes of files. So if you've downloaded it ever (including but not limited to due to a sticker pack install) I can show it without downloading anything

> Well I sort of have that also. That's why I started using sims, to get hashes of files. So if you've downloaded it ever (including but not limited to due to a sticker pack install) I can show it without downloading anything yes perfect, now write that down someplace other devs can find :) ↺