XSF Discussion - 2023-05-09

is URL decoding eventually idempotent?

encoding isn't (you can always slap on another layer of encoding), but does decoding eventually lead to a set of characters that cannot be decoded into a different set of characters (and still retain their original semantics)?

Guus: wellll, kinda. imagine decoding "%2525252525" in a loop. eventually it's gonna end at invalid syntax :D (% at the end of string)

so, strictly speaking, you should care for the number of decodings done ✏

Guus, you can't just decode until there is nothing left to decode, you need to decode the exact same number of times as it was encoded

For example, if I have a file that I save as %25.jpg, and then I upload it, the URL would be https://example.com/%2525.jpg. When someone downloads it, it should be called "%25.jpg" (the original filename), not "%.jpg" (in such a case, the original filename has been lost)

one should also be able to upload and download a file called %2F ;D

I think that blocking support for such file names would be a more sensible approach than to exposing users to the incompetence of developers ;)

but blocking needs to be... developed!

Hehe try downloading a file called "CON" on Windows ;)

it's a CON!

success depends on whether using the win32 or kernel API ;P

> movim=# select count(*) from contacts where bannerhash is not null; > 148

Looks like the profile banner feature is quite successfull :)

I'm thinking of writing a small XEP for it

Do it

To add to the "millions of XEPs" that XMPP already has (to quote someone on HN today) 😄

People need to make up their minds. Do we have not enough features or too many? 😉

yes

Maybe for the next humorous XEP we coudl simply compile all the others in one big XEP

"There, you just need to implement that XEP and should be good"

^^

sounds like a job for chatgpt

I thought about that, except easily a third of the xeps aren't really. More like compile the compliance suites into annual monospecs

But then someone will say "this spec is too long"

How could it be too long with 45 and 60 included ;-).

So the RFC approach?

0045+$any_xep = too long

All we can do is keep working on the ecosystem. If people can use it and do dev work all without reading any specs at all, then they won't care how many or how long

No webdev says the html+css+JavaScript+several http+DNS specs are too many too long. They simply remain unaware of them because they have good libraries to use etc ✏

b-b-but every client developer MUST write their own xml parser!

and an xmpp library on top

If that is true it is exactly the problem. I think it's not true, but it is somewhat popular as an approach

I did write a blog post producing a fairly functional client on a library

But also most devs won't want to build a client but a bot or component or special use app

> it is somewhat popular as an approach I was referring to this, and it seems to be viral

or there's just too many languages popping up

vala, go, dart, what else?!

*Elbe-Sprint Hamburg 2023* Dear developers & community, in June the Elbe-Sprint takes place in Hamburg. Would be great to see you there! If you want to join, but don't got a wiki account ask me or others for a favor to do so. https://wiki.xmpp.org/web/Sprints/2023-06_Elbe-Sprint_Hamburg https://jabbers.one:5281/file_share/RD3geQ-OCYRKE1_6I0Hzweoe/elbe-sprint.png