jdev - 2024-09-18

Hello

Dears, if I have `<a href="xmpp:foo\40example.com@otherexample.com">foo</a>` in my browser HTML and open the link with Gajim, it tries to communicate with `foo%5c40example.com@otherexample.com`. Where is the bug? In the HTML or in Gajim?

singpolyma likely has opinions and experience here ^

oh hi

bug is not in the html, since `xmpp:foo\40` and `xmpp:foo%5c40` are the same thing ✏

What if you right click the link and copy it, what does a paste into a text editor do

I bet it pastes foo%5c40 which is totally fine and correct

If so then you are saying gajim should unescape it or?

Doesn't url-decode when extracting the JID from the xmpp: URI?

moparisthebest: yes

the different examples are what should `xmpp:foo%blah.com@example.com` do? (this one is invalid and so the browser might do who knows what random thing with it. solution is to fix the link) or worse `xmpp:#foo@example.com` (this one is effectively blank but doesn't look like it is because # ends the URL completely)

singpolyma, huh, in which grammar does `#` end an XMPP URL?

I thought that was an HTTP specific thing?

no, #fragment is a generic URI thing

fascinating

... I think

depending on which of the competing definitions you subscribe to

:)

> no, #fragment is a generic URI thing Correct ↺

or maybe the WHATWG one only for HTTP(S) URLs? I am not sure and now does not feel like the time to go read those specs

URL and URI and whatwg url agree on this point. # is never valid in any of them

singpolyma, buuutt... # *is* valid in HTTP URIs, isn't it?

it just isn't sent to the remote.

Nope

but it's constantly used.

It's not part of the uri

The fragment is an extra thing

ok, I'm gonna need specs now

Part of "Uri with fragment"

Tho it is special in a similar way to ?

specs in url land? Good luck

I mean you could say it's a distinction without difference. But officially it's not that you treat the fragment part of Uri special but rather fragment is not part of Uri and if you support fragments they're a seperate thing

https://everything.curl.dev/cmdline/urls/browsers.html is a helpful intro

singpolyma, I'm all for those nuances, but I wasn't aware of them. I'd like some document where it's written down which is not a third-party resource (sorry, moparisthebest ).

it makes sense that it's somehow special, given that it's not sent to HTTP servers for example

(and that that behaviour is consistent)

you want IETF RFC or WHATWG?

If you're ok with just uri it's in the rfc. Check the grammar for Uri you'll find # is not an allowed character in any position

because iirc they're subtly different :)

"the RFC" --- which one?

THE

https://www.rfc-editor.org/rfc/rfc3986 maybe? or follow the updated by chain

actually I should head to bed ✏

o/

I should be asleep :|

jonas’: the link I sent has links to all the various RFCs and standards and a brief explanation so I thought it was best

https://www.rfc-editor.org/rfc/rfc3986#section-3 looks like the thing to look at, if you're not sleeping

https://url.spec.whatwg.org/ (what browsers use, constantly changing) https://www.ietf.org/rfc/rfc3986.txt (the RFC some people use a bit from)

IIRC the WHATWG has different sets of allowed characters per URL component.

That RFC looks like it's talking about hierarchical so it mentions fragment

But xmpp is non hierarchical

I can find the ref later

So Gajim (or any client) should turn `%5c` into `\` again?

Yes

You can use %40 for the @ if you want

But there's no reason to ✏

The XEP (what number was it?) says `\40`, and I'm feeling uneasy in doing something non-standard.

Oh you meant for on jids. Yes \ for jid escaping

I thought you mean eg xmpp: someone%40example.com which is ok if course

But `\` is sometimes annoying, having special meaning in most programming languages. And users don't find on their keyboard or confuse it with `/`.

If we used % instead of \ in jid escaping then in URIs it would be xmpp:blah%2540thing.com@example.com

TBF users aren't generally meant to see it, hopefully it's hidden behind auto escaping UI etc often

I mean in the context of e.g. email-XMPP gateways.

In an alt universe I'd use xmpp URIs directly in the wire protocol like sip does and then we wouldn't need any escaping mechanism at all

Yes, it's mostly hidden, but here and there it is hard to avoid that users see their JID, or they even must see it for certain actions.

Could show it in a human presentation way sometimes like browsers do with URLs. You rarely see %20 anymore they hide it

In my use case, it is not an email gateway, btw. but we are just abusing users verified email addresses to create a JID, that is "verified by email" 😀️

Oooh. Like quicksy

In almost all cases we only show the email address and hide the server part.

I love it

Haha, yes, in a way like Quicksy.

Is this a secret project?

It's free software: https://codeberg.org/Ammonit/ammonit-live-dashboard/src/branch/main/accounts

AGPL3

Maybe at some point, we can separate that function from the main project (dashboard), so that it can be reused easier.

It has the same drawback as Quicksy: If there were multiple server with the same scheme, people still cannot find others, if they are on a different server. Phone number (or email address) are only unique and easy to find on one server. In our use case, that does not matter, because it's all about IoT machine-to-human communication and human-to-human communication is not in our scope (but we do not prevent it).

Also, we do not filter one-time email addresses (such as guerillamail), so there is no spam account protection atm. This is probably better with Quicksy, as phone numbers are somewhat expensive.