jdev - 2021-12-24

  1. contrapunctus

    πŸ˜„

  2. Π–ΠΎΠΊΠΈΡ€

    Xmpp makes heavy use of namespaces, but are they in reality all that significant? I mean, are there actually any elements defined by existing standards that have different namespaces but same names?

  3. jonas’

    Π–ΠΎΠΊΠΈΡ€, <query/>, in about every standard using IQs

  4. jonas’

    there's also <body xmlns="jabber:client"/> vs. <body xmlns="http://www.w3.org/1999/xhtml"/>

  5. flow

    Π–ΠΎΠΊΠΈΡ€, not only XMPP does use namespaces, but XML parser do too

  6. flow

    and name clashes are a thing, even though they are usually mostly encountered in large projects, while namespaces are an easy way to solve it

  7. Π–ΠΎΠΊΠΈΡ€

    I know they are a thing in theory, I was asking about xmpp practice. But I've already been told they indeed are a thing there. Damn those thing add a level a complexity, as if streaming xml wasn't complicated enough

  8. Π–ΠΎΠΊΠΈΡ€

    And lots of bandwidth

  9. MattJ

    News to me that some short text strings are "lots of bandwidth" πŸ™‚

  10. MattJ

    XMPP implementations would be a horrible mess without namespaces

  11. Π–ΠΎΠΊΠΈΡ€

    Well, compared to the contents itself they certailnly are. Like in <a xmlns='urn:xmpp:sm:3' h='1'/> meaningful characetrs here are basically "a" and "1". That's two characters. Thanks to xml, and thanks even more to the brilliant idea to send the namespace with every ack, the proportion of meaningful data to xml details is 2:29. Which is about 7%

  12. Π–ΠΎΠΊΠΈΡ€

    And that's a namespace that at least doesn't include "https://..." like some others do

  13. selurvedu

    > meaningful characetrs here are basically "a" and "1" um... I am not even going to try to explain why there's much more to it than you say.

  14. Π–ΠΎΠΊΠΈΡ€

    With s exps this could be smth like (a 1) Even with xml this could at least boild down to <a h='1'/>, three times shorter

  15. selurvedu

    Also, see how WhatsApp having similar concerns managed to compress XML in their proprietary FunXMPP protocol https://sci-hub.se/10.1016/j.diin.2015.09.002

  16. contrapunctus

    Π–ΠΎΠΊΠΈΡ€: s-expressions FTW πŸ™‚

  17. pulkomandy

    there is stream compression defined in XMPP or apparently you can use compression at the TLS level (according to https://xmpp.org/extensions/xep-0138.html), I would say that the very repetitive parts of XML will compress very well with that

  18. Π–ΠΎΠΊΠΈΡ€

    Of course you can *manage* to compress it. But no popular client does. You can *manage* any kind of bloat.

  19. Π–ΠΎΠΊΠΈΡ€

    if you have enough time and resources

  20. pulkomandy

    or you can remove the X in XMPP and make it a non-extensible protocol. Then you can remove a lot of things form it :)

  21. Π–ΠΎΠΊΠΈΡ€

    Extensiblity doesn't mean bloat

  22. Π–ΠΎΠΊΠΈΡ€

    if it weren't for the readily existing code, <a h='1'/> could work just as well

  23. contrapunctus

    .o(It's probably not too difficult to define an s-expression encoding for XML (since this can vary between XML libraries), and have XMPP-over-sexp. Probably be easy to use it too - server can decide what to use based on what the client sends.)

  24. selurvedu

    Π–ΠΎΠΊΠΈΡ€, do you have some specific need for saving traffic? I find XMPP using just tiny bits of traffic compared to many modern messengers and other apps. Of course, enterprise usage and server owners will use more traffic...

  25. selurvedu

    Π–ΠΎΠΊΠΈΡ€, you don't have to include namespaces with every single element. It's not that problematic as you describe it. https://xmpp.org/rfcs/rfc6120.html#streams-ns Also some other people actually don't like namespaces as well, it's been discussed (see here https://wiki.xmpp.org/web/XMPP_Office_Hours/2021-04-13-Notes )

  26. Π–ΠΎΠΊΠΈΡ€

    >compared to modern messengers and other apps That's not saying much is it πŸ™‚ Saying "lighter than modern apps" is like saying "cleaner than sewage" No, I don't have any specific requirements for saving traffic. Instead I'm evaluating xmpp among other protocols and wondering maybe there's a rationalization to ascpects I find irrational. >you don't have to include namespaces with every single element. It's not that problematic as you describe it. https://xmpp.org/rfcs/rfc6120.html#streams-ns Heard about that, also heard that lots of software doesn't support it πŸ™‚ Another example of how one *can* in principle manage bloat, but that doesn't mean you will

  27. defanor

    contrapunctus, IME encoding XML in s-expressions (as in SXML and/or Emacs's xml.el) becomes perhaps more awkward than just using XML when you try to handle namespace prefixes and attribute namespaces.

  28. contrapunctus

    defanor: do tell...what happens?

  29. defanor

    contrapunctus, well, you have lots of s-expressions. A lot of nesting, I find it harder to read and write than XML.

  30. defanor

    Not like the s-expressions you'd normally compose, if you've designed a protocol or an API for those in mind at once.

  31. defanor

    "With those in mind", even.

  32. selurvedu

    > Heard about that, also heard that lots of software doesn't support it πŸ™‚ Dunno, works for me πŸ™ƒοΈ

  33. flow

    Π–ΠΎΠΊΠΈΡ€ I think if you have a text based protocol, than written out names make the protocol more accessible, even though it consumes more bytes on the wire. That's a similar argument when programming, in favor of self-explaining variable names, compared to single letter variables names. I doubt that those extra bytes on the wire kill your battery or will have you run into your traffic quota. That said, I did not measure it myself, but, as far as I can tell, most people complaining about the verbositiy of XMPP do so only based on their gut feeling. It would be really nice if we had some hard facts.

  34. flow

    Π–ΠΎΠΊΠΈΡ€, you may be happy to hear that "<a xmlns='urn:xmpp:sm:3' h='1'/>" could probably be easily shorted into "<a:sm h='1'>" if this particular feature of XML namespaces has been negotiated with the remote party

  35. contrapunctus

    defanor: pattern matching? 🀷

  36. Zash

    flow: just gotta xep that negotiation

  37. flow

    Zash, wanna give me a little christmas present? :)

  38. contrapunctus

    defanor: > contrapunctus, well, you have lots of s-expressions. A lot of nesting, I find it harder to read and write than XML. Oh wait, there are libraries to query the s-expressions! ✎

  39. contrapunctus

    defanor: > contrapunctus, well, you have lots of s-expressions. A lot of nesting, I find it harder to read and write than XML. Oh wait, there are libraries to query the s-expression representations of XML! ✏

  40. defanor

    contrapunctus, pattern matching is awkward for XML, since order normally matters there (at least in generic ones for s-exps, like pcase), but not in XML, and IIRC parsers tend to preserve the order. Libraries for querying those structures would probably indeed be convenient, but that sounds similar to working with just some XML objects, not benefiting as much from those being encoded in s-expressions.

  41. defanor

    I mean the order of attributes and such, not child elements. Though the order of those matters in XML, but not always in XMPP.

  42. Zash

    flow: I don't christmas, sorry.

  43. defanor

    Hrm, though maybe even the order of attributes may matter in XML in general, but still not always in XMPP.

  44. defanor

    https://www.w3.org/TR/2008/REC-xml-20081126/#sec-starttags -- nope, the order of attributes indeed shouldn't be significant in general.

  45. flow

    yep, attribute order can not matter, since there can only be at most one attribute with a given name on an element

  46. flow

    element order, on the other hand, does matter in XML, but typically not in XMPP (there me be exceptions, but I don't have one at hand)

  47. contrapunctus

    defanor: I'd probably prefer it because easier on the eyes, compatible with standard list functions, less bytes to transfer, simpler for people to understand and for programs to parse...

  48. doge

    flow: > Π–ΠΎΠΊΠΈΡ€ I think if you have a text based protocol, than written out names make the protocol more accessible, even though it consumes more bytes on the wire. That's a similar argument when programming, in favor of self-explaining variable names, compared to single letter variables names. I doubt that those extra bytes on the wire kill your battery or will have you run into your traffic quota. That said, I did not measure it myself, but, as far as I can tell, most people complaining about the verbositiy of XMPP do so only based on their gut feeling. It would be really nice if we had some hard facts. I don't remember the quote exactly but Xml combines the readability of binary formats with the efficiency of plain text ones Xmpp streams are not human readable imho, at least not without heavy formatting. And frankly even in terms of efficiency even most plaintext formats easily beat xml. Take json, or even homebrewn formats like what freenet uses (fcp) And verbosity does not always mean readability. Sometimes it even precludes it. I'd consider the succinct python much more readable than the verbose java. And in the particular example of <a h='1'/>, specifying the xmlns='blahblah' does not improve readability one bit. It impairs it even beyond what xml has already done

  49. contrapunctus

    So...are there any working implementations of group voice chat? πŸ€”

  50. Zash

    contrapunctus: yes

  51. Zash

    Or, working on at least

  52. Zash

    Dino and JSXC afaik

  53. contrapunctus

    Huh

  54. wurstsalat

    looks like dino group voice chats just landed in master

  55. contrapunctus

    Wow, I must try that.

  56. emus

    yes, but it is still deactivated I think

  57. defanor

    contrapunctus, it can be fewer bytes, but as composed by Emacs's (xml-parse-region nil nil nil nil t) in Emacs, your message as an s-expression is actually larger: https://paste.uberspace.net/emacs-xml-sexp.txt

  58. defanor

    Not that s-expressions are unsuitable for XML manipulation though, it's just that even though I like them too, by simply piling XML's data model on top of the s-expressions one, you end up dealing with both at once, which I didn't quite like even locally.

  59. Zash

    Turns out XML is already a decent encoding of the XML data model. Who knew?

  60. Π–ΠΎΠΊΠΈΡ€

    not that the xml data model is a particularly decent one tho

  61. lovetox

    i love xml, its great, namespaces are perfect for extensibility

  62. Zash

    It's fine, not really a problem, not something I would qant to spend time arguing about. Especially not today.

  63. flow

    doge, I think that is true if you stare at raw XMPP XML, but pretty-printed XMPP XML is very readable IMHO. I can't tell you how much positive feedback I got from Smack users after Smack started pretty printing the XML in its debugger. I think that was for some people an eye opener

  64. defanor

    XML's verbosity and relative complexity used to bother me in the past, but then I've found myself agreeing with the common sentiment that it doesn't really matter: plenty of other things to worry/care about in a network protocol, often more important ones.

  65. Zash

    I'd rather figure out how to send less stuff than smaller stuff

  66. flow

    furthermore, the subset of XML that XMPP uses is pretty sane, and, for what it provides, not that complex

  67. flow

    I sometimes wish that it would be possible to write </> but then again, if this is my main critique of XML, then i'd say it's pretty good designed

  68. Zash

    Make it an editor macro

  69. flow

    well, my idea was that it would be on the wire too :)

  70. flow

    in fact, I think it is already an editor macro…

  71. Sam

    The subset thing is part of the problem. If you have to jump through hoops to make it sane, lots of people won't jump through those hoops and things will break. I'm not entirely sure my library handles this correctly, for example, and I know there have been issues with others that don't.

  72. Link Mauve

    β€œ11:47:07 flow> element order, on the other hand, does matter in XML, but typically not in XMPP (there me be exceptions, but I don't have one at hand)”, in XHTML-IM it is very much important to keep the order of children.

  73. flow

    thanks Link, that's actually a good example

  74. flow

    Sam, not sure about that. from the top of my head, the subset is mostly what most modern XML parsers accept per default, plus, no XML comments

  75. flow

    at least that is my impression

  76. doge

    > β€œ11:47:07 flow> element order, on the other hand, does matter in XML, but typically not in XMPP (there me be exceptions, but I don't have one at hand)” It doesn't mean the order is discarded does it Also yeah, xml carries more data than is actually used by xmpp. Such as element tails, element order

  77. Link Mauve

    When I wrote my first XMPP client, in high school, I did it by reverse engineering the XML logs of Gajim instead of reading the specification, these were Englicrypted and would have been of no use to me.

  78. flow

    "Englicrypted", like that :)

  79. Link Mauve

    Gajim only added newlines between tags, and that was enough for me to successfully write my first XMPP client for the Nintendo DS. ^^

  80. flow

    Link Mauve, it appears you broke the cipher by now ;)

  81. doge

    And then there is the usual xml stunt of <key>value</key> <key v="value/> Or in clinical cases <entry key="key" value="value"/>

  82. Link Mauve

    Turns out, daily exposure for 15Β years was enough for that. :D

  83. Link Mauve

    doge, what is the issue here?

  84. doge

    > Gajim only added newlines between tags, and that was enough for me to successfully write my first XMPP client for the Nintendo DS. ^^ What language did one write Nintendo DS programs in?

  85. Link Mauve

    I used C.

  86. Link Mauve

    I didn’t know C very well at the time, I was still afraid of pointers back then.

  87. flow

    doge, that's a matter of good XML (and, by extension, XMPP protocol) design. I think I spot bad design by now, but I fear I don't have compiled a list of guidelines (there are some guidelines on XML design on the web though)

  88. flow

    but then again, it is sometimes personal preference what the right thing to do is

  89. Link Mauve

    https://linkmauve.fr/dev/jabber8.3.5.tar.xz is the last version I worked on.

  90. Link Mauve

    It was the end of the winter break and I had to start school again, and the code was horrid so during the following holidays I couldn’t really get back to it.

  91. doge

    > And then there is the usual xml stunt of > <key>value</key> > <key v="value/> > Or in clinical cases > <entry key="key" value="value"/> Compared to Json: {'key': 'value'} Or tcl: {key value} It's more verbose and less readable.

  92. Link Mauve

    As a corollary of the earlier issue, this client’s source is Frencrypted. :p

  93. defanor

    I was about to say that those clinical cases aren't unique to XML: I saw JSON being used that way too. Sometimes even "key1"/"value1", "key2"/"value2", etc.

  94. flow

    doge, point taken, but that is due XML not having explicit support for dictionaries

  95. flow

    usually, but depending on the value, a good format is: <entry key='foo'>value</entry>

  96. flow

    I dont' think that this is a strong argument against XML, but maybe I am just to used to it

  97. doge

    > Compared to > Json: {'key': 'value'} > Or tcl: {key value} > It's more verbose and less readable. And carries superfluous info like the fact that the elements tag is empty, or well that it is one of the myriad of ways to write the same thing. Not just write differently, it'll be represented in the data model differently. While providing no advantages. That's a complexity for the sake of complexity

  98. Link Mauve

    This is all good, until you need multiple values, or i18n, or…

  99. Link Mauve

    See XEP-0004 for a more forward-looking way of encoding a dict.

  100. doge

    > usually, but depending on the value, a good format is: <entry key='foo'>value</entry> Super verbose and not readable, wasting space and traffic. Just like all xml <entry key='foo'>value</entry> is harder to read than {key value} And MUCH longer to write

  101. Link Mauve

    doge, feel free to use XEP-0335.

  102. Zash

    Mmmmmmmmod_rest?

  103. Link Mauve

    Or that.

  104. doge

    Link Mauve: that unfortunately won't fix the fact that writing an xmpp client has to start with writing short of an xml parser

  105. Link Mauve

    Right, unless like Zash said you use mod_rest. :)

  106. pep.

    I guess the only XML parser that you'd need to write only needs to go up until <features/>, then you can do whatever serialization format you want :)

  107. flow

    or unless you simply use an parser from one of the various existing xml libraries ✎

  108. flow

    or unless you simply use a parser from one of the various existing xml libraries ✏

  109. flow

    but yeah, you probably have to or want to pre-process the XMPP stream before handing it over to your XML parser

  110. pep.

    Is there a case where a pubsub node name is mandated, that isn't on PEP?

  111. pep.

    Not that many useful errors in PubSub :/

  112. pep.

    "Node Configuration Not Supported", "Insufficient Privileges", "NodeID Required", "No Configuration Options", "Node Does Not Exist"

  113. pep.

    (For nodes)

  114. stuart.j.mackintosh

    If XMPP were to become very popular in a short time, what implemented mechanisms (client or server as appropriate) exist now to manage spam and uninvited / unwelcome direct connection attempts?

  115. Martin

    https://github.com/JabberSPAM

  116. Martin

    There's a blacklist and in resources you found plenty modules for xmpp servers. ✎

  117. stuart.j.mackintosh

    Thanks Martin

  118. Martin

    There's a blacklist and in resources you'll find plenty modules for xmpp servers. ✏

  119. pep.

    Is there a way to know the room just got created when I join it?