XSF Discussion - 2022-03-08

  1. emus

    Hey folks, if we want this celebration soon, we would need more contributions: https://yopad.eu/p/xmpp-celebration2022-365days If not, no problem, its just that I would not continue with this. Let me know your feedback

  2. Guus

    emus: I welcome the initiative, but I'm not much of a story teller myself.

  3. emus

    Is alright! you can also use it to shortly tell how it backs your software for example (if it makes that easier). I just intended to give some directions, but no need to.

  4. emus

    Guus: I am also happy to simply post an image of your beloved XMPP shirts 😅 I assume this is the true proof of loyality 😉

  5. Zash

    With the covid crisis over, can we gather in that tunnel and take a group picture now?

  6. Zash

    Although I imagine getting there hasn't gotten easier :/

  7. jonas’

    just everyone take a picture in front of a green/white screen and have the rest being done by photoshop

  8. emus

    That's the motivation I wanna hear! 😍

  9. Ingolf

    > we are accepted into gsoc \o/ Congratulations This is good news for the spread of Jabber/XMPP! It's nice that Google allowed it, when they shut down their Jabber/XMPP. The good browser 'Vivaldi' is working on a Jaber/XMPP chat, which will then be integrated into the browser ;-)

  10. Ingolf

    > The current situation around Ukraine and especially Russia really shines another light on disappearing (self-destructing) messages. > Maybe those should be revisited Very good thought ;-)

  11. larma

    I remember some discussion about multipart/alternative in messaging: apparently matrix just moved from their "limited html + markdownish plain text fallback" to some multi mime format that looks featurewise similar to multipart/alternative: https://www.artificialworlds.net/blog/2022/03/08/comparison-of-matrix-events-before-and-after-extensible-events/

  12. lovetox

    and? is this not what we had with xhtml?

  13. Zash

    and is email really something worth taking ideas from?

  14. lovetox

    it sure is simpler then whatever we wanted to do with adding information which codepoint is formed in which way ✎

  15. lovetox

    it sure is simpler than whatever we wanted to do with adding information which codepoint is formed in which way ✏

  16. Zash

    having it formally written down that <body> and xhtml-im are variants of the "same" content is good tho, if that isn't already written somewhere

  17. lovetox

    but has other drawbacks, i think for example when encrypting and you dont have full stanza encryption it is error prone

  18. mathieui

    Zash, it was already normative

  19. mathieui

    ("In Jabber/XMPP communications, the meaning (as opposed to markup) of the message MUST always be represented as best as possible in the normal <body/> child element or elements of the <message/> stanza qualified by the 'jabber:client' (or 'jabber:server') namespace. ")

  20. Zash

    Right-o

  21. moparisthebest

    but also that's useless and cannot be relied upon

  22. moparisthebest

    not that we don't have the exact same problem with the multiple-language support

  23. Zash

    It's not like multipart/alternative solves anything, just structures it differently

  24. mathieui

    moparisthebest, unless you provide a lightweight, deterministic multi-language validator & generator that anyone can embed into their clients to ensure that all multipart elements can be narrowed down to the text representation, this is going to be hard

  25. moparisthebest

    right, so it's really just best to only support sending 1 body representation so there is never any ambiguity

  26. mathieui

    well, if you can accept having your meaning polluted with inline markup, yes

  27. Zash

    https://xmpp.org/extensions/xep-0394.html to the rescue

  28. moparisthebest

    right, don't do that either, pollute your *own* text with inline markup like we've been doing since ye olden days

  29. Ge0rG

    So I've done a bunch of grepping of XEPs for xmlns'es, and got some artifacts where I'm not sure if they are editorial or normative.

  30. Ge0rG

    https://xmpp.org/extensions/xep-0406.html#example-4 is using <pubsub xmlns='http://jabber.org/protocol/'> which is not the pubsub xmlns

  31. Ge0rG

    https://xmpp.org/extensions/xep-0105.html#example-1 is mixing /profile/ and /protocol/ in funny ways

  32. Ge0rG

    https://xmpp.org/extensions/xep-0087.html#example-4 is using xmlns='http://jabber.org/si' instead of /protocol/si/

  33. Ge0rG

    cc jonas’ maybe?

  34. mathieui

    the protocol police strikes again

  35. moparisthebest

    If they are wrong they are editorial and if they are right they are normative, problem solved

  36. Ge0rG

    https://xmpp.org/extensions/xep-0072.html#example-8 is using xmlns='http://jabber.org/protocol/si-pub' and example 9 has /sipub

  37. Ge0rG

    moparisthebest: you do't say ✎

  38. Ge0rG

    moparisthebest: you don't say ✏

  39. Ge0rG

    https://xmpp.org/extensions/xep-0390.html mentions a non-existing /protocol/iqibb namespace

  40. moparisthebest

    Ge0rG: don't forget 156 linking to a registry that doesn't exist

  41. Ge0rG

    I've created a first version of a namespace to XEP mapping in apache redirect format, to be rolled out on jabber.org. https://op-co.de/tmp/namespacemap.txt is the file, I've briefly reviewed it but errors are well possible. CC MattJ

  42. Ge0rG &

  43. jonas’

    Ge0rG, make PRs