jdev - 2021-12-24

  1. glickyong has left

  2. defanor has left

  3. atomicwatch has left

  4. marc0s has left

  5. marc0s has joined

  6. msavoritias has left

  7. marc0s has left

  8. marc0s has joined

  9. glickyong has joined

  10. marc0s has left

  11. marc0s has joined

  12. marc0s has left

  13. marc0s has joined

  14. marc0s has left

  15. marc0s has joined

  16. emus has left

  17. jgart has left

  18. debacle has left

  19. marc0s has left

  20. marc0s has joined

  21. glickyong has left

  22. FireFly has left

  23. glickyong has joined

  24. sonny has left

  25. glickyong has left

  26. glickyong has joined

  27. mac has joined

  28. jgart has joined

  29. mac has left

  30. marc0s has left

  31. marc0s has joined

  32. glickyong has left

  33. Yagizа has joined

  34. mac has joined

  35. contrapunctus

    😄

  36. kikuchiyo has left

  37. Alex has left

  38. wurstsalat has left

  39. rafasaurus has left

  40. rafasaurus has joined

  41. Жокир has joined

  42. Жокир

    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?

  43. mac has left

  44. Yagizа has left

  45. defanor has joined

  46. Alacer_dsrt has joined

  47. mac has joined

  48. emus has joined

  49. jonas’

    Жокир, <query/>, in about every standard using IQs

  50. jonas’

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

  51. COM8 has joined

  52. atomicwatch has joined

  53. COM8 has left

  54. COM8 has joined

  55. COM8 has left

  56. nephele has joined

  57. Yagizа has joined

  58. glickyong has joined

  59. atomicwatch has left

  60. Yagizа has left

  61. atomicwatch has joined

  62. paul has joined

  63. atomicwatch has left

  64. atomicwatch has joined

  65. wurstsalat has joined

  66. marmistrz has joined

  67. Neustradamus has left

  68. Neustradamus has joined

  69. Martin has left

  70. Martin has joined

  71. FireFly has joined

  72. huhn has left

  73. emus has left

  74. emus has joined

  75. Alex has joined

  76. atomicwatch has left

  77. atomicwatch has joined

  78. debacle has joined

  79. sonny has joined

  80. moparisthebest has left

  81. marmistrz has left

  82. flow

    Жокир, not only XMPP does use namespaces, but XML parser do too

  83. 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

  84. msavoritias has joined

  85. Жокир

    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

  86. Жокир

    And lots of bandwidth

  87. moparisthebest has joined

  88. mac has left

  89. doge has left

  90. doge has joined

  91. MattJ

    News to me that some short text strings are "lots of bandwidth" 🙂

  92. Yagizа has joined

  93. MattJ

    XMPP implementations would be a horrible mess without namespaces

  94. mac has joined

  95. Жокир

    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%

  96. Жокир

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

  97. 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.

  98. jgart has left

  99. Жокир

    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

  100. 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

  101. contrapunctus

    Жокир: s-expressions FTW 🙂

  102. 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

  103. jgart has joined

  104. Жокир

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

  105. Жокир

    if you have enough time and resources

  106. 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 :)

  107. Жокир

    Extensiblity doesn't mean bloat

  108. Жокир

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

  109. 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.)

  110. 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...

  111. 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 )

  112. Жокир

    >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

  113. 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.

  114. contrapunctus

    defanor: do tell...what happens?

  115. defanor

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

  116. 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.

  117. defanor

    "With those in mind", even.

  118. selurvedu

    > Heard about that, also heard that lots of software doesn't support it 🙂 Dunno, works for me 🙃️

  119. glickyong has left

  120. Жокир has left

  121. al has joined

  122. 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.

  123. 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

  124. contrapunctus

    defanor: pattern matching? 🤷

  125. Zash

    flow: just gotta xep that negotiation

  126. flow

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

  127. 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! ✎

  128. 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! ✏

  129. al has left

  130. 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.

  131. 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.

  132. Zash

    flow: I don't christmas, sorry.

  133. defanor

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

  134. defanor

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

  135. me9 has joined

  136. flow

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

  137. 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)

  138. marc0s has left

  139. marc0s has joined

  140. Wojtek has joined

  141. mac has left

  142. mac has joined

  143. 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...

  144. debacle has left

  145. 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

  146. marc0s has left

  147. marc0s has joined

  148. marc0s has left

  149. marc0s has joined

  150. marc0s has left

  151. marc0s has joined

  152. contrapunctus

    So...are there any working implementations of group voice chat? 🤔

  153. Zash

    contrapunctus: yes

  154. Zash

    Or, working on at least

  155. Zash

    Dino and JSXC afaik

  156. contrapunctus

    Huh

  157. wurstsalat

    looks like dino group voice chats just landed in master

  158. contrapunctus

    Wow, I must try that.

  159. pasdesushi has left

  160. Wojtek has left

  161. emus

    yes, but it is still deactivated I think

  162. PapaTutuWawa has joined

  163. pasdesushi has joined

  164. 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

  165. Жокир has joined

  166. mac has left

  167. mac has joined

  168. kikuchiyo has joined

  169. 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.

  170. inky has joined

  171. Zash

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

  172. Жокир

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

  173. lovetox

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

  174. Zash

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

  175. jgart has left

  176. jgart has joined

  177. me9 has left

  178. 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

  179. 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.

  180. mac has left

  181. mac has joined

  182. Zash

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

  183. flow

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

  184. 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

  185. debacle has joined

  186. Zash

    Make it an editor macro

  187. flow

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

  188. flow

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

  189. 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.

  190. 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.

  191. flow

    thanks Link, that's actually a good example

  192. 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

  193. Alastair Hogge has left

  194. flow

    at least that is my impression

  195. 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

  196. 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.

  197. flow

    "Englicrypted", like that :)

  198. 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. ^^

  199. flow

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

  200. 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"/>

  201. Link Mauve

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

  202. Link Mauve

    doge, what is the issue here?

  203. 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?

  204. Link Mauve

    I used C.

  205. Link Mauve

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

  206. 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)

  207. flow

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

  208. Link Mauve

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

  209. 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.

  210. 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.

  211. Link Mauve

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

  212. 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.

  213. flow

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

  214. flow

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

  215. flow

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

  216. 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

  217. Link Mauve

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

  218. mac has left

  219. Link Mauve

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

  220. 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

  221. Link Mauve

    doge, feel free to use XEP-0335.

  222. Zash

    Mmmmmmmmod_rest?

  223. Link Mauve

    Or that.

  224. 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

  225. rafasaurus has left

  226. Link Mauve

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

  227. jgart has left

  228. Жокир has left

  229. mac has joined

  230. 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 :)

  231. flow

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

  232. flow

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

  233. flow

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

  234. rafasaurus has joined

  235. pep.

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

  236. sonny has left

  237. sonny has joined

  238. PapaTutuWawa has left

  239. Alastair Hogge has joined

  240. Alex has left

  241. Alex has joined

  242. inky has left

  243. inky has joined

  244. marmistrz has joined

  245. glickyong has joined

  246. moparisthebest has left

  247. pep.

    Not that many useful errors in PubSub :/

  248. marmistrz has left

  249. pep.

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

  250. pep.

    (For nodes)

  251. inky has left

  252. debacle has left

  253. moparisthebest has joined

  254. goffi has left

  255. Alastair Hogge has left

  256. atomicwatch has left

  257. me9 has joined

  258. atomicwatch has joined

  259. glickyong has left

  260. Alastair Hogge has joined

  261. mac has left

  262. mac has joined

  263. glickyong has joined

  264. emus has left

  265. Alex has left

  266. Alex has joined

  267. glickyong has left

  268. me9 has left

  269. me9 has joined

  270. pulkomandy has left

  271. pulkomandy has joined

  272. nephele has left

  273. goffi has joined

  274. 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?

  275. marc0s has left

  276. marc0s has joined

  277. mac has left

  278. mac has joined

  279. glickyong has joined

  280. me9 has left

  281. sonny has left

  282. sonny has joined

  283. sonny has left

  284. sonny has joined

  285. Martin

    https://github.com/JabberSPAM

  286. Martin

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

  287. lovetox has left

  288. stuart.j.mackintosh

    Thanks Martin

  289. lovetox has joined

  290. inky has joined

  291. rafasaurus has left

  292. glickyong has left

  293. larma has joined

  294. rafasaurus has joined

  295. Alacer has joined

  296. Alacer_dsrt has left

  297. Alacer_dsrt has joined

  298. Alacer_dsrt has left

  299. Alacer_dsrt has joined

  300. sonny has left

  301. Martin

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

  302. larma has left

  303. nephele has joined

  304. inky has left

  305. Alacer_dsrt has left

  306. marc0s has left

  307. marc0s has joined

  308. Alacer has left

  309. glickyong has joined

  310. alacer has joined

  311. rafasaurus has left

  312. alacer has left

  313. lovetox has left

  314. jgart has joined

  315. rafasaurus has joined

  316. antranigv has left

  317. lovetox has joined

  318. sonny has joined

  319. mac has left

  320. mac has joined

  321. Neustradamus has left

  322. mac has left

  323. mac has joined

  324. inky has joined

  325. moparisthebest has left

  326. pulkomandy has left

  327. pulkomandy has joined

  328. Ingolf has left

  329. pulkomandy has left

  330. pulkomandy has joined

  331. pulkomandy has left

  332. pulkomandy has joined

  333. Ingolf has joined

  334. marc0s has left

  335. marc0s has joined

  336. marc0s has left

  337. marc0s has joined

  338. nephele has left

  339. glickyong has left

  340. al has joined

  341. emus has joined

  342. antranigv has joined

  343. mac has left

  344. mac has joined

  345. Yagizа has left

  346. marc0s has left

  347. marc0s has joined

  348. PapaTutuWawa has joined

  349. debacle has joined

  350. mac has left

  351. mac has joined

  352. al has left

  353. inky has left

  354. dezant has joined

  355. mac has left

  356. Yagizа has joined

  357. emus has left

  358. bung has joined

  359. debacle has left

  360. bung has left

  361. inky has joined

  362. bung has joined

  363. bung has left

  364. Yagizа has left

  365. mac has joined

  366. inky has left

  367. msavoritias has left

  368. moparisthebest has joined

  369. inky has joined

  370. sonny has left

  371. sonny has joined

  372. sonny has left

  373. sonny has joined

  374. inky has left

  375. marc0s has left

  376. marc0s has joined

  377. antranigv has left

  378. marc0s has left

  379. marc0s has joined

  380. atomicwatch has left

  381. pep.

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

  382. mac has left

  383. 9lakes has left

  384. antranigv has joined

  385. 9lakes has joined

  386. atomicwatch has joined

  387. marc0s has left

  388. marc0s has joined

  389. atomicwatch has left

  390. goffi has left

  391. dezant has left