XSF Discussion - 2023-05-09


  1. Guus

    is URL decoding eventually idempotent?

  2. Guus

    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)?

  3. mjk

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

  4. mjk

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

  5. mjk

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

  6. MattJ

    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

  7. MattJ

    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)

  8. mjk

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

  9. Ge0rG

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

  10. mjk

    but blocking needs to be... developed!

  11. vanitasvitae

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

  12. Ge0rG

    it's a CON!

  13. mjk

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

  14. edhelas

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

  15. edhelas

    Looks like the profile banner feature is quite successfull :)

  16. edhelas

    I'm thinking of writing a small XEP for it

  17. moparisthebest

    Do it

  18. MattJ

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

  19. singpolyma

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

  20. mjk

    yes

  21. edhelas

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

  22. edhelas

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

  23. emus

    ^^

  24. mjk

    sounds like a job for chatgpt

  25. singpolyma

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

  26. singpolyma

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

  27. intosi

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

  28. moparisthebest

    So the RFC approach?

  29. mjk

    0045+$any_xep = too long

  30. singpolyma

    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

  31. singpolyma

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

  32. singpolyma

    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

  33. mjk

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

  34. mjk

    and an xmpp library on top

  35. singpolyma

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

  36. singpolyma

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

  37. singpolyma

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

  38. mjk

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

  39. mjk

    or there's just too many languages popping up

  40. mjk

    vala, go, dart, what else?!

  41. emus

    *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