jdev - 2026-04-07

Cynthia, Anything you "discover" and wish you'd known in advance would be very welcome as PRs to XEP-0143, XEP-0001, and/or the website.

> Cynthia, Anything you "discover" and wish you'd known in advance would be very welcome as PRs to XEP-0143, XEP-0001, and/or the website. I mean to be honest, I only read XEP-0001 ✏ ↺

> i just waited a week or two for it to get merged (which seems to be on the same day as the council meeting where voting will start) and then once the voting starts you get to battle the standards@ readme 😈 LMAO README I MEANT MAILING LIST 😭😭😭 ↺

> I mean to be honest, I only read XEP-0001 Ah, interesting. And what steered you to XEP-0001? People, or the website, or...? ↺

> LMAO README I MEANT MAILING LIST 😭😭😭 I did wonder about that. ↺

Why do no clients support Message Markup

And why are there 2 XEPs that do the same thing (styling and markup) ✏

Message Styling always reminded me of diet Message Markup

my understanding is both were made at the same time to solve the same problem, and the idea was to figure out which one solves it better

Styling is basically universally supported and has a trivially good fallback

XEP-0393 is easier to support and XEP-0394 doesn't do anything XEP-0393 doesn't (yet), so i assume that's the main reason everyone goes for that one

I personally find Markup to be a bit of a bad spot in terms of design, but I know not everyone agrees so that can't be the only reason it's not implemented

maybe it's just that it doesn't do things people need, as you say, and Styling is sufficient

I admit Markup offers nothing above Styling

(yet)

It is more extensible than Styling is

for sure. Styling is intentionally LCD

i find it more elegant and more extensible so i'm hoping to submit some proposals to do more with it later on :)

> for sure. Styling is intentionally LCD > LCD? ↺

low cost design

or something

lowest common denominator, sorry

oh right

i guess the one thing XEP-0393 has over anything else is its so easy to support that there's little reason for XHTML-IM and XEP-0394 users not to support it, even if they won't support each other directly

indeed

I mean even if you don't support it the fallback is basically what some users wanted to see anyway

so you pretty much always "support" it

though almost no one supports it fully

Isn't it just a subset of Markdown?

no, its only markdown-like. for example *this* would've been italic if it were just a subset, while **this** would be bold

also the mechanism to escape styling for specific sections is entirely implementation-defined so it could be a backslash like in markdown, or a non-printable character as the XEP provides as an example: > This specification does not provide a mechanism for removing styling from individual spans or blocks within a styled message. Implementations are free to implement their own workarounds, for example by inserting Unicode non-printable characters to invalidate styling directives, but no specific technique is known to be widely supported.

(i didn't actually know this i thought it was all-or-nothing via <unstyled />)

it is all or nothing via unstyled, and also almost no one implements unstyled

it's possible to use a hack as stated in the XEP but I don't think anyone does and it's not suggested just noted

But clients end up implementing your XEP in an inconsistent way too

When you deprecate XHTML because of inconsistent implementation and behavior (and security issues) ✏

I think the reason was only security issues

I think the reason was only security issues

Given how many other issues come up when we talk about this, I don't think it was only security issues 🙂

> I think the reason was only security issues Security issues leading to inconsistent implementation ↺

Because clients try to implement the things in their own safe way

Like how font sizes won't work, and inline images with external URLs won't work ✏

And if you say "but client X supports font sizes", I think that just proves the point

XHTML-IM was too flexible

Security issues was the primary driver in getting rid of XHTML-IM, but there were other problems with it that we wanted to avoid in any replacement.

the "security issues" claim seems wild to me, but here we are 🤷‍♂️

Yes, I know, you do keep saying this, but a room full of people reached a different consensus.

on this topic, has there ever been thought given to fallbacks for https://xmpp.org/extensions/xep-0394.html ?

FWIW I don't recall the consensus around XHTML-IM deprecation being particularly strong, even if a Council did vote it through

There were plenty of people opposed to the deprecation

That's also fair.

What's the point of supporting XHTML if what you'll post will look different on all clients supporting it

Anything beyond a basic bold/italic/strikethrough is not guaranteed to appear the same

Why would I want to guarentee things look the same on different apps?

It will appear how the app wants it to appear, like anything else

I remember when Apple's iChat used to send XHTML-IM, and often set the colours to fun things, such as sending white text which other clients would try to render on a white background

And so much annoying "I'll make my text huge and pink" when we had XHTML-IM in chatrooms.

So an app will sanitize away colors and sizes

I think Prosody, M-Link, and others all implemented explicit filtering for XHTML-IM as a result.

hehe thanks for the idea hehe

While some apps will not

what would you exactly need xhtml-im for? is it just for fancy texts?

> what would you exactly need xhtml-im for? is it just for fancy texts? To be annoying ↺

It's a use case, I suppose.

yes it is just fancy text just like html in email

If XHTML was implemented the right way, I could put giant text

arent there any better formats for that?

It never is nowadays ✏

and can xhtmlim allow embedding custom stickers/emojis?

Yes

If your client does not sanitize inline images

stratself, Well, I don't think we ever got cid: mapping or equivalent.

> on this topic, has there ever been thought given to fallbacks for https://xmpp.org/extensions/xep-0394.html ? Since markup is applied on the <body>, How would you make fallbacks work? ↺

> If your client does not sanitize inline images i'm not sure how the custom stickers xep (or any future xep on this) will be implemented, but yeah that seem like a concern ↺

Stickers XEP does not use XHTML at all

> stratself, Well, I don't think we ever got cid: mapping or equivalent. that's what bob xep is? ↺

And the ProtoXEP snit and I worked on is based on Message Markup (XEP-0394)

for custom emojis

hi :3

XHTML-IM is used for custom emoji now, but yes message markup is getting the same ability soon

i do think xhtml would have ungraceful fallbacks to be fair. Not that I don't want fancy texts, but it is my concern

or correct me if i'm wrong

right now 0394 XEP seems to have no fallbacks at all, so people without support see just unstyled text?

this isn't a troll I'm actually not sure of the intent

hmm, good question

in the future i want to submit proposals for inline links, spoilers, and timestamps(the thing discord has). also maybe headings but idk if i really care about that much

> right now 0394 XEP seems to have no fallbacks at all, so people without support see just unstyled text? i'd just use XEP-0393 or things in the same vein as a fallback but idk if that's actually a good solution ↺

as in including the 0393 formatting characters in the body and formatting them too?

people didn't like that mentions allowed you to have @user in the body as a fallback in mentions so i don't see why *this* as a fallback for bold should be any more acceptable tbh

> as in including the 0393 formatting characters in the body and formatting them too? yes ↺

yeah that's not great

or i.e. in a proposal for inline links i might just send the markdown format

but idk what else you'd do tbh if you don't support the thing that styles the text idk why you'd expect the fallback to be styled anyways

> or i.e. in a proposal for inline links i might just send the markdown format i guess 0393 can just be extended for this? ↺

> in the future i want to submit proposals for inline links, spoilers, and timestamps(the thing discord has). also maybe headings but idk if i really care about that much how do you add timestamps in discord as a user? ↺

> singpolyma: Why would I want to guarentee things look the same on different apps? standardisation saves lives?

> in the future i want to submit proposals for inline links, spoilers, and timestamps(the thing discord has). also maybe headings but idk if i really care about that much Timestamps? ↺

You mean Discord's Snowflake time format?

technically I guess we could use XEP-0428 on every fallback formatting character

> how do you add timestamps in discord as a user? you can type @time and you'll get a ui flow for it ↺

https://files.isekai.rocks/file_share/019d6927-498c-7d27-ac4a-6c880f33a9d0/365e8144-e85e-4a9a-a8d5-118ae2aef700.png

>> how do you add timestamps in discord as a user? > you can type @time and you'll get a ui flow for it Oh this is very useful ↺

I never seen this before, then again I never used discord for a long time

i already have a draft markup spec for this capability but i don't want to submit too many proposals all at once considering how much work mentions has turned out to be 💀

how is that useful? are you supposed to auto-scroll up to the time being mentioned?

what? it's just a timestamp display

> I never seen this before, then again I never used discord for a long time its been around for a few years but never had a frontend interface, so you had to look up a tool that'd send the backend format 😭 only in the past few months have we gotten the frontend ↺

> how is that useful? are you supposed to auto-scroll up to the time being mentioned? i send a timestamp and i see it in my timezone and you see it in yours ↺

instead of me going "guys lets meet up at 5:00 AM UTC" and everyone having to manually convert

hmm, alright. it can make sense somewhat

> how is that useful? are you supposed to auto-scroll up to the time being mentioned? You know how `time` command works? ↺

alright, we can discuss that later

You type the time itself and it guesses what underlying timestamp to use

And timezone

inline links can just be [this](example.com) i think, and 0393 can be extended for that

if it even should be extended, tbh

393 is a hack

imo 393 is just a convention, so

it's not a hack it's just documenting what everyone does anyway

i wouldn't stop anyone from writing XEP-0393 equivalents to any XEP-0394 extension i submit, but it also seems... a bit pointless

I think 0393 is pretty fixed at this point

> inline links can just be [this](example.com) i think, and 0393 can be extended for that iirc, it is one of the accessibility fallbacks when you're printing a website too ↺

like, just spit the domain out in bracket format

> instead of me going "guys lets meet up at 5:00 AM UTC" and everyone having to manually convert How are you planning to implement this? ↺

Will you use a Unix timestamp + timezone?

Or ISO date format

there's a XEP for timestamp formats, so i just used that

Can you link

https://xmpp.org/extensions/xep-0082.html

I see!

> four digit year

RIP to XMPP users in 10000

basically everyone supports it and it has dates, times, and datetimes so its basically perfect here

> RIP to XMPP users in 10000 hopefully we've discovered something better than xmpp by then ↺

and years tbh

Y10K is a well-understood problem.

are the sizes of avatars essentially fittable in a BoB?

(unrelated to anything above)

not necessarily

they have to be, yes

oh really

since they fit in a PEP update

i see

that is to say, they're already inband, so it's not a change much

there's slightly less overhead with bob

> are the sizes of avatars essentially fittable in a BoB? They have to fit in a vCard anyway ↺

yeah

i know some people have whole gifs as avatars so i assumed they can be pretty massive

I modified Profanity to see how big I can make my avatar

turns out 196KB is pretty massive

I could only upload up to 512x512

what does jdev think of a way for an account to specify a specific "profile", per message?

oh i thought the recommended bob limit was like 8kib

Before it stopped because the stanza was too large for C2S and S2S

stratself, I think you might need to expand on your use-case.

> oh i thought the recommended bob limit was like 8kib sure. you asked if it would fit not if it was recommended ↺

> what does jdev think of a way for an account to specify a specific "profile", per message? what would this "profile" be used for? ↺

> what does jdev think of a way for an account to specify a specific "profile", per message? sounds prone to mistakes and leaks ↺

many clients support multi-account setups pretty well as it is

> what does jdev think of a way for an account to specify a specific "profile", per message? I think I've heard of that before ↺

indeed

Like different personas you could post as?

Could be useful for bridges

gateways can already create infinite Jabber IDs anyway

"create"

use, without creating

> gateways can already create infinite Jabber IDs anyway If you host a bridge bot in a server you don't own, this would be impossible ↺

well, not if the server allowed you to have a component. which you really want for this use case anyway.

> Like different personas you could post as? i was gonna write, but Cynthia sums this up perfectly ↺

Are these different bare jids?

they will come from the same JID, shows up as different "profiles" of that JID

The idea is you post as a persona in a message

But that persona is never shown in the participant list

considering the concept of semi-anon i'd be surprised if you can't already do this. although idk if it'd work well per-se

Or anywhere else, because the bot or user makes it up per message

Can you impersonate others?

> considering the concept of semi-anon i'd be surprised if you can't already do this. although idk if it'd work well per-se you absolutely can if you don't care about avatars ↺

> considering the concept of semi-anon i'd be surprised if you can't already do this. although idk if it'd work well per-se you can just change the nickname everytime, but avatars are a limitation ↺

> well, not if the server allowed you to have a component. which you really want for this use case anyway. You say this, and there are bridge bots that work the plain text way ↺

yeah avatars were why i added that last part to my message

Like userA: message

>> considering the concept of semi-anon i'd be surprised if you can't already do this. although idk if it'd work well per-se > > you can just change the nickname everytime, but avatars are a limitation No that doesn't work ↺

bridge bots on XMPP side are a hack, though. mostly due to lack of cheap/free hosting resources for components

If you change your nickname, the change applies retroactively (to all your previous messages)

> If you change your nickname, the change applies retroactively (to all your previous messages) um. no? ↺

it definitely does not

i can even post with multiple nicks at the same time

though with occupant id these days things can get weird

Given the nickname is part of the message's from address.

Really? Because in some clients it didnt work ✏

i guess whether the client lets you do it is separate from whether the protocol does

the inspiration actually comes from Matrix's MSC4144 - Per Message Profile https://github.com/beeper/matrix-spec-proposals/blob/per-message-profile/proposals/4144-per-message-profile.md

snit, Well, if we're only talking MUC, then the server ha to let you as well. Joining with multiple nicknames from two different clients is possible, but the server might just force them to be the same nickname.

Per message profile would be useful

oh true

(i'll come back with an example client rendering of such)

> bridge bots on XMPP side are a hack, though. mostly due to lack of cheap/free hosting resources for components That's exactly my point ↺

Nobody wants to host a XMPP server to have a good bridge

https://xmpp.muoi.me:443/upload/4c2d341d9f0ed7d19fdfaa765d01191720dafd2c/q7vMHoRBquAiQ7IkBfT1Qy1TddXdfNckxTVVGlSsk0/a3ef0254-dce4-4954-9efb-e2d2a7f5d998.png

for example, 'tulir' is the github user, and their messages are bridged via the 'GitHub' bot

also pretty useful for roleplaying and other stuff where you need multiple identities per account. See https://pluralkit.me/ for an approach of this on discord

> Can you impersonate others? i don't believe this allows for any in-xmpp impersonation ↺

Impersonation would be hard when the person who's doing it is literally next to the name

Or if you click on the name

> Like > userA: message this should be the fallback message too yeah ↺

the thing about semi-anon is we can already impersonate users very easily

If you're in control of the MUC server

you don't even need that much

How much

if they're not even in the muc you don't even have to do anything special and if they are you can just

use their nick + a space

like this lole

What about the avatar

you... change your avatar

I change my avatar for literally everyone?

whoever you want to impersonate, yeah

So I can't send 2 different messages by 2 different users at the same time

if you try really hard you could

if i were to develop a client for power users, i'd definitely represent the occupant id in the forefront in some manner. Ideally via an identicon of their id https://en.wikipedia.org/wiki/Identicon

or if you just use multiple accounts

> if you try really hard you could No, it's error prone ↺

anyways, i hope this chat consider the idea of Per Message Profile. Imo it's a pretty neat approach ✏

pro tip: we don't have to consider it if you write the spec and nothing is particularly off

Depending on how many rooms are using your bot, your server will get overwhelmed

And start changing avatars to random people

Unrelated to the message

How many servers are particularly battle-tested against constant vCard changes?

good point

gotta learn how vcards work first

but they're prolly sent via pubsub right? not inband like PMPs

Cynthia : Also this will leak the avatar of whoever sent a message anywhere

Because the vCard changes for everyone to see

And using multiple accounts is already off the table

So I wanna use a special persona I have in private, everyone in China will know because my avatar changed for a bit

mind you the bit i said about impersonating users was refering to like

actually impersonating people, maliciously

not the use-cases pmp would cover

i was just saying pmp doesn't technically have to worry too much about preventing it because its super easy as-is 🧌

(although it'd be nice if it did worry about it, ofc)

If I wanted to invite a Git watch bot (someone else hosted) into my MUC, and have it output notifications as if the Git user behind it was talking... How would that be possible?

Discord uses Webhooks for this, Matrix uses Per Message Profile, XMPP uses... some server hack

there are several ways to do that, including webhooks, but the "best" way would be a component IMO. that's not a hack it's a protocol feature specifically designed for this use case

It's a hack and clunky

You join as JID whatever, post the notification, and leave

You repeat for each notification

I wrote this ~5 years ago: https://gist.github.com/mar-v-in/d1946974657369f82c6b871c5064f2bb Basically a spec to allow clients to render matterbridge properly

And you can't mute the bot at all when it does this

Because in your PoV, it's different users

> It's a hack and clunky it is neither of those ↺

> Because in your PoV, it's different users ... so you want it to be different users but also not? that's rather different ↺

if you want to be able to mute the whole "bot" at once then multi profile won't work either

Maybe "Mute profile" and "Mute origin user"

right but multi profile wouldn't allow you to know they share an origin user, for privacy reasons, usually

so it's a different use case

> right but multi profile wouldn't allow you to know they share an origin user, for privacy reasons, usually Origin user as in the bridge bot ↺

Like if I had a Git watch bot that sent a notification about a commit John Doe made

> it's not a hack it's just documenting what everyone does anyway That's not true, most people I know started to write 0393 compatible because of clients rendering it 0393 compatible, which they did because 0393 said how they should do it. ↺

The buttons would be like: "Mute profile" mute all notifications from John Doe "Mute origin user" mute all notifications from the Git bot

Which would be easy if the profiles (John Doe, e.g.) were puppets that the Git bot user used ✏

> I wrote this ~5 years ago: https://gist.github.com/mar-v-in/d1946974657369f82c6b871c5064f2bb > Basically a spec to allow clients to render matterbridge properly This spec looks good, but you should make it more generic so it's not just used by bridges ↺

Like the PluralKit for example

people didn't really like it back then, because one could just do proper gateway I guess.

> I wrote this ~5 years ago: https://gist.github.com/mar-v-in/d1946974657369f82c6b871c5064f2bb > Basically a spec to allow clients to render matterbridge properly thanks a lot ! ↺

> people didn't really like it back then, because one could just do proper gateway I guess. may i ask of the reasons why? ↺

I guess the reason is that people prefer this to be done entirely on the server, so no extra work is needed on the client. The specification adds extra work for every receiving client, instead of just the sending entity and the server (which may be the same in some bridge/gateway setups)

> I guess the reason is that people prefer this to be done entirely on the server, so no extra work is needed on the client. The specification adds extra work for every receiving client, instead of just the sending entity and the server (which may be the same in some bridge/gateway setups) It's dumb to expect people to self host so they can have a good bridge UI ↺

Yes, you can do a lot of things when you self-host, but the Average Joe isn't gonna do it

indeed. Luckily we don't need to self host to have a component 🙂

(I mean, you have to host the component, but that's the same as hosting a bot)

Not applicable to all use cases

Say if I wanted to have something like PluralKit in XMPP

Do I have to let people register "plural" accounts at my component and join MUCs (which then blurs things for moderators, and makes it even easier to do abuse?) ✏

Not to mention this would look terrible in 1:1

for the plural-human use case https://xmpp.org/extensions/xep-0383.html is the thing

components are more for plural-bot

> for the plural-human use case https://xmpp.org/extensions/xep-0383.html is the thing Still not good in 1:1 ↺

How so? It's designed for 1:1

This assumes that you can talk at any time, a plural entity's headmate

Because all of their mates (or whatever) would have separate JIDs

a specific headmate*

And really, people aren't gonna jump around JIDs to figure who's fronting

? You're not supposed to be able to figure it out. That would violate the sender's privacy

That's why this is an abuse of Burner JIDs

And doesn't fit the usecases

... I don't think I'm going to be able to figure out what you're talking about

I'll try to be clear

Whenever you talk to a plural human, they usually like to talk as whoever is fronting

So like, this seems like a usecase different from Burner JIDs or components

Whenever I talk to a plural entity, I have to guess who's talking by their typing style alone, and even then I'm confused so I have to ask them

I hope you understand me :(

But either they want you to know who is fronting (and thus select this when sending) or they don't, right? And if they do select then either of multi account or burner jid gives that UX and if they don't I'm not sure we can do anything about that?

Yes

do you mean that you want to _send_ to one entity and receive from multiple?

It would be nice if they could let you know who's fronting right away

Cynthia, I think there's different use cases there. In some cases, they might want different accounts (and separate history), and in other cases something like a simple <nick/> element embedded in the message would be most appropriate.

(or <presence/> even, maybe)

> do you mean that you want to _send_ to one entity and receive from multiple? Oh this is an interesting edge indeed ↺

You have to knock on the main account and wait for them to send you a message from one of their mates

Or vice versa, they have to wait for messages from their main account and send messages from one of their mates

that might be best served by just using a MUC

Wouldn't it pollute the history with you trying to figure out who's fronting?

> that might be best served by just using a MUC That may be overkill ↺

To the plural entity, you'd have to have a separate MUC for each of your contacts ✏

in my experience, the plural entities that i am aware of are okay with the multiple profiles per-id approach

and since it'd likely help with bridging too, i believe PMP to be a workable solution for many use cases

i dont think there's any overlap with bridging. But the one in multi out case is an interesting one which obviously needs its own unique facilities

i don't get what you're meaning with the "send one, receive multiple"... isn't sending to the same JID essentially that? ✏

i don't get what you're meaning with the "send one, receive multiple" thing... isn't sending to the same JID essentially that? ✏

A shared inbox?

A mailing list?

I mean this case where all contact want to message a "root" persona but get replies from one or more others

> and since it'd likely help with bridging too, i believe PMP to be a workable solution for many use cases Yes, and it's likely easy to implement ↺

the normal facilities don't work here because of the asymmetry

I mean I don't wanna make guesses on how the UI stuff are implemented

whereas for bridging you always have symmetry so it's a very different case

so you can basically just message/tag the JID

> I mean this case where all contact want to message a "root" persona but get replies from one or more others yeah, interesting. Though it's usually the case that the "root" persona is the main account and its "default" profile ✏ ↺

i did ask tulir how per-profile mentions may be implemented.. it'd probably be the JID, plus the ID of that specific profile

Mentions are parsed from the message anyway

Unless we're talking about Explicit Mentions?

yes, explicits though it would be nice (as a client exercise) to tie implicit mentions against the current fronting persona