XSF Discussion - 2021-07-27

  1. moparisthebest

    Couldn't resist :) and maybe, same name there

  2. Maskugatiger

    hi guys,if u want find my group..on gajim.. u only type this keyword "maskuga" on search box. start/join. then click button Global Group Chat Search. that all.

  3. moparisthebest

    I warned him he should stop with the spam in dino channel before this, he insists it's not spam, this is channel #4 that I've seen

  4. ralphm

    Thanks, moparisthebest. Spam is in the eye of the beholder.

  5. Sam

    The office hours are today at 1600 UTC! Join us for "Building a Chat Bot on Ad Hoc Commands" by Christopher Vollick: https://socialcoop.meet.coop/sam-pku-dud-niv

  6. Holger

    Seems 0060's integer-or-max thing was defined for pubsub#max_items and two other node config options, but e.g. not for pubsub#max_payload_size, where I'd think it would make sense as well?

  7. phryk

    Sam, sounds interesting, was wondering how to go about creating XMPP bots – and there's a few hours left before that so i can get some food in me. :)

  8. phryk

    Sam, is it alright to share this invite link on the fediverse?

  9. MattJ

    phryk, https://fosstodon.org/@xmpp/106642759433718435

  10. phryk

    Oooh, didn't even know the XSF had a fedi account, but that makes so much sense in hindsight that I'm embarassed I didn't realize it.^^

  11. phryk

    wait lol, i already follow that account :D

  12. phryk

    any clue whether i need previous knowledge about ad-hoc commands or the internals of any other xmpp spec/xep?

  13. Sam

    I'm not sure, I haven't talked to the presenter about the content

  14. phryk

    alrighty. it seems as though this sort of talk is at least a semi-regular occurance?

  15. Sam

    In theory; lately no one seems to want to sign up

  16. phryk

    When I got this setup finished, I might be interested in saying a bit about secure XMPP setups.

  17. phryk

    That's gonna take at the very least a month tho. Besides some more minor stuff, I still have to implement a custom invite page, fix at least one bug in mod_e2e_policy and extend its featureset by a good chunk, and I never programmed in lua before. :P

  18. phryk

    Currently I'm writing a bunch of texts for the website to onboard people and give them what they need to make informed decisions.

  19. Sam

    You could always present on what you plan to do instead; that way it's more likely to happen 🙂

  20. phryk

    But that way, I don't have any actual findings. :P

  21. phryk

    Plus, it's an anarchist thing – I want propaganda of the deed: if I already did it and show it off it shows to others that and how it's possible. :)

  22. emus

    The office hours start in about 30 mins! Join us for "Building a Chat Bot on Ad Hoc Commands" by Christopher Vollick: https://socialcoop.meet.coop/sam-pku-dud-niv

  23. jonas’

    Sam, what's your final take on https://github.com/xsf/xeps/pull/1090, after list discussion?

  24. jonas’

    can it be closed, do you want to update it?

  25. Sam

    I still think it's fine as is, but might as well update it for the mam thing too

  26. jonas’

    Sam, could you explain where the current methods are not sufficient on list so that we have it documented? It's still not obvious to me.

  27. goffi

    jonas’: hi, I didn't change the status from Deferred to experimental for https://github.com/xsf/xeps/pull/1094, will it be done automatically?

  28. goffi

    apparently not, I'll make an other PR then

  29. jonas’

    goffi: thx!

  30. MattJ

    <iteam-hat>I guess the E2EE SIG wants a mailing list? How about a MUC? (cc vanitasvitae)

  31. goffi

    jonas’: https://github.com/xsf/xeps/pull/1097/files

  32. vanitasvitae

    I have thought about that as well, but I'm not sure how muvh benefit dedicated lists and rooms would bring.

  33. vanitasvitae

    But it can't hurt either I guess. Whats the process of getting a MUC registered on xmpp.org?

  34. MattJ

    My opinion is that a MUC would be valuable, but list discussion would be better on standards@ if the traffic is low

  35. vanitasvitae

    Yeah, thats more or less my opinion as well

  36. vanitasvitae

    Too many lists to keep track of :D

  37. MattJ

    But never enough MUCs!

  38. vanitasvitae


  39. me9

    > MattJ wrote: > My opinion is that a MUC would be valuable, but list discussion would be better on standards@ if the traffic is low What muc address would that be?

  40. me9

    It was stated here, not so long ago, that the XSF makes no software for XMPP but only discusses the standards, XEPs. Or did I get this wrong? Does it also write the XEPs? I mean defining something in detail without making it would feel weird to me.

  41. moparisthebest

    people write the XEPs, anyone can, the XSF discusses+publishes them

  42. moparisthebest

    sometimes code comes before XEPs or after or sometimes never, personally I agree with you, for me code always comes first

  43. MattJ

    "Rough consensus and running code" is the way

  44. me9

    Ok, thanks.

  45. MattJ

    me9: the XSF is a volunteer organization. When a XEP is written there is usually someone with an interest in implementing it, and they are involved in the process (often they are the XEP's author)

  46. me9


  47. phryk

    Where are past presentations hosted? Would be especially interested in talks giving a good high-level overview of the specs and terminology.

  48. me9

    phryk: Do you mean the XMPP Office Hours?

  49. phryk

    For example, but if there's more than just that, I'm happy, too. ;)

  50. phryk

    Ah found XSF's Youtube channel and Sam's talk.

  51. phryk

    4/20 \o/

  52. me9

    > phryk wrote: > Ah found XSF's Youtube channel and Sam's talk. I think Sam made that channel and puts the recorsings on there.

  53. me9

    > phryk wrote: > Ah found XSF's Youtube channel and Sam's talk. I think Sam made that channel and puts the recordings on there.

  54. phryk

    lol grindr is built on xmpp?

  55. Link Mauve


  56. phryk

    and fucking zoom? jeebus. :F

  57. jonas’

    language maybe

  58. Zash

    Yes, maybe keep a civil language

  59. phryk

    I'll try.^^

  60. phryk

    Under protest. :P

  61. jjrh

    Didn't know about zoom, that's pretty nifty :)

  62. phryk

    Is there a recording of the "Towards XMPP 2.0" thing?

  63. phryk

    https://www.youtube.com/watch?v=oc5844dyrsc and this one is going into my future watch list :3

  64. Link Mauve

    phryk, Zoom posted some job offer on https://xmpp.work/ recently.

  65. Link Mauve

    But looking at their docs is enough to know they use XMPP.

  66. phryk

    I never used Zoom and never looked at their docs. :P

  67. phryk

    I even dislike jitsi because goddamnit, just build an A/V MUC thing I can join with a normal XMPP client. :F

  68. Link Mauve

    phryk, that’s exactly what they have done.

  69. jonas’


  70. phryk

    They did?

  71. Link Mauve

    They do.

  72. phryk

    Wait, can I join jitsi meets with conversations, then?

  73. Zash


  74. Link Mauve

    You can join any Jitsi MUC with any other client, yes.

  75. jonas’

    you won't get A/V though

  76. phryk

    Yeah, I meant the A/V part. :P

  77. Link Mauve

    phryk, their main meet.jit.si server only exposes a WebSocket entrypoint, no plain TCP ones.

  78. Link Mauve

    phryk, get any other client to implement multi-party A/V first?

  79. jonas’

    Link Mauve, though nowadays you need to send <nick/> in presence for things to work IIRC

  80. Link Mauve

    jonas’, yes, even back then.

  81. jonas’

    back then™ it was sufficient to send <nick/> in <message/>, not in presence.

  82. Link Mauve

    Or you get weird auto-generated ids instead of your nick.

  83. phryk

    Link Mauve, Conversations doesn't implement multi-party A/V yet? I thought they did…

  84. Link Mauve

    phryk, nope, it doesn’t.

  85. Sam

    I think they're webrtc only now, last time I tried I couldn't connect anymore

  86. phryk


  87. Zash

    It doesn't and Jitsi doesn't want to cooperate

  88. jonas’

    Link Mauve, I know because my bot got away with that, while injecting it into presence was so annoying that I replaced it with a prosody module :D

  89. Link Mauve

    The only clients I know of which implement that are Jitsi Meet, Jitsi, Empathy, and I guess Zoom.

  90. Zash

    Isn't everything "webrtc" these days tho?

  91. jonas’

    Link Mauve, dino is on it though, or so I hear

  92. phryk

    Yeah figures, I guess they also didn't hand in an XEP to specify how multi-party A/V either?

  93. Link Mauve

    Sam, always has been WebRTC, it wouldn’t do audio/video in a browser otherwise.

  94. jonas’

    and Conversations is interested to follow suit

  95. jonas’

    phryk, they are based on XEPs which specify multi-party A/V :)

  96. Sam

    Link Mauve: the signaling is webrtc now too, I mean

  97. Link Mauve

    Note that Conversations, Movim, Dino and whatnot are also WebRTC, with Dino being the only one not WebRTC only.

  98. jonas’

    those haven't been kept up to date though :(

  99. Link Mauve

    Sam, WebRTC doesn’t do signaling though.

  100. Link Mauve

    It leaves that out to the client.

  101. phryk

    jonas’, care to throw me the XEP numbers? :)

  102. Sam

    It does whatever you send over it.

  103. jonas’

    phryk, check the list for COLIBRI

  104. jonas’

    Sam, you need something to exchange the SDPs over though, before you can even exchange peer-to-peer data

  105. Link Mauve

    phryk, XEP-0298, XEP-0340 are the main ones.

  106. jonas’

    right, Coin and COLIBRI

  107. Sam

    I couldn't see a websocket connection last time I tried anyways, I could see IQs in a webrtc error message.

  108. jonas’

    (make sure to enable Deferred ones in the view)

  109. Zash

    What was "WebRTC" even? Some profile of codecs and stuff? RTP over UDP over DTLS over HTTP over SCTP over DTLS over ...???

  110. phryk

    Dino just uses rtp directly?

  111. Link Mauve

    Sam, in any given room, press F12, go to the network tab, and look for the wss://meet.jit.si/xmpp-websocket?room=yourroom connection, it has HTTP status 101.

  112. Link Mauve

    Then in the Response tab you can see the WebSocket exchanges.

  113. Link Mauve

    (In Firefox, I don’t know how it is in other browsers.)

  114. Link Mauve

    phryk, yes, or with DTLS-SRTP to negociate the encryption, which is basically what WebRTC is.

  115. Link Mauve

    Plus a bunch of other extensions made mandatory.

  116. phryk


  117. phryk

    Now, I think, I'll finally go read that mod_e2e_policy code. :3

  118. Zash

    MattJ, others interested in E2EE might be interested in an e2ee ietf mailinglist: https://mailarchive.ietf.org/arch/msg/ietf-announce/JD82eEVcnGOYCYCcIjRDwiZlB6Q

  119. southerntofu

    Link Mauve, can you actually join meet.jit.si with any other client? i thought they disabled s2s?

  120. phryk

    southerntofu, sounds like you can join chats if your client supports xmpp over websocket.

  121. phryk

    so, i assume that basically means conversejs and nothing else?^^

  122. southerntofu

    idk phryk i dug through my browser console to find the muc address and tried to join, but it failed

  123. Link Mauve

    southerntofu, yes you can, configure your client to use this WebSocket endpoint, and then join the MUC you want.

  124. southerntofu

    ok strange, thanks

  125. Link Mauve

    Most desktop clients don’t support WebSocket though, so use something like Gajim, Converse.js or such.

  126. Link Mauve

    I have successfully used Gajim.

  127. phryk

    Sounds like Gajim is the best client for debugging XMPP stuff…

  128. southerntofu

    good to know! like we were talking in some other chan, i'd find it great to have better desktop/mobile clients for Jitsi Meet

  129. moparisthebest

    <open xmlns="urn:ietf:params:xml:ns:xmpp-framing" is WebSocket C2S, anyone have opinions on what S2S should look like? unless I hear complaints I'm going with xmlns="urn:ietf:params:xml:ns:xmpp-framing-server"

  130. vanitasvitae

    Zash, created on 27.07? Coincidence? :O

  131. moparisthebest

    southerntofu, phryk I'm close to releasing a tool that'll let any normal-xmpp-speaking client connect over WebSockets FYI

  132. southerntofu

    a MUC<->websocketMUC gateway?

  133. phryk


  134. vanitasvitae


  135. Zash

    moparisthebest: The framing that is only really needed with clients that are limited to DOM entire-document parsers? Why would you ever keep that? Why do we still have it for c2s???

  136. moparisthebest

    a TCP-XMPP -> websocket-xmpp proxy

  137. moparisthebest

    Zash, yea, wouldn't *need* the framing I guess, on the other hand why not

  138. Link Mauve

    phryk, I usually use poezio, but it’s a matter of preferences really.

  139. Link Mauve

    It doesn’t support WebSocket though, nor WebRTC.

  140. phryk

    My preference UI wise is dino, tho I'd like it to be a bit mor explicit and offer more things on context…

  141. phryk

    Might actually end up writing my own client, but that's one of those potential projects like me writing my own wayland composer or webframework. :P

  142. Link Mauve

    phryk, why not contribute to Dino?

  143. phryk

    I mean I am doing the latter, but I started in 2011-2012 and it's been in it's third iteration since 2015 and still isn't even at alpha^^

  144. phryk

    Link Mauve, because the devs made it clear they don't see eye to eye with me concerning UX.

  145. moparisthebest


  146. phryk

    No way.

  147. moparisthebest

    why? certainly nicer than totally starting from scratch when you are 90% of the way there

  148. phryk

    No, and a whole bunch of reasons.

  149. phryk

    For one, I'm not gonna learn yet another language just to fork a thing when I'm already currently learning D for that wayland compositor, have to get back into Perl for a job and am about to embark on learning Lua.

  150. phryk

    Learning 3 languages in parallel is enough for me, thank you very much.

  151. phryk

    Also, because time and time again I've found that using other peoples codebases for complex stuff turns out to be a complete cl*****f*** when trying to bend it to my needs.

  152. phryk

    For example in my webframework I tried using pandas (python data analysis module) for over a year and everything was pain and suffering for that time.

  153. phryk

    When I decided to just throw the damn thing out, I was at feature parity with my old stuff in about a month and a week later had more features than before, the thing worked more generally and the serialization was more reliable while not changing its interface at all.

  154. phryk

    When I decided to just throw the damn thing out, I was at feature parity with my old stuff in about a month and a week later had more features than before, the thing worked more generically and the serialization was more reliable while not changing its interface at all.

  155. moparisthebest

    other people's code is terrible, your code is terrible, welcome to programming

  156. phryk

    Nah, it's not only that.

  157. moparisthebest

    programmers like rewriting things :) https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

  158. phryk

    *Some* other peoples code is great, amazing even. I've only ever once had a problem with flask for example when it was relatively fresh, dumped my concerns into IRC and forgot about it – only to come back to it a couple months later and found that all my issues had been fixed in ways that were better than what i proposed.

  159. southerntofu

    and some other people's code is garbage, like ansible which has over 1000 papercuts/m² which are very counter-intuitive

  160. phryk

    And XMPP implementations are one of those things where I'd be *extremely* cautious. Been playing with the tought of implementing it myself, but then it's not a medium-sized domain-specific project anymore, but a multi-year one.^^

  161. phryk

    The concept for an XMPP messenger I came up with some time last year was using python + kivy so I can do responsive design from the ground up and do desktop + android + iOS (+ pinephone or whatever) – basically one client to rule them all. :P

  162. phryk

    But honestly, I'd like it to be compiled, so currently I'd be leaning more towards D, but then I don't know of any compatible GUI toolkit being constructed with responsive design methodology built-in…

  163. phryk

    Plus, I'd still lose the whole "support for any and all platforms" thing…

  164. southerntofu

    phryk, sounds a lot like libervia.org (except python)

  165. phryk

    Isn't that just an online service, not a client?

  166. southerntofu

    phryk, it's a client with different frontends: gtk, web, cli, tui, android...

  167. phryk

    oh, like mplayer but for XMPP? :D

  168. southerntofu

    something like that :P

  169. phryk

    good approach, I'd say. but I want just one frontend that' responsive.

  170. southerntofu

    also you may be interested in some rust GUI frameworks which support web platform, like https://github.com/hecrj/iced

  171. southerntofu

    or keep an eye on WASI project to reuse web technologies everywhere (except JS of course)

  172. phryk

    No, no, aand no. ^^

  173. phryk

    And definitely no electron or anything like that.

  174. southerntofu

    it's not EXACTLY "anything like that" but it's the same spirit yes

  175. phryk

    Don't get me wrong, I've been doing web development for some 15 odd years now and I love what the web enables, but I hate how the web is used to replace anything native.

  176. southerntofu

    https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/ <--- not exactly sure it's the best but if web platform is on your list, then it may be the most appropriate

  177. phryk

    My webframework has a strict policy about no client-side scripting and no third-party requests. enforced by CSP in its core so you'd have to fork the damn thing to use that stuff. :F

  178. southerntofu

    phryk, i also hate it, but with a proper desktop/system integration, lightweight runtime, and distribution on proper package systems (appimage/guix/flatpak) i think i could actually like it

  179. southerntofu

    phryk, i really like what i hear, do you have a link? is everything handled via <form>s?

  180. phryk

    No, web platform is absolutely not on my list. I'll begrudgingly deploy converse on the XMPP service I'm currently building, but only for onboarding and fallback.

  181. Link Mauve

    phryk, libervia already has a Kivy frontend named Cagou.

  182. southerntofu

    ah sorry i thought "web" was in the "one client to rules them all" :D :D

  183. Link Mauve

    You may also be interested in Kaidan, doing the same but with Kirigami.

  184. phryk

    Yes, I have an integrated custom form system that also allows building complex, stateful applications powered by encrypted server-side sessions out of webforms.

  185. Link Mauve

    So far I’m not impressed on desktop, but maybe with more workforce they could become good.

  186. phryk

    Kirigami doesn't ring a bell. I wanted to try Kaidan on my system, but it only ever segfaulted – I thought it was KDE?

  187. moparisthebest

    sounds useless for e2e chat though right?

  188. Link Mauve

    phryk, it’s one of the KDE frameworks, targetting mobile too.

  189. phryk

    So KDE developed a desktop<->mobile portable GUI framework independently from Qt?

  190. southerntofu

    phryk, also libervia project could use some help, it's pretty cool and the maintainer has an interesting vision from what i could chat with

  191. moparisthebest

    server-side anything without client-side scripting is useless for e2e chat I mean

  192. Link Mauve

    phryk, I don’t think it’s independent on it, probably building on top of it.

  193. phryk

    southerntofu, https://rnd.phryk.net/phryk-evil-mad-sciences-llc/poobrains/ <- the framework

  194. Link Mauve

    I haven’t looked much into it, so I can’t help you more with that.

  195. southerntofu

    moparisthebest, it's not useless, you can build encryption by making your own user agent for those HTTP requests :)

  196. phryk

    Mhh, Qt is complicated because I don't know if we can depend on it to stay open/maintained or if it'll diverge from the commercial one.

  197. southerntofu

    encryption in the browser is the worst idea already

  198. Ellenor Malik


  199. phryk

    X.509 is the worst idea already. :P

  200. moparisthebest

    sure, but at least you can do it in a real language with webasm

  201. phryk

    Worst. Spec. Ever.

  202. southerntofu

    moparisthebest, not all browsers support that, we're already trying to remove JS, without adding an even bigger attack surface :P :P

  203. southerntofu

    for me WASM is only useful for cross-platform applications, not on the actual WWW

  204. southerntofu

    it brings the good stuff of the web (HTML+CSS) on the desktop via WASI, and we can keep client-side scripting outside of the browser :)

  205. southerntofu

    (because of fingerprinting, sandbox escapes, rowhammer-style attacks..)

  206. Link Mauve

    phryk, Libervia’s Cagou is built on Python + Kivy, have a look at it, the room is at xmpp:sat@chat.jabberfr.org?join fyi.

  207. Link Mauve

    southerntofu, how is wasm a bigger attack surface than JS?

  208. Zash

    X.509 is great because it caused this to be written: https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

  209. Link Mauve

    It also brings neither HTML nor CSS into wasi.

  210. southerntofu

    Link Mauve, doesn't have to be bigger (in fact can be smaller) but it's bigger than no client-side scripting at all

  211. southerntofu

    Link Mauve, no but WASI + a desktop browser engine allows good cross-platform web-based UI, that's what i meant

  212. Link Mauve

    How is that different from a browser?

  213. phryk

    Zash, It also caused this to be written: https://phryk.net/article/zomgwtftls/ :P

  214. phryk

    (CW: language)

  215. southerntofu

    Link Mauve, it doesn't run random code from the internet to just display stuff

  216. southerntofu

    it runs an application you downloaded and vetted, hopefully through trustworthy chanels

  217. Link Mauve

    southerntofu, I mean, a browser engine + a wasm interpreter which has access to local stuff (wasi) is worse than a browser engine + a wasm interpreter which is restricted to HTTP resources to me.

  218. Link Mauve

    The former is pretty much electron.

  219. Link Mauve

    The latter, any standard browser.

  220. southerntofu

    oO? you'd rather run random code from the internet?

  221. Link Mauve

    I’d rather have a sandbox than none.

  222. Link Mauve

    Which is why I do use the web, and why I don’t use electron.

  223. southerntofu

    well sure you can sandbox stuff, but in my view that'd be the role of firejail/flatpak/chroot not the role of the runtime itself

  224. southerntofu

    also browser sandboxes are a joke, people keep on poking holes through all the time

  225. phryk

    > X.509 - the PDF of IT Security <- I'm still *extremely* proud of that heading. :P

  226. southerntofu

    personally i'd much rather run code packaged by my distro without a sandbox, than sandboxed code fro mthe internet

  227. Link Mauve

    Well, good for you I guess.

  228. southerntofu

    sure. i mean how much malware distributed through debian? vs how much malware due to browser vulns?

  229. phryk

    southerntofu, full ACK on that. I especially hate the implications of client-side scripting code delivered by servers being able to be different for every request. theoretically you can target by demographics or users to only *sometimes* deploy malicious code making any audit basically meaningless.

  230. southerntofu

    phryk, exactly! plus i recently learnt about rowhammer.js and i was like "wow is this what we have come to?"

  231. phryk

    When I install packages from the distro package repo (or my own one), I have strong cryptographic assurance that it hasn't been tampered with between compilation and delivery.

  232. Zash

    Computers bad. Grow potatoes. 🤷️

  233. phryk

    Heh, yeah, I still remember that ASLR-defeating exploit that worked over javascript.

  234. phryk

    Exactly, run GNU Hurd and bury thyself!

  235. phryk

    he said, running FreeBSD and being very unGNU… ^^

  236. southerntofu

    don't forget your GNU/shovel to resolve (`dig`) where this whole is taking you :) :)

  237. phryk

    I often say we should have abolished UNIX and all used Lisp machines, only half-jokingly. :P

  238. southerntofu

    well that is an interesting paradigm! but i'm afraid we're growing offtopic here :D

  239. phryk

    Aye, was thinking the same thing.

  240. phryk

    To get a bit more on-topic: Is the server domain alone a valid (but somehow special) JID? If so, where is that definedD?

  241. phryk

    To get a bit more on-topic: Is the server domain alone a valid (but somehow special) JID? If so, where is that defined?

  242. moparisthebest

    All browsers support wasm, and I'd rather they only support wasm and not js

  243. Zash

    Yes, a bare hostname is a valid JID. XMPP-Core and/or XMPP-Addr

  244. phryk


  245. Zash

    https://xmpp.org/rfcs/rfc6120.html#rfc.section.2.1 and https://xmpp.org/rfcs/rfc6122.html