XSF Discussion - 2019-02-04

  1. pep.

    I would assume conversations had to go through the same hassle? Also Signal

  2. moparisthebest

    Wow I was joking about overthrowing the French govt earlier but maybe it's time

  3. moparisthebest

    Is there a way to check whether the eventually released French binaries are the same as in other countries?

  4. pep.

    I'm now wondering how it works with Linux distributions even.

  5. moparisthebest

    Looks like only apple requires it

  6. moparisthebest

    Like maybe everyone else should ask the French Kings permission too but just doesn't

  7. lovetox

    They can only enforce it if you go over some software store

  8. lovetox

    Thats the downside if most people only get software through a software store like apple or google store

  9. pep.

    What about distribution repositories

  10. pep.

    (Not that I want any of this bs there, just curious)

  11. lovetox

    pep. repositorys are like http servers, i think its too much work for a government or an agency to monitor all possible repositorys

  12. lovetox

    its easy to make one big company follow some rules

  13. lovetox

    because the company wants to make money in this country

  14. debacle

    Marketing issue: Because we all love the wonderful orange hoodies sold at the summit, we talked about having an "inofficial XMPP brand colour", which more or less matches the hoodies. The XMPP logo has two tones of orange: https://www.color-hex.com/color/e96d1f and https://www.color-hex.com/color/d9541e

  15. debacle

    The former looks more "aggressive" to me than the latter. I'ld prefer that, but as most software developers, I'm not good when it comes to design and marketing stuff.

  16. goffi

    debacle: I guess this is something for the board, maybe it should be added to agenda?

  17. debacle

    goffi, after that you need to change the colour of your SàT starfish :)

  18. Ge0rG

    I'd like to have a Jabber hoodie.

  19. jonas’

    talk to cisco about that

  20. Guus

    Ge0rG I think ralphm took them home, so you might be able to have him ship one to you.

  21. pep.

    Guus, I think that was just a taunt :)

  22. debacle

    Jabber is only trademarked for computing and communication, right? You can have a Jabber washing powder or Jabber fashion products.

  23. ralphm

    I have all the hoodies here, as well as the XSF flag that Guus has had made.

  24. Ge0rG

    No, I'm actually interested in having a Jabber hoodie.

  25. moparisthebest

    print one?

  26. Guus

    (There's another flag with Daniel, btw)

  27. Ge0rG

    🤔 can do. Will I violate trademarks?

  28. ralphm

    XMPP is not a trademark, as it was "invented" especially for the purpose of not being one, so that it could be used as the name of a set of protocols with the IETF.

  29. ralphm

    And Jabber logo is officially owned by the XSF.

  30. moparisthebest

    who cares Ge0rG , XSF is :P

  31. moparisthebest

    there is still 0 paperwork showing XSF has the right to do anything with jabber

  32. ralphm

    (I.e. the bulb used for the JSF logo, not to be confused with the bulb Jabber, Inc. used)

  33. moparisthebest

    there is paperwork saying they had rights up until June of 2001 or something, but nothing saying it was extended

  34. ralphm

    moparisthebest: ok great, and now?

  35. moparisthebest

    find the paperwork or forget about it, in my opinion

  36. moparisthebest

    long live XMPP, jabber can go die in a fire

  37. ralphm

    That's one viewpoint, sure.

  38. moparisthebest

    how can a company rely on a grant of use of jabber from the XSF when nothing says the XSF has that right?

  39. pep.

    I'd like to cut ties with Cisco at some point as well

  40. moparisthebest

    also, assuming the old expired agreements were extended and still in effect, a company STILL can't rely on it because the XSF has like 30 days to take legal action against trademark abuses, and the XSF doesn't have resources for that?

  41. moparisthebest

    but we don't even get that far, because there is no such paperwork, is there?

  42. moparisthebest

    wasn't last time I asked...

  43. Ge0rG

    moparisthebest: AFAIU, stpeter has the paperwork

  44. moparisthebest

    that doesn't sound like a legal defense for a company sued by cisco for using jabber

  45. jonas’

    Ge0rG, do you want to get https://github.com/xsf/xeps/pull/739 merged now or do you want to modify it?

  46. jonas’

    moparisthebest, AFAIK, stpeter has always taken some type of action when trademark violations have been reported.

  47. jonas’

    (having reported one or another myself)

  48. Ge0rG

    jonas’: I've written another mail to standards@ regarding the still open points wrt. error conditions. Would be nice to get some feedback for that first.

  49. jonas’


  50. jonas’

    because I just replied to the one from tuesday

  51. Ge0rG

    oh, I didn't read my private mail yet.

  52. jonas’

    what I forgot to write regarding your second point (clearly defining the error condition for "not in room"): we can have '410 advance and adapt it according to changes in '45 later, IMO

  53. Ge0rG

    jonas’: Warning: The key used to create the signature expired at: Tue 12 Jul 2016 09:13:45 PM CEST

  54. jonas’

    Ge0rG, gpg2 --refresh-keys

  55. Ge0rG

    why doesn't it do that automagically?

  56. jonas’

    because privacy

  57. Ge0rG

    jonas’: if I understand your remark here right, there is no need to add those things into 0410 now?

  58. jonas’

    I think the former <not-in-room/> should be added to '410 right now

  59. jonas’

    (and then backported to '45)

  60. jonas’

    the latter (general not-in-room condition, i.e. not-acceptable vs. whatever) should be in '45, and does not need to be added to '410 right now

  61. jonas’

    (former and latter refering to the order of the points made in your original email)

  62. Ge0rG

    But my former proposal uses the MUC namespace, for which I'm not an authority

  63. jonas’

    that’s kinda true

  64. jonas’

    I’d try it and see if it passes by council? :>

  65. jonas’

    I mean you’re also using identifiers from the muc prefix for disco#info, aren’t you?

  66. Ge0rG

    That's a very subversive approach

  67. jonas’

    (while obviously pointing council at it to not make it appear like you tried to smuglge something, obviously)

  68. Ge0rG

    Yeah, right! 😂

  69. Ge0rG

    jonas’: my laptop is still busy thrashing, so I can't do any meaningful work right now.

  70. jonas’


  71. Ge0rG

    Can we merge the existing changes first, and then have a separate pr for the new condition? That surely would make a better proposition for two council votes.

  72. jonas’

    I am fine with that

  73. jonas’

    (fwiw, I’m asking because I’m on a merge spree)

  74. Ge0rG

    jonas’: engage the merge button!

  75. jonas’

    so I’ll just merge it now!

  76. jonas’

    it will take approx. 3h to appear on the website because there doesn’t seem a way to cancel builds in the new docker hub interface

  77. Ge0rG

    It also looks like my OOM condition is nearing its end, after I somehow managed to store a 6.5GB session file into 2GB of free disk space, and can see the "quit" button of this application already

  78. lovetox

    hm jonas’ the xor xep is not on the server

  79. jonas’

    ah, the email template is still lacking the "due to unrelated automated processes yada yada will appear soon"

  80. jonas’

    (i.e.: I forgot to push that one before sending out the email)

  81. jonas’

    look again in an hour

  82. jonas’

    docker build takes ages

  83. lovetox

    k thanks

  84. jonas’

    Ge0rG, gentle reminder about your on-list-ing of https://github.com/xsf/xeps/pull/743

  85. Ge0rG

    jonas’: I still think that the warning text isn't sufficiently bold and red and blinking

  86. jonas’

    Ge0rG, maybe state that on-list then, with an official -1, so we can get the vote over with.

  87. Ge0rG

    jonas’: but thanks for the reminder. I'll send a mail to the list tomorrow

  88. jonas’


  89. jonas’

    thank you very much

  90. jonas’


  91. jonas’

  92. pep.

    jonas’, the new inbox stuff is not yet ready?

  93. jonas’

    what new inbox stuff?

  94. pep.

    I get 404 for XOR

  95. jonas’


  96. pep.


  97. jonas’

    see above

  98. pep.


  99. jonas’

    should be there in 15min or so

  100. pep.


  101. jonas’

    one day I’ll silently replace the nginx stuff with a reverse-proxy to a host of mine where I can do incremental builds :-X

  102. flow

    Or we ditch docker, and design the tool so that it takes the xeps repo as input and a directory for the html as output, and simply let a web server serve that directory to the world

  103. jonas’

    flow, iteam does not want to execute uncontainerised code on the server.

  104. jonas’

    flow, there is already the makefile which does essentially that

  105. flow

    jonas’, I know, but I don't really think that this is a good decission

  106. flow

    For the wiki, maybe

  107. flow

    But not for the editor tooling

  108. jonas’

    I can see why they made that decision, and I’m not the one to overturn that.

  109. jonas’

    I will complain once in a while about the 1h build times, because those are annoying big time

  110. Ge0rG

    Can't we have a docker image that contains all the tools? Or do we already, and it's the XEP build that takes so long?

  111. flow

    jonas’, you are the one with the most "leidensdruck" regarding that, I decided to that I don't want to get invovled with a process which I believe to be fundamentally wrong

  112. Zash

    Should be doable to not do it from scratch every time?

  113. jonas’

    everything which invovles not doing everything from scratch all the time requires to move away from docker hup

  114. jonas’

    everything which invovles not doing everything from scratch all the time requires to move the build of the xeps away from docker hub

  115. jonas’

    and that requires a machine which can do the builds

  116. jonas’


  117. flow

    Ge0rG, why does it have to be docker? as far as I can tell, most tools is simply python. I am not sure about external dependencies, but I've been told there are other solutions for that besides docker

  118. jonas’

    flow, there is one crucial tool

  119. jonas’

    the toolchain which builds the PDFs

  120. jonas’

    this is terrible to set up

  121. jonas’

    it involves some chain of XSL, some tooling called texml I think, and latex to generate the PDFs

  122. jonas’

    parts of wihch are unpackaged, I think

  123. flow

    jonas’, true, and PDFs are nice, but that could be done in docker. How many times have people asked you why a PDF is 404, vs the HTML?

  124. jonas’

    I can totally see why you wouldn’t run that automatedly on any server, even if only because of the CPU load caused by a mass rebuild

  125. pep.

    flow, as a sysadmin I really understand the need for some form of container. This way iteam doesn't have to know what's going on to deploy the app, editors can do whatever they want in it

  126. jonas’

    even if one split the build into HTML (on the server itself) and PDF (on dockerhub or whatever), there needs to be a way to trigger a build from github on the server, which is another thing iteam doesn’t want

  127. flow

    pep., I think "just depend on stuff that is in debian stable" could be a feasible policy in this case

  128. jonas’

    (also completely understandable)

  129. flow

    no need to dockerize

  130. jonas’

    (I’m still scared of the webhook-website-build-thing I made for another org)

  131. pep.

    flow, some kind of isolation might also be desirable. If they ever want to run something unrelated to editorial things

  132. jonas’

    flow, to do this totally safely, one would have to split the build tools out in a separate repository; makefile is executable code, you don’t want to have that updated automatedly on the server

  133. flow

    jonas’, splitting tooling and xeps was actually what I also suggested back then

  134. jonas’

    makes it more annoying to use by the editor, too

  135. flow

    pep., true, but there are also solutions for that that

  136. jonas’

    I can also see why iteam wouldn’t want to maintain the code execution on the server, given that they’re all very busy folks.

  137. jonas’

    I wonder whether there’s something with nginx where you can ask multiple sources for a URL. like, "try local file first, if that’s not found, try this reverse-proxied service, if that’s not found, return not found"

  138. pep.

    try_files ?

  139. pep.


  140. jonas’

    doesn’t seem to me that could use a reverse-proxied service as fallback

  141. pep.

    location / { try_files /system/maintenance.html $uri $uri/index.html $uri.html @mongrel; } location @mongrel { proxy_pass http://mongrel; }

  142. jonas’


  143. jonas’

    that makes sense then

  144. jonas’

    that could allow editors to host builds which are taken until the docker build has passed

  145. jonas’

    that could allow editors to host builds which are served until the docker build has passed

  146. flow

    I mean ideally editors would run the tooling locally and just sync with a remote directory that is served over http(s)

  147. jonas’

    for certain definitions of "sync"

  148. mathieui

    I see the appeal into relying on the repository build and not on people syncing files on the server

  149. flow

    mathieui, does it really make a big difference between triggering the docker build vs running the tool localy? Besides the later being finished way earlier than the docker build?

  150. jonas’

    flow, yes, the docker build always yields a consistent result

  151. jonas’

    when multiple people do editor work and everyone syncs parts of their builds up to a server ... that’s meh

  152. jonas’

    mix into that local, uncommitted changes and it’s getting messy quick

  153. Zash

    Horrible hack: Download existing files (only really need the timestamps) so the thing believes it already built the things it already built

  154. flow

    jonas’, one sure could design the tool so that this shouldn't become a real world issue, i'd say

  155. jonas’

    Zash, oh my god

  156. mathieui

    Zash, I like it

  157. flow

    hackidy hack hack

  158. jonas’

    flow, not really, unless you let the tool run `git checkout . ; git clean -f`, which no automated tool should run ever.

  159. flow

    jonas’, depends, if this is a repo in a shadow directory…

  160. jonas’


  161. flow

    but yeah, people have different opinions and experiences about "how to do it right"

  162. jonas’

    too dangerous to write those lines in any tool, ever

  163. flow

    back to bug hunting

  164. Zash

    This feels like https://xkcd.com/2044/

  165. pep.

    Sometimes I wonder how much time you spend on xkcd Zash

  166. jonas’

    he just has a good memory because he doesn’t keep logs and thus has to rely on his brain, in contrast to all of us :(

  167. Zash

    Logs wasn't a thing when I grew up

  168. pep.

    I just don't want to clutter my memory with logs, and logs are mostly free :p

  169. Zash

    I also never learned to take notes in school.

  170. jonas’


  171. pep.

    I'm also really bad at that

  172. Neustradamus

    It is possible to do an update of https://xmpp.org/2019/01/the-xmpp-newsletter-31-january-2018/ ?

  173. jonas’


  174. jonas’

    what’s missing?

  175. pep.

    If it's about the url, that was discussed on the commteam channel iirc

  176. Neustradamus


  177. jonas’

    the URL cannot be changed anymore

  178. jonas’

    it is linked to from various sources

  179. jonas’

    Neustradamus, see also https://github.com/xsf/xmpp.org/commit/2c9f80b5bd3301f2bab5a18300146dce7b075c9d https://github.com/xsf/xmpp.org/commit/7862fd7c71a531e8875a0731779554b3e896aedd https://github.com/xsf/xmpp.org/commit/7fd06dc8f805776540add7ed0819861ef3d5b783

  180. pep.

    jonas’, in hugo there's an "aliases" directives

  181. jonas’

    I had lots of fun

  182. jonas’

    pep., hm, aliases

  183. jonas’

    I was thinking ln -s in the docker build :-X

  184. Neustradamus

    But redirection/alias...

  185. pep.

    That creates a stub with <meta/>

  186. jonas’

    pelican does not seem to have any alias functionality

  187. Neustradamus

    Posted by "Seve, jcbrand" -> https://xmpp.org/author/seve-jcbrand.html strange page too

  188. jonas’

    or redirects

  189. pep.

    Maybe we can just create the page manually

  190. jonas’

    pep., sounds like a plan, go ahead

  191. pep.

    <meta http-equiv="refresh" content="0; https://foo.bar/2019-1234" />

  192. pep.


  193. Zash


  194. Zash

    So many hacks

  195. pep.

    of course.

  196. pep.

    Compat compat compat

  197. pep.

    jonas’, hmm, how do I create a static page? Do I create a .md with html in it directly? :/

  198. jonas’

    look at how the homepage is created, essentially

  199. jonas’

    it’ll be messed with by templates though

  200. jonas’

    so you probably have to create your own template for that page

  201. jonas’

    I think it might be easier to simply hack the symlink creation somewhere into the build process.

  202. pep.


  203. pep.

    It's not a symlink that we want, do we. It's a redirect

  204. pep.

    So either <meta/>, either nginx

  205. jonas’

    yes, a proper redirect needs to be done by a webserver

  206. pep.

    I feel meta is better though

  207. jonas’

    meta is never better

  208. pep.

    Well.. that's an application issue

  209. Zash

    Also having they date in the slug seems redundant since it's in the path too

  210. pep.

    hah, true

  211. Zash

    (this is where someone says it's required because of reasons)

  212. jonas’

    it isn’t, I think

  213. pep.

    https://github.com/Nitron/pelican-alias hmm.

  214. pep.

    How do you feel about having one moar plugin

  215. Neustradamus

    On https://xmpp.org/extensions/inbox/xor.html No new draft information: https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid And 2 mistakes about -> "Jabber" network It is the XMPP network

  216. Zash

    Re XEP-0335, https://tools.ietf.org/html/rfc7493 might be worth looking at (ping MattJ)