jdev - 2026-03-04

Trying to figure out what message duplication code should look like in practice. Should I only look at what the server assigns? Is there any reason to look at origin ID? ✏

Trying to figure out what message duplication code should look like in practice. Should I only look at what stanza id the server assigns? Is there any reason to look at origin ID? ✏

> you'd have to define what "HTML" is as well, as theres the Living Standard HTML of today, HTML4.01, HTML5, the earlier versions of HTML, etc... These are all so similar as to be essentially the same thing ↺

> Trying to figure out what message duplication code should look like in practice. Should I only look at what stanza id the server assigns? Is there any reason to look at origin ID? No. Origin ID is a historical artifact ↺

lol: you need to deduplicate also message you sent, for which you have no stanza id

> lol: you need to deduplicate also message you sent, for which you have no stanza id Omg, how?.. ↺

Not by assigning the attr id=... ?

Indeed. You can trust the attr id in your own sent

Okay so messages end up having like what three IDs?

Origin id - ignore completely Server assigned id - dedup Attr id - also dedup?

I mean two. Origin ID doesn't need to be there

and when it is there approximately all implementations set it equal to attr id

Attr id you can only be sure is unique on your own sent messages. Though it's used in a few other contexts but not for dedup

(you can be sure on yours because you set them and you chose unique ids riiiiiight?)

Ok so my client shouldn't look at attr id other than for my own messages. Interesting.

Everything else you'll have a server ID. Except for when you don't but I've mostly chosen to see no evil on those cases

nothing to dedup in those cases at least

(it's mostly when something doesn't go into mam at all)

you'd have to ignore a bunch of new elements added since HTML5 to say they're the same, they imply that your program will support A/V functionality and other stuff. does the XMPP client just make them a no-op and ignore them in that case?

right. unsupported HTML elements are basically equivalent to <span> in HTML semantics generally

ie you can just ignore them

then you mean a subset of HTML as this is what HTML is now

https://html.spec.whatwg.org for reference, this is HTML today.

I'm very very familiar with HTML and what it is today yes :)

a user agent is free to not support a tag and is also free to render tag in any way it wants. that's sort of the whole point. just like with xmpp

I don't know why we're discussing this as if it is hypothetical. Many messaging and other systems are using html like this already it's hardly a unique idea

browsers that omit too many end up garbling some web pages to being almost unreadable in practice

sure. luckily we're not needing to render web pages

i've only really used communications programs supporting HTML that were proprietary and required a web engine to function. never seen any with different interpretations of HTML in messages in practice

the rendering of messages between clients might look strange in some corner cases. i suppose inputting raw HTML isn't too quick either so there might be a markup language that translates to it when someone wants bold text or something like that real quick

no sane messenger is going to have users manually type html

anyone remember bbcode on forums? we should bring that back 🤣

people used to write HTML web pages by hand...

anything is possible

sure but writing it in an instant messenger still seems crazy, do what you want though

i could see a messenger _allowing_ direct html input, but i'd sure hope they'd have something more user friendly like markdown for most use-cases....

yup

Or like having a button that makes things bold, heh