jdev - 2026-08-31

Maybe yeah, but I'm more referring to LINE

LINE makes you grab a small snippet from their garbo streaming service, MySpace lets you do really anything

Can we start to not use base64 and very low stanza limits at the same time?

what's the alternative ?

I don't really know, but keeping this isn't good either. I don't like it when setting avatar of MUCs disconnects me... but user avatar doesn't? Wait, is this a server bug?

Your client should scale down the avatar, or your server should set a reasonable stanza limit

Oh, client scaling down the avatar. Makes sense, former was on Psi while latter was on monocles/conversations.

even then, animated avatars easily hit stanza limits. hopefully someday we'll have http-based avatars like any other media does nowadays

Mhm, that would work too. Even better potentially?

Hmmm If HTTP is good because multiple streams, why don't we have multiple XMPP streams?

you can, both with TLS and QUIC (where it's free)

What would this change the same stanza limit applies

Oh, right. Forgot about that...

Multiple streams are sexy

But how does it work in practice

Just assume you get stanzas from any connection? Or is it one connection for specific sets of stanzas?

The later

E.g. a stream per MUC

That would be nice

But server would need to support right?

No .. you can open as many streams to a server as you want

That's what we call multi device capability

But it can be made more elegant

Oh

So this is a thing that exists

Yeah, but isn't this for having multiple devices, not having a single device that has multiple connections? You'd still receive all incoming events on all connections

Depends on what you do, if you send no presence on a connection to the server it will not Route messages to you

Oh, that's good

Though to join a MUC you need to send directed presence l, not sure how a server interprets that

> Hmmm > If HTTP is good because multiple streams, why don't we have multiple XMPP streams? And yet every webdev's job for years was to reduce number of streams with crazy hacks like CSS sprites ↺

https://sekurak.pl/grozny-atak-na-szyfrowany-komunikator-gajim-przez-luke-w-kde-plasma/

You need to translate , but describes how via avatar and url handlers rce can happen with an example for Gajim

> below the output content of the link: > > [Znak RTLO] telnet:.cache/gajim/avatars/HASH_SHA1%00/moc.x//:sptth > > Ready to ship, the darkened link may look like this: > https://x.com/00%317076d6aadee1744dbdcdcfaf0a7295f6cc479/s27%at16%va/miA6%ag/eh36%aceE2%:tenlet > > Thanks to the RTLO sign, the victim in the Gajima chat window will see a seemingly safe link, looking like a standard address starting with https://. that's awesome and terrifying, how do you defend against this ?

You sanitize the url

We do this already for filenames when we store files

Because you can also hide obfuscate the file extensions with this

sanitize how ?

Remove the char from the url

which char? isn't the RTL the problem ?

That's a char

but sometimes for some languages a valid one no ? I didn't think you could just always remove it ?

also, it's not even part of the URL, right?

I didn't look into it in detail, is it at the end? I thought it's in the middle

I see no use case for having it in the middle ✏

u202etelnet:.cache/gajim/avatars/HASH_SHA1%00/moc.x//:sptth

it's placed before the link

even without all this, some users might not look at the URL scheme

Yeah but that's a user problem, and I guess KDE fixes the bug where it pipes stuff to bash

So if a link ends in a reversed URI scheme its dubious?

I think the "gajim bug" is just that it displays the wrong URL to the user, but I suspect it affects all clients hence the "how do you defend against this?" question, I have no idea

RTL is and always will be a pain

If it would be at least either or

But no some users want to write RTL while theire env is on something different ✏

But no some users want to write RTL while their env is on something different ✏

I wonder how eg firefox/chrome displays such a URL, and if they've solved this problem how easy it'd be to figure out how...

there's nothing special about the URL, only the context in which it's displayed

which doesn't matter on a website since the link text could be anything

browsers do prompt users before opening other programs though

browsers let you see the URL destination before clicking it though

that too

does it show https://... or telnet://... for this ?

telnet

since the RTL override is not part of the URL at all

but that's probably just by luck of showing it in a separate place ?

yeah

I have no idea what the right thing to do here is but it should probably be figured out and documented someplace shared maybe modernxmpp? cc MattJ

lovetox: are you also fixing the "bug" "avatar code allows strangers to write arbitrary files to my system" ? might be good for defense in depth, unless checking file content opens up another vuln rofl

we are thinking about solutions but its not trivial

for simple formats like a png or jpeg we could load it into the image lib and encode it again, this probably gets rid of all non-image data

but then again avatars is just one delivery mechanism, i bet there are countless others where you can get a specific file to someones harddisk

please do document what you end up doing somewhere even if it's just pasted into wiki.xmpp.org

i dont think this was a particular hard challenge, the challenge is usually to execute it

if you can prevent being able to create a file at a known path that would be better than nothing

i also dont understand the flow that user do in countries where they have RTL

when would they insert this character?

this would be just useful if i want mixed content or? but why would users on IM Platforms want to have mixed text

same, the easy fix for non-rtl users is just displaying a big scary "this person is probably trying to attack you" message and stripping it , but I have no idea how it should work for people who do want rtl sometimes :/

it seems the problem is for people that write in some chats RTL and in others english (LTR)

they need to configure the env for one or the other

this would not matter for latin characters because they are always defined LTR

but it seems there are neutral chars, like punctations, and if they are at the end or beginning they take the directionality of the env

means if someone has their env set to RTL, and type a english sentence in the chat, it will look like this ".This is English"

to fix that, they insert the LTR mark before the period, tho force it to LTR

maybe fix is as simple as URLs should never be displayed RTL ?

where's our RTL expert...

maybe, im not sure what users do if the write hebrew, and post in the middle a latin url, if they reverse it, or leave it as it is

I do have friends from Israel I could ask.

same, interested to find out though

hrm sch isn't here now, let's see if we can summon him *cough* pubsub atom rss

but what about my idea, to check if the end of the link is a reversed uri scheme

btw the link in the article does not work anymore

seems they used a old version of Gajim with better url detection, the current url detection stops somwhere in the middle, because its worse :D

> seems they used a old version of Gajim with better url detection, the current url detection stops somwhere in the middle, because its worse :D Task failed successfully? ↺

you mean you uh totally fixed that on purpose ? congrats !

> seems they used a old version of Gajim with better url detection, the current url detection stops somwhere in the middle, because its worse :D works for me here ↺

So the bug is that it uses RTL mode with a malicious URL written "backwards?"

‮telnet:.cache/gajim/avatars/HASH_SHA1%00/gro.mijag//:sptth

https://share.conversations.im/meeson_/message/Rf4Krxp6BydB8l2Y/Bildschirmfoto_20260831_183138.png

Hmm

And this would trigger a telnet URI

> works for me here yes i did it wrong, it still works ↺

but i used the longer one, they obfuscate the path by percent encoding it

> So the bug is that it uses RTL mode with a malicious URL written "backwards?" one of the bugs yes, the one that likely affects all clients and where the fix isn't obvious (to me anyway) ↺

> one of the bugs yes, the one that likely affects all clients and where the fix isn't obvious (to me anyway) Well Livewire does not render it as a clickable link. Probably because it doesn't have any RTL in mind lol ↺

mmm, well okay it does not like the encoded chars % here:

https://share.conversations.im/meeson_/message/Eg6Fuvwuyq1pi4wC/Bildschirmfoto_20260831_183403.png

no you did it also wrong

you cannot copy that from the site

:D

you need to reverse that string, and then post it with RTL

because the string just reversed, is not a valid url because the percent encodings are wrong

they posted how the result looks on the site, not how they put it into the application

Are RTL strings still left to right as far as the actual raw UTF8 bytes are concerned?

Like you don't need to iterate backwards.

we need a bot you can send a request to that'll respond appropriately, that'll make testing all the clients easiest, if no one beats me I'll try to set this up tonight

> Are RTL strings still left to right as far as the actual raw UTF8 bytes are concerned? typed u202eLTR, which yields RTL. The inspector says the label contains ✏ ↺

‮ 202E L 004C T 0054 R 0052

which is still RTL, when I paste it here. I am confused

i would expect on the wire everything is LTR

so the bytes are left to right parsed

The bytes within UTF-8 are in the same order, and the codepoints are in "reading" order, so for RTL the R-most would be first on the wire.

The wire in neither LTR nor RTL, technically. You just think it's LTR because that's your normal reading direction.

(For an Arabic speaker, say, they'd think that English was written RTL on the wire)

Obviously depends on which direction the wire is laid.

> The bytes within UTF-8 are in the same order, and the codepoints are in "reading" order, so for RTL the R-most would be first on the wire. Yes but basically, index 0 is the first character regardless of reading order, right? ↺

Well, I assumed you read characters in order, so yes?

>> The bytes within UTF-8 are in the same order, and the codepoints are in "reading" order, so for RTL the R-most would be first on the wire. > Yes but basically, index 0 is the first character regardless of reading order, right? lua rejects this question entirely ↺

> lua rejects this question entirely We don't talk about that ↺

> Obviously depends on which direction the wire is laid. Lol ↺

dwd, the bytes are in the order a client puts them there i would expect, so the question would be what a text input gives back the developer

the input would need to return the characters in the order the user typed them

لا أَعْرِف

it does not matter on what side of the input they are added

But I would expect it in the same order - so the ل then ا and so on.

(Given Arabic orthography that's not helpful, actually, but those are the rightmost and second-rightmost characters)

> Are RTL strings still left to right as far as the actual raw UTF8 bytes are concerned? The first character in the string (rendered rightmost) is first, so you can consider all characters to be encoded LTR, and it's up to the renderer to decide how to draw the strings (which includes switching direction according to which characters are used) ↺

but you cannot say this by just looking at a string how it will end up on the wire

you can if you see the string in the application, and see its on the right side, then you can deduce how it was typed, and therefore deduce how programm will put it on the wire

I haven't read all of the backlog, so maybe there's a separate issue; for Arabic specifically, rendering depends heavily on ligatures, so each rendered character depends on which characters appear before and after it, but there is a defined ordering and if you know Arabic then you will know which characters are there and the codepoints be encoded in sequence (rightmost first, leftmost last)

yes under the assumption that nobody uses Left-Right Marks (Invisible Control Characters) to change the order

You can potentially do interesting things using those, though I wonder how strongly renderers follow them given that they already need to work correctly even when they're not present

And the true answer is: it's complicated - see https://en.wikipedia.org/wiki/Bidirectional_text#Unicode_bidi_support But yes, the encoded ordering is not necessarily clear from the visual ordering