jdev - 2026-02-22

Do MUC components usually double as pubsub services or would I need to run mod_pubsub on a subdomain of the MUC domain if I wanted to associated pubsub data with a MUC?

I've never seen them done together but it might mostly work depending

It works for PEP, why not MUC?

(in theory, anyway)

> yeah I see this too. from jabber.el, > ``` > (:muc-foreign > (message > ((xml:lang . "en") (to . "wgreenhouse@hmm.st/Emacs") (from . "jdev@muc.xmpp.org/singpolyma") > (type . "groupchat") (id . "1EF11773-2F35-4F95-8F81-812B75BA0A91")) > (fallback ((xmlns . "urn:xmpp:fallback:0") (for . "urn:xmpp:reply:0")) > (body ((start . "0") (end . "97")))) > (reply > ((xmlns . "urn:xmpp:reply:0") (to . "jdev@muc.xmpp.org/Cynthia") > (id . "2026-02-21-2316b69a202e1896"))) > (html ((xmlns . "http://jabber.org/protocol/xhtml-im")) > (body ((xmlns . "http://www.w3.org/1999/xhtml")) > (p nil "Do you have an example of such an \"unofficial xep\"?"))) > (occupant-id > ((xmlns . "urn:xmpp:occupant-id:0") (id . "n6yAmftuthaHwtUpgo0dr+mFnc+asBQ1cHNAb+fqdMo="))) > (stanza-id > ((xmlns . "urn:xmpp:sid:0") (id . "2026-02-21-06751bdea7d529e3") (by . "jdev@muc.xmpp.org"))) > (body nil > "> one of the reasons people make them are that they don't have to put their real identity on it\n\nDo you have an example of such an \"unofficial xep\"?\n")) > :time (27033 44356 737756 983000)) > ``` Wow so readable ↺

thats just a lisp language

More like e lisp language

somewhat crosspost from gajim muc, but this displayed indicator looks correct to send to a muc when a message is displayed right? ```xml <message to="chaos@group.pain.agency/m0rph" from="jjj333_p_1325_4d2.org@koishi.pain.agency" id="9ceace15d9f34df786b8556a302141ce"> <displayed xmlns="urn:xmpp:chat-markers:0" id="019c8495-b0de-7ff1-9a49-05b5a58493cb" /> </message> ```

also as far as i can tell you have to send it as a dm which then ig gets restricted by the muc

turns out its not for multiple reasons

singpolyma, do you parse the og:url attribute?

i wonder why i should and for what i should use that

hello, we're currently implementing XEP-0461 message replies for matterbridge, but i don't see in the spec that the quote marker (`> quote`) is specified. is it safe to assume that all clients use `> ` as a quote marker for the fallback text?

(yes i know about the start/end offsets, i'm just wondering about the general case where stripping the ` >` may be the more appropriate UI decision)

apart from the obvious fact that we can never know if all clients do that and will in the future

Clients supporting XEP-0393 render the fallback using the `>` character, see https://xmpp.org/extensions/xep-0393.html#quote

there is https://xmpp.org/extensions/xep-0393.html

ha thanks!

> singpolyma, do you parse the og:url attribute? Yes. I treat RDF:about as the original link in text and og:url as a "canonical" or "resolved" link ↺

> hello, we're currently implementing XEP-0461 message replies for matterbridge, but i don't see in the spec that the quote marker (`> quote`) is specified. is it safe to assume that all clients use `> ` as a quote marker for the fallback text? No. You cannot be sure the fallback text is a quote at all. And there may be quotes which as not part of the fallback ↺

woops, i understand the second assertion, but not the first… what would a fallback text that's not a quote be?

Anything the app wants it to be. Could be [a reply to some Nick] as an example but there are no limits

ok is that actually implemented by clients in the wild or is that speculation due to the spec not mandating a quotation format?

I don't think anyone can truly answer that because auditing every single client would be quite a job. The bigger question is what is your use case to ignore the spec in this case?

so on the matterbridge level we're gonna keep a cache of messages to properly format the reply so that's not really a problem, my question was more on the go-xmpp level where letting remote entities define what quote format/presentation will be used feels wrong (for clients who don't implement message replies) to produce consistent UI, so someone suggested just removing `> ` from the fallback text and exposing it as a different string could be an idea so the client can figure out the appropriate way to display it or relay it to other networks

If you support replies you can just delete that text entirely. If you're writing code to do anything at all to the fallback text you're better off not doing that and implementing the thing it is a fallback for instead

so that means it's a reasonable assumption that all clients need to keep a message cache/archive in order to properly support replies formatting and the fallback text can just be whatever so it should just be ignored by clients? or is there value i don't see in the fallback being whatever the remote client decides and we should in fact not ignore it systematically?

Yes you should ignore the fallback text. It exists only for clients that don't support this feature

sorry i was not clear: my question is precisely what to do in the library code for clients who don't implement the feature (no problem implementing it in our client, my question is how should upstream handle things)

Oh. If they don't implement the feature you can do nothing at all 🙂 the text is in body and they will show it

ok i guess that's an acceptable compromise ^^

singpolyma, im aware that og:url is the canonical url, but what are you doing with that information in the GUI?

ah you display it under the title

Yeah

lol, luca: specifically it was sxml (xml rendered as lisp s-expressions) which is what `xml-parse-region` et al. in emacs deal with

singpolyma, and on click you open the canoncial url or the url the user sent?

I open canonical at the moment

ok, but could this not be problematic? i dont know much about web, but could a link pass some parameters that would be not in the canonical url?

or asked the other way around, what is a reason to not open exactly the link the user sent?

Well I keep the link the user sent in body. but yes there are trade offs here I don't claim to be sure I have it perfect

My thought was to show the real url and then it felt weird to open something different than shown

ok thanks

i was reading about hats (XEP-0317) and references (XEP-0372) a bit ago. i noticed that the hat's URI would fit in perfectly as a URI in a reference, and i thought it'd be cool to leverage that to mention all users with a given hat at once. however, it seems like 372 only expects references of the `mention` type to be a bare user JID, which would exclude hat URIs. has there been any discussion about broadening which kinds of URIs are "mention"-able? would be nice to have the ability to mention all users at once who have a hat indicating they want to play a certain game, for example

Yo. Aspiring XMPP developer. Client-server backend, frontend. Trying to decouple UX and client logic. Also trying to create migration paths from other services and some interoperability for existing attempts to drag people out of Discord, etc.

Makin' an XMPP octopus, in short. Unix socket multiplexer and individual XMPP XEP programs all sitting on that socket bus.

Currently occupied, but planning to work on it more in the new week.

Got invited here from another MUC, so hello!

Hope to share some useful programs and code with you all.

Tasteful MUC logo, btw.

> lol, luca: specifically it was sxml (xml rendered as lisp s-expressions) which is what `xml-parse-region` et al. in emacs deal with Haha sex ↺

snit: Hello, mentions in MUC can't use a bare JID anyways (that would only allow to mention the entire chat in "anonymous" rooms). A few years ago we started to split/rewrite the XEP but I think that work was never finished?

> Yo. Aspiring XMPP developer. Client-server backend, frontend. Trying to decouple UX and client logic. Also trying to create migration paths from other services and some interoperability for existing attempts to drag people out of Discord, etc. Welcome! ↺

Thank you. Glad to be hackin'.

singpolyma, i thin 256x256 is too big

a stanza with a single picture as data uri, can reach 100kb

with 128x128 im at 50kb with 3 pictures

we go with that for now

Ok

> snit: Hello, mentions in MUC can't use a bare JID anyways (that would only allow to mention the entire chat in "anonymous" rooms). A few years ago we started to split/rewrite the XEP but I think that work was never finished? i did notice the discrepancy with mucs; i figured that was a consequence of the XEP seeming relatively incomplete. i assumed the intention was to allow whatever means of mentioning any individual user, but it seemed like it actively excludes other types of mentions such as hats. is there a link to the newer work(s) you mentioned? or are they just kind of vague ideas ↺

singpolyma, i tested with JPEG as format and it seems factor 10 smaller than my png output

are there any arguments against sending jpeg?

Yeah if you are doing a small thing JPG might be a good choice. Or webp

Converting png with transparency to jpg might have some issues though

But I guess we could check beforehand and convert depending on that

snit: See https://github.com/xsf/xeps/pull/1281 and https://bouah.net/specs/mentions.html for the drafts on trying to make better mentions

oh that's huge, a quick skim of the latter suggests it handles hats exactly as i expected, as well as a few other things i was thinking about :O

sunglocto: here's the github thing you were asking about earlier ^^^

> Yeah if you are doing a small thing JPG might be a good choice. Or webp > webp might be a more fair conversion since it has the ability to be lossless, while still afaik smaller than png ↺

> Converting png with transparency to jpg might have some issues though it also has transparency support i think ↺

I'm not sure how well webp is supported nowadays. Does it work on iOS/Android/macOS/Linux/Windows?

for browsers looks like yes https://caniuse.com/webp

> it also has transparency support i think JPEGs don't have an alpha channel ↺

it's pretty limited in that aspect

it's just 24-bit RGB or YCbCr

> I'm not sure how well webp is supported nowadays. Does it work on iOS/Android/macOS/Linux/Windows? as an ios user, yes webp works fine its just webm that is shaky ↺

i also assume android is fine since google has finally started using it for all their services

> JPEGs don't have an alpha channel ye thats why i said webp ↺

oh i thought you were referring to JPEG

mb

this has nothing to do with the operating system, its just encoding, you can write a library on any OS to do that

> this has nothing to do with the operating system, its just encoding, you can write a library on any OS to do that true, however most apps dont, which has been a pain point. whereas if the os can play it natively it usually works ↺

like for example i can play a webm in safari but not inside telegram despite them embedding a webview

all browsers in iOS use safari

apple forces them to do that

yes

if it's something safari doesn't support, none of the apps are able to do something about it

when i said safari i meant opening a url in the embeded webviewer in telegram

> if it's something safari doesn't support, none of the apps are able to do something about it but they can support the encoding outside of a webview, look at vlc on ios ↺

> I'm not sure how well webp is supported nowadays. Does it work on iOS/Android/macOS/Linux/Windows? Yes ↺