XSF Discussion - 2021-08-02

  1. wurstsalat

    Hi all! Following last week's discussion around xmpp.org's site generator and its current state, I went ahead and built something. Since many problems are related to the currently used theme (compiling sass, difficult upgrade), I aimed for something simpler and easier to maintain. As Pelican needs an update as well, this would most likely involve further theme and template changes. Because of this, I went with Hugo instead. So here's what I did: switched to Hugo; created a theme which almost looks like xmpp.org, but is based on Bootstrap 5 (it's well documented); added a simple user CSS; migrated templates, e.g. processing of members.json, clients.json, xeplist; updated Makefile, Dockerfile, and MakefileDocker. The readme should be up to date. Using either `hugo server` or `make -f MakefileDocker serve` works. Tested with hugo 0.54 and 0.86. https://github.com/wurstsalat3000/xmpp.org-hugo This is almost on-par with the current xmpp.org (some meta data still needs to be adjusted), and I'm happy to put in further work.

  2. emus

    wurstsalat: Great work! Thanks

  3. emus

    wurstsalat: do you have a rendered version, too?

  4. wurstsalat


  5. Zash

    Looks good

  6. wurstsalat

    menu issues while resizing are gone as well :)

  7. Ge0rG

    wurstsalat: it looks awesome. Did you also check the blog URLs and the RSS for consistency with the old version?

  8. wurstsalat

    Ge0rG, they don't match yet, but that's a matter of configuration

  9. Ge0rG


  10. emus


  11. emus

    jcbrand, Seve: ^

  12. Seve

    That is so awesome wurstsalat !! We definitely need this, what a great job!

  13. moparisthebest

    wurstsalat: excellent work!

  14. edhelas

    looks good :)

  15. moparisthebest

    re: POSH > As an example, the well-known URI for the hypothetical SPICE application might be "spice". funny that the SPICE protocol became real about 2 years later hehe

  16. moparisthebest

    does anyone implement POSH *and* XEP-0368 in the wild? and if so, do you request /.well-known/posh/xmpp-client.json or /.well-known/posh/xmpps-client.json or both? in hindsight XEP-0368 should explicitly mention the right thing (which, I suppose should be "just use xmpp-client.json"

  17. moparisthebest

    or server of course, point being xmpp- not xmpps- is likely correct

  18. Zash

    I'm not sure if POSH is that great at fulfilling its purpose today. The way it has a hash of the cert means it's much easier to point at a unlimited-lifetime self-signed cert than some name-mismatched Let's Encrypt cert.

  19. Zash

    A simplified variant where you just serve the name to expect might be better today.

  20. moparisthebest

    not wrong

  21. jonas’

    ITYM DNSSEC on your SRV records?

  22. Zash


  23. moparisthebest


  24. Zash


  25. moparisthebest

    but I'm not having any luck getting people to abandon their .im :P

  26. Zash

    Now since only something HTTPS-based has any chance of getting anywhere, can we at least transport DNSSEC signatures over DoH?

  27. moparisthebest

    that already works

  28. Zash

    Obviously not, that would have been a nice thing. Can't have nice things.

  29. moparisthebest

    it just transports raw DNS packets in UDP form, RRSIG etc travels over it just fine

  30. Zash

    Lies! It's JSON, I've seen it!

  31. Zash


  32. Zash

    (I know, that's some Cloudflare alternative format?)

  33. moparisthebest

    google had an old format like that

  34. Zash


  35. moparisthebest


  36. Zash

    Next you'll probably try to tell met that clients actually check the DNSSEC

  37. moparisthebest

    >_> depends on the client? <_<

  38. moparisthebest

    2 more POSH questions: 1. what about HTTP redirects? 2. with JSON-level redirects, I see no reason there couldn't be infinite layers of these like HTTP redirects, but it says: > If the source domain returns a reference, the POSH client MUST use the lower of the two "expires" values when determining how long to cache results which implies exactly 2...

  39. moparisthebest

    well, one redirect to something that is not a redirect I guess

  40. wurstsalat

    à propos redirect: Ge0rG, I updated the blog structure and it now follows current xmpp.org's blog urls. I also put redirects in place where necessary. I guess that's it for now, waiting for feedback :) https://github.com/wurstsalat3000/xmpp.org-hugo

  41. jonas’

    what do the folks with hugo-experience have to say about this? cc @ Zash ^

  42. Zash

    Doomed to break in some Hugo update! DOOMED!

  43. wurstsalat

    Zash, for now it works with hugo ~0.50 (docker debian) and ~0.80 (arch). I didn't notice anything breaking on gajim.org, where we also use different versions. but that depends on the templates in use :)

  44. MattJ

    I hadn't seen any discussion on migrating away from pelican, so this caught me by surprise. But thanks for the work!

  45. MattJ

    I have to say I personally would much prefer the site being based on hugo

  46. MattJ

    and bootstrap

  47. MattJ

    Selfishly because these are both things I use for many other sites already... :)

  48. MattJ

    I haven't had time to figure out yet another site generator, which has held me back from doing various website tasks

  49. MattJ

    Is the data-driven stuff ported also? The software lists for example. And will this affect Link Mauve's DOAP work in any way?

  50. wurstsalat

    MattJ, yes, I ported all of them (afaik)

  51. wurstsalat

    my guess is that it's easier to integrate now

  52. MattJ

    Excellent news :)

  53. wurstsalat

    I initially wanted to try integrating Link Mauve's work, but somehow ended up with what I got now

  54. MattJ

    Very exciting

  55. jonas’

    I don't have strong opinions w.r.t. pelican vs. hugo in this case, and anything which gets us away from the unmaintainable mess there would be great.

  56. jonas’

    I can't judge this specific implementation though.

  57. Sam

    I haven't looked at this theme, but I also do everything in Hugo and recommend it. It is impossible to learn because of terrible docs, will break with every upgrade in mostly minor/silent ways, and is generally incredibly buggy, but it's better than everything else I've tried.

  58. Sam

    And certainly better than an ancient version of Pelican that no one knows how to upgrade.

  59. Zash

    Also FAST!

  60. Sam

    This is the main reason I use it ⤴️

  61. wurstsalat

    Hugo's docs are pretty helpful though

  62. moparisthebest

    I use Hugo and zola in different places, Hugo has much bigger use+community though, my opinion is go for it, with massive thanks to wurstsalat for putting in the hard work (and volunteering to maintain it forever more right? muhuhahaha)

  63. Sam

    In my experience it's impossible to find any useful information in hugo's docs. They're long, but hard to search and half the time don't describe anything useful (if you're building themes anyways), but YMMV

  64. Zash

    I wasn't aware Hugo had docs at all

  65. wurstsalat

    well, I just built a theme with them :)

  66. Zash

    Keeping the existing vcs history would be good tho

  67. Sam

    Archive the repo, rename it to xmpp.org-pelican or something, and start a new one.

  68. Zash


  69. Sam

    Because they're entirely unrelated histories and it would be pointless to download all the pelican stuff every time for no reason.

  70. Zash

    I don't care about Pelican, but the history of the *content* should be kept.

  71. Sam

    It will be, in a separate repo. If for some reason we are ever of interest to internet archaeologists it will just require a minor skip over to another repo to see if it looks the same.

  72. Zash

    Hello, I'm an Internet Archaeologist with an ITeam hat. I say keep the history!

  73. wurstsalat

    content resides in the same folder even

  74. Ellenor Malik

    moparisthebest: DoX when?

  75. Zash

    I would not be happy trying to find out who and why some wording is the way it is, only for the trail to end with "Initial commit".

  76. moparisthebest

    Ellenor Malik, bit over 2 years ago https://xmpp.org/extensions/xep-0418.html

  77. Sam

    Fine, split that tree out and keep those commits. It will be a pain in the ass for whomever does the migration for no reason whatsoever though.

  78. Sam

    But it's easy enough to switch repos to figure out where some wording came from.

  79. Ellenor Malik

    moparisthebest: I'm sorry

  80. wurstsalat


  81. wurstsalat

    that's the current xmpp.org repo

  82. wurstsalat

    (I'm all for keeping the history)

  83. Zash

    Should be feasible to delete the `.py` files of the old stuff, `git mv` stuff around and `git commit -m "Switch to Hugo"`

  84. Sam

    Possible, but now I still have to download all of the old pelican stuff every time I clone the repo.

  85. Sam

    What is the point of making more work for ourselves for some hypothetical maybe future person who can't be bothered to open a second tab?

  86. Sam

    We have a repo already, if we want to use it let's just fork it and start using it.

  87. wurstsalat

    but Zash is real :)

  88. Zash

    Why have a repo at all then!

  89. Zash

    Why have history?

  90. Ellenor Malik


  91. Sam

    Obviously we should keep history, I'm not arguing to delete the old repo and purge it with fire, don't misrepresent the argument.

  92. Zash

    If you dont want history just do a shallow clone

  93. Ellenor Malik

    I need to learn java

  94. Holger

    Sam: To be fair it's not about the second tab no? You now have to search two histories. I.e. clone two repos, run the same command twice, …

  95. moparisthebest

    you don't even need to do the hard work of git mv

  96. Holger

    History is _the_ point of VCS and making it harder to use for no strong reason is meh.

  97. moparisthebest

    git add . will automagically do things for you

  98. Holger

    (Or is this pelican stuff gigabytes of data?)

  99. Sam

    It's 70mb (ish). We'd be marking a rare case (searching for something far back in the history) a tiny bit harder to make the common case (forking the repo, cloning it, and making a change) easier.

  100. Sam

    And just not mixing up two unrelated histories where the only thing they share is the content tree.

  101. moparisthebest

    `rm -rf .git` in new repo, `mv /path/to/old/repo/.git .`, `git add . && git commit -m 'hugo now'`

  102. Zash

    Isn't this because the repo has a ton of images and stuff?

  103. Holger

    "Unrelated except where they're totally not unrelated."

  104. moparisthebest

    git might be able to detect the templates/contents were the same history

  105. moparisthebest

    likely even

  106. Zash

    What pelican stuff are you even talking about?

  107. Zash

    It's like a few python config files

  108. Sam

    The theme and the config

  109. Sam

    You are probably right that the bulk of it is the same though, I was forgetting static which I assume hasn't changed

  110. Zash

    And the history only goes back to 2013, earlier stuff is ... lost.

  111. Zash


  112. Zash


  113. Zash

    All this has happened before, all of it will happen again

  114. Holger


  115. Zash

    or is https://github.com/xsf/site-archived it?

  116. wurstsalat

    At least content dates back to 2007

  117. Zash

    Huh, 10 commits from 2013

  118. Zash


  119. Sam

    See, we did it that way last time, let's do it again for consistency and to have a nice hard reset point.

  120. Zash

    I don't have anything else to say on this topic.

  121. Holger

    I get that others don't see as much value in history like e.g. I do, presumably because they don't use it as much. But I don't get how others actually see value in ditching history.

  122. Sam

    I see a lot of value in history, I don't see value in making sure it's kept in one repo.

  123. Sam

    No one is suggesting ditching history.

  124. moparisthebest

    if you don't want history, do a shallow clone

  125. moparisthebest

    no reason for it not to be kept in the same git repo though

  126. Sam

    I do want history, I just don't want a bunch of unrelated pelican history.

  127. moparisthebest

    then do a shallow clone, problem solved

  128. Sam

    Again, making things more difficult for the common case for no reason.

  129. Zash

    I never meant to start a discussion, just a friendly "when you do this for real, do it as a PR that does this in the existing site repo"

  130. moparisthebest

    it's literally the reason version control exists

  131. Sam

    Yes, and we should keep doing the reason version control exists, just as two separate histories for two separate projects.

  132. moparisthebest

    if you don't want version control, just release new tar archives like postfix http://www.postfix.org/download.html

  133. moparisthebest

    it's not unrelated pelican history, many/most of the files are the same

  134. Sam

    Again, stop misrepresenting what I'm saying, this is the third time someone has suggested that I'm saying we shouldn't use VC. I thin you know that's not what I said.

  135. moparisthebest

    "randomly delete all history" is suggesting to not use version control

  136. moparisthebest

    ok, not randomly, but when you do a major refactor

  137. Sam

    "delete all history" is also not what I said. Ever, please reread the discussion.

  138. moparisthebest

    "move all history to different place for no reason upon each major refactor" ?

  139. Holger

    Sam: Yes s/ditch/cripple/, sorry. `git log -S'universal messaging standard'` might not be needed often, but if you need it, it can be *super* useful. Having to clone one or more archive repos (which requires the knowledge of their existence) and re-run that command in each of those is terrible UX, for no good reason at all.

  140. Sam

    And having to do a shallow clone or have a ton of unrelated history is terrible UX *in the common case that happens every day* not just in a rare thing that one or two people will want to do on occasion.

  141. Holger

    That's the thing I don't get: How does it affect UX?

  142. Holger

    You're not seriously talking about those KiB of clone traffic are you?

  143. Sam

    I am in part, yes.

  144. Sam

    I dunno, I honestly don't care as much as this makes it sound like I do, but we have a repo, just forking it and using it seems like the obvious thing to do. On my slow internet most repos are already a pain, so it seems worth taking the opportunity for a clean break.

  145. moparisthebest


  146. moparisthebest

    git did automagically detect all the renames, so full history of content etc is kept

  147. moparisthebest

    $ du -sh * 65M xmpp.org 41M xmpp.org-hugo 72M xmpp.org-hugo-with-history

  148. moparisthebest

    $ du -sh */.git 45M xmpp.org/.git 18M xmpp.org-hugo/.git 48M xmpp.org-hugo-with-history/.git

  149. moparisthebest

    switching to hugo only adds 3MB to the total size of the git repo, keeping history, seems plenty worth it, and not at all "unrelated history"

  150. wurstsalat

    I'm guessing most changes relate to the content/data anyways?