XSF Discussion - 2021-01-15

  1. flow

    FYI GSoC org application starts 29.1, unfortunately due to personal constraints I will not be able to act as GSoC org admin this year

  2. flow

    FYI GSoC org application starts 29.1. Unfortunately, due to personal constraints, I will not be able to act as GSoC org admin this year

  3. goffi

    Hello, I don't see any mention of a XMPP summit this year, will there be any? I know that FOSDEM is online, but isn't there any plan to do an online summit too?

  4. jonas’

    SamWhited, re your last email in the DOAP thread: I think you might’ve misunderstood what mathieui was trying to say in the first quote you made.

  5. jonas’

    He was trying to say that projects which do not provide a DOAP file will remain at the status quo (pre-DOAP) regarding their listing.

  6. jonas’

    projects which do provide a DOAP file get extras (pictures, xep info etc.)

  7. jonas’

    so a DOAP file is still no requirement whatsoever to be listed

  8. SamWhited

    Yes, that is how I understood it. It's better than them not being listed, but it's still not okay.

  9. SamWhited

    There is some level of complexity where that is okay, but DOAP is far above it. This will only hurt us and make fewer projects able to be listed in a nice looking way.

  10. Ge0rG

    I really don't understand the amount of hate towards XML in the XMPP community.

  11. MattJ

    Ge0rG, have you ever worked on non-XMPP XML-based systems/protocols? :)

  12. MattJ

    Apart from XMPP, almost everything is terrible

  13. Ge0rG

    MattJ: I have really horrible memories of a SOAP API I was involved in.

  14. SamWhited

    The supposed "knee jerk" reactions people have too it aren't entirely wrong. I work on XMPP because I think it's the best way to do federated chat and it does XML about as well as it's possible to do it, but XML still introduces tons of security issues, needless complexity that leads to bugs, etc. and we shouldn't fall into the XML communities trap of "it's so powerful that we need to rewrite everything using XML".

  15. SamWhited

    If we're going to use more XML, we should at least restrict ourselves to the sane subset of XML that XMPP uses which makes it sort of tolerable to work with.

  16. MattJ

    That didn't happen with DOAP, we didn't set out to find a way to express project data in XML

  17. MattJ

    It just happens that DOAP -> RDF -> XML

  18. Ge0rG

    SamWhited: could you imagine writing a simple yaml2doap converter?

  19. SamWhited

    Ge0rG: again, this is the problem: if I need extra tools and converters and DSLs or whatever just to display some metadata we've already failed.

  20. MattJ

    I can, and I honestly volunteer to do it if you give me a spec

  21. Zash

    I wrote a small shell script that can turn CSV into DOAP

  22. MattJ

    No, I just want this format bikeshedding to stop

  23. MattJ

    It really doesn't matter 99% as much as getting the job done

  24. Zash

    At least the XEP table thing

  25. Ge0rG

    SamWhited: I had to write an extra tool and DSL for DOAP because I wanted to use the same basic document structure for Bruno the Jabber™ Bear as well as for yaxim. There is no other document format that would have saved me from *that*

  26. SamWhited

    Normally I'd agree with MattJ, but I do think DOAP is worse than not doing the job and just listing things on the website when the author files an issue or whatever.

  27. Ge0rG

    SamWhited: I think you've already made yourself clear in that regard.

  28. Ge0rG

    It also looks like most people disagree with you on that.

  29. Zash

    Didn't half the (client) projects listed already adopt DOAP? IIRC from looking at Link Mauves render

  30. Ge0rG

    I've adopted DOAP in 2019

  31. SamWhited

    My site generator (currently hugo, but that may change soon; I'm sure most of them do something like this) can spit out files in various formats (JSON, XML, CSV, probably others). You can put some simple key values in and get a file out. Great. However it doesn't support downloading schemas and validating them and writing namespace prefixes which are sort of their own extra side metadata channel and etc. and nor should it, there's no reason to add all that complexity, it's as simple as that.

  32. MattJ

    I agree with everything you just said

  33. MattJ

    I don't know why you think that stuff is necessary

  34. SamWhited

    Even if I'm writing my own implementation, ie. in my site I have a python file that converts yaml or whatever, it's easy to marshal an object to some simple format, it's not trivial to figure out how to parse a schema and validate it, for example.

  35. MattJ

    It just feels like you're /trying/ to see it as more complicated than it is

  36. Ge0rG

    SamWhited: your site generator can convert a HTML template and a set of variables / arrays into a webpage. It surely can convert an XML template into a DOAP file

  37. MattJ

    Nobody is doing that

  38. SamWhited

    All of this is necessary because if I just pick a file and copy/paste it as I've tried to do multiple times half of them use different technologies and namespaces that aren't discoverable, there's no documentation for what the fields are or how to change them, etc.

  39. SamWhited

    Ge0rG: it can't.

  40. MattJ

    SamWhited, let us know what you're stuck on, we can help... and document it

  41. SamWhited

    The entire format needs documentation, so far every time I say "what are the fields" someone links me to a blob of XML. That is not documentation, I have no idea how to read it and it's not helpful.

  42. Ge0rG

    yeah, you can help improve the documentation!

  43. SamWhited

    Not to mention that that blob of XML doesn't even cover all the fields because they're defined in like 3 or 4 different places.

  44. SamWhited

    Apparently I need to figure out DOAP and RDF and SPDX and FOAF and SCHEMA or whatever just to figure out what fields I can even write

  45. jonas’

    lesson learnt: don’t try to fix a potential misunderstanding.

  46. Ge0rG

    SamWhited: with the amount of energy you invested (and took from everybody reading and answering), you could have created a splendid XMPP RDF manual.

  47. SamWhited

    Or I could spend the time fighting for a sane format, which is a much better use of the time than accepting this overengineered garbage from people who should know better

  48. SamWhited

    This is exactly why no one uses XMPP anymore, we make the same damn mistakes over and over again and it's infuriating.

  49. Ge0rG

    There is an awesome saying in German hacker culture, "wer macht, hat recht" - loosely translated it means "the one who's doing things, is in the right"

  50. SamWhited

    As I've said, I'm happy to introduce an alternate format.

  51. Ge0rG

    SamWhited: yes. please use your time machine to travel into 2017 and introduce it back then

  52. Ge0rG

    SamWhited: or, if you are inclined to improve the situation as it is today, write a yaml2doap converter for the people who look for an easy key-value solution.

  53. Ge0rG

    or json2doap, or whatever.

  54. SamWhited

    Ge0rG: no, as I've also said multiple times that's a stupid way to do it and means we've already failed.

  55. SamWhited

    It's infuriating that I'd need tooling just to list some metadata

  56. Ge0rG

    SamWhited: I used a text editor as my tooling.

  57. SamWhited

    Well lucky you, I've tried that and I have no idea if it's valid or works or what all the fields are

  58. Ge0rG

    SamWhited: well, then write a doap2yaml converter and convince everybody to use your schema-less new efficient format

  59. SamWhited

    Ge0rG: yes, I have already volunteered to do that

  60. Ge0rG

    I have volunteered to do many things in the past. Most of them never were actually done.

  61. SamWhited

    I don't understand the argument, this is the second time someone has said "so do it yourself" and I've said "fine, I will" and then the answer is "well we'll just use DOAP anyways" or "well it probably won't get done". What was the point in asking in the first place?

  62. Ge0rG

    SamWhited: it would make you stop complaining and distract you with pointless action? ;)

  63. Ge0rG

    SamWhited: seriously though, if there is a lossless converter into a different format and a documentation for that format, you *might* have a chance to convince the people to switch

  64. Ge0rG

    However, nobody in the XSF has the resources to maintain a meta-data specification project, and using an existing one is the next-best solution.

  65. Ge0rG

    If you want to compete with DOAP, you need to do better than DOAP in terms of long-term reliability

  66. SamWhited

    Yah, I'm working on it. I don't know about the converter part because I can't figure out how doap works in the first place and if I write it I'm sure everyone will just complain that it's actually wrong because I had to guess at how fields worked and left out every schema in existance that could be improted, etc., but the spec should be easy enough

  67. SamWhited

    We don't need any of that to display some clients on the website.

  68. SamWhited

    We need the like dozen or so simple values that let us show links to a readme and a license and a screenshot and what not.

  69. Ge0rG

    or two screenshots. or an array

  70. Ge0rG

    also multiple resolutions

  71. SamWhited

    Sure, I wasn't actually enumerating every single thing we'd need. But we can't fall into the trap of "we need everything", we need something "good enough".

  72. SamWhited

    What that is we can bike shed on a bit during the XEP process.

  73. SamWhited

    Anyways, we'll see, it's a bit of a self fullfilling prophecy because I both want to finish this and try to convince people to switch, and have been told alternatives probably won't be considered so I'm not sure if there's a point and either way I'm stuck in the position of "why didn't you do it? we wouldn't have even tried to use it anyways, but why didn't you do it?" so I may or may not finish it.

  74. Ge0rG

    SamWhited: nobody wants to bikeshed what we need. We just want to have a format for writing down a list of XEPs and some meta-data

  75. MattJ

    I have no desire for bikeshedding anything, which is why we'll be sticking with DOAP, but I'm not opposed to an alternative format if there is a conversion possible

  76. MattJ

    That is, I'm not opposed to another format existing

  77. SamWhited

    I mean, sure, I'd rather not argue over exactly what image formats shoudl be required either, but it's better than "so support everything under the sun with no documentation, what could go wrong?"

  78. MattJ

    DOAP is more interoperable with other stuff, so that's what I'd prefer to use

  79. Guus

    This is a recurring discussion. I feel that the effort going in this discussion outweighs the benefit of having automation around discovery what the description of a project is. What are we using this for? Slightly more data (yet inconsistent and thus possibly presented in an ugly way) on our website?

  80. Ge0rG

    Guus: as a client developer, it's good to see which (OSS) implementations cover a given XEP, to steal code^W^Wget inspiration, and which other implementations one needs to do interop-testing with

  81. Ge0rG

    as a user, I want to see which clients have the IM Compliance Suite 2021 badge attached.

  82. MattJ

    Guus, personally I think this is going to be on the list of the best things that have happened to XMPP for a long time

  83. MattJ

    and I can barely comprehend a stance that it will be hardly useful

  84. Ge0rG

    also gamification effects!

  85. MattJ

    We have so much XMPP software to choose from, and nobody knows what is up to date and what is not

  86. Guus

    Ok, I'd be happy if that's the case. I'm skeptical, but happy to be proven wrong.

  87. MattJ

    Having this data is useful for so many things

  88. MattJ

    Even for XEP work, it's useful to be able to know at a glance what implements a XEP

  89. mathieui

    Ge0rG, this is a tool to make the ecosystem more readable, by 1) listing for each XEP, which client/library/server implements it (self-reported, which is as good as we will get), which helps developers pick and choose both which implementation to go with, and which they may want to implement 2) For users, it gives the opportunity to see at a glance which client implements which compliance suite, which is easy to map to desired features not saying it is a panacea or that it will have a miraculous effect, but it should help

  90. Ge0rG

    mathieui: no need to convince *me*

  91. mathieui

    err, Guus*

  92. Ge0rG

    BTW, having DOAP should be a huge marketing benefit for xmpp library developers, cc flow

  93. Guus

    I remain skeptical and happy to be proven wrong.

  94. moparisthebest

    Guus, what's to be skeptical about? haven't seen Link Mauve 's work that is already done and demonstrates the utility? unfortunately I don't have that link handy...

  95. Link Mauve

    moparisthebest, https://linkmauve.fr/software/clients.html and https://linkmauve.fr/extensions/ maybe?

  96. mathieui

    (probably worth it to link to an extension page, where it is imo the most useful, e.g. https://linkmauve.fr/extensions/xep-0199.html )

  97. Link Mauve


  98. MattJ

    It's easy to forget that outside of our core community, people really struggle with discovering this information

  99. jonas’

    (not just outside the core community)

  100. Guus

    moparisthebest I have no doubt that the technology will work. I'm doubtful that it'll lead to the availability of an accurate set of data of a good cross-section of the ecosystem.

  101. Ge0rG

    Guus: I think we can help that by making good use of this data on our website

  102. Zash

    Guus, don't underestimate the attractiveness of shiny green checkmarks

  103. Ge0rG

    Zash: badges!

  104. Zash


  105. Ge0rG

    Zash: didn't you want to make some progress with badges?

  106. Zash

    here's my badge so far: `"badges":{"av":"advanced","web":"advanced"}`

  107. Zash

    Dunno if Link Mauve uses this or made their own thing?

  108. Link Mauve

    I use it directly, see https://git.linkmauve.fr/xmpp-doap.git/

  109. Zash

    Oh, source code

  110. Link Mauve

    And then parse its stdout.

  111. Link Mauve

    It even comes in a docker thingy!

  112. Ge0rG

    is there a badge rendering thing where we can combine multiple Compliance Categories into one badge?

  113. Zash

    Ge0rG, yeah, that's the main question atm I think

  114. Link Mauve

    Ge0rG, that was my request a few days ago, which theTedd replied with interested eyes. :)

  115. Link Mauve

    Ge0rG, that was my request a few days ago, to which theTedd replied with interested eyes. :)

  116. Ge0rG

    Link Mauve: this is ending up in significant bike shedding again

  117. Link Mauve

    “14:27:05 SamWhited> Well lucky you, I've tried that and I have no idea if it's valid or works or what all the fields are”, honest question, why do you feel like this needs more validating than, say, your website, or a random stanza you send over the wire?

  118. Zash

    Shouldn't there exist RDF (documentation) viewers?

  119. Ge0rG

    I suppose that a badge format like [XMPP Compliance 2020: Core IM, Advanced Web] with the : as a color separator would be better, but how do you color-code "Advanced Web"?

  120. Zash


  121. Zash

    Ge0rG, "Core Core" ... ‽

  122. SamWhited

    Link Mauve: I mean, I want it to actually work if I'm going to go to all the trouble of learning it and not just copy/paste which means that one bug gets repeated over and over again

  123. Ge0rG

    Zash: "Core Server"

  124. SamWhited

    If people really would support an alternate format, would you prefer a documented set of keys that gets stuck in an XML file in .well-known (or wherever), or a microformat in the code of the site itself?

  125. Ge0rG googles: DOAP schema > Did you mean: SOAP schema NOOOO!!111!!!

  126. Zash

    Ge0rG, I mean, Core being both a category and a compliance level makes for confusion.

  127. jonas’

    I would accept an alternate format which is already defined elsewhere.

  128. jonas’

    SamWhited, making up a format when we could reuse DOAP is not going to sit well with me

  129. Ge0rG

    Zash: yes, I've stumbled upon that when creating badges for all combinations, and I solved it by de-duplicating "Core"

  130. SamWhited

    I think if I had to pick a single main complaint about this garbage fire of a format it's that it's not documented in a single place and is actually like 5 formats jammed together. If we come up with a small one for our own use it's documented in a single place which seems like the biggest win to me.

  131. MattJ

    SamWhited, microformats in HTML are more effort to parse in my opinion

  132. SamWhited

    MattJ: good point

  133. Link Mauve

    SamWhited, I’ve found multiple DOAP validators, if you really want to go down that road.

  134. SamWhited

    Again, I shouldn't have to use alternate tools. If it's not human readable first and machine readable second we've already failed.

  135. lskdjf

    How about not putting the "Core" caterogy onto badges? It's not understandable what this category entails. And since a big point of the badges is to let users know how advanced clients/servers are, I'd leave it out. It just adds noise.

  136. Link Mauve

    SamWhited, DOAP is both, thankfully. :)

  137. SamWhited

    It's not and I think you know it.

  138. lskdjf

    How about not putting the "Core" category onto badges? It's not understandable what this category entails. And since a big point of the badges is to let users know how advanced clients/servers are, I'd leave it out. It just adds noise.

  139. Zash

    I say it's perfectly readable as long as you avert your eyes from the xmlns:prefix definitions.

  140. SamWhited

    And as long as you know how XML schemas work apparently since the only documentation is itself a giant blob of even more XML technologies to learn

  141. Kev

    To be fair (and I'm not defending DOAP, or saying I want us to use it), I think anyone involved in writing XMPP software already has a fair clue how schemas work or they'll be in trouble :)

  142. Kev

    No, I take that back, that's not true.

  143. Kev

    Ignore :)

  144. SamWhited

    Maybe I'm just an idiot then, because I have never had to write a schema or learn any of this prefix nonsense to write XMPP and any time I've tried I've gotten bogged down in contradictions and terrible docs and never figured it out

  145. Link Mauve

    I remember my first client doing sprintf(stanza, "<message><body>%s</body></message>", message); :°)

  146. Ge0rG

    can't Link Mauve provide a link to a working DOAP schema verifier, SamWhited use that verifier to check their favorite client's hand-rolled DOAP and then document the fields and their meaning in human-readable HTML?

  147. Link Mauve

    SamWhited, XMPP uses XML Schema to describe the protocol extensions starting with draft specifications.

  148. lskdjf

    Link Mauve, the number of doap files are currently given as e.g. "3/6", which translates to "3 out of 6". However 6 isn't the total number of clients, and there probably will never be DOAP files for _all_ implementations. I'd maybe leave it out and just say "3", to not suggest a false number of total implementations.

  149. Kev

    Link: No, it doesn't, not really.

  150. Ge0rG

    Link Mauve: which is why nobody ever achieves Draft.

  151. Kev

    It uses schemas only illustratively, it's the text that's definitive.

  152. Link Mauve

    Ge0rG, there is one right in the DOAP repository: https://github.com/ewilderj/doap/tree/master/validator

  153. Kev

    So there's ~= no reason to read the schema in a XEP.

  154. Link Mauve

    lskdjf, good idea!

  155. SamWhited

    Link Mauve: and I have never written one or been able to read one. I have seen people find errors in them on a fairly regular basis though.

  156. Link Mauve

    lskdjf, is that better?

  157. Link Mauve

    SamWhited, yes, I am part of these people.

  158. lskdjf

    Link Mauve, that was quick 😉 imho it is better, yes

  159. Link Mauve

    Our usage of XML Schema has been fairly useless to me as an implementor, I usually use it as a list of known elements and their attributes, but I have to use my own DSL.

  160. Link Mauve

    lskdjf, just a small .js file to modify. ^^

  161. Ge0rG

    Link Mauve: can you add a tooltip listing all the clients over the number? with the respective logo?

  162. Ge0rG

    or make the number collapsible? :D

  163. SamWhited

    Alternative suggestion: is it possible to just say "anything the website pulls from DOAP has to also be accepted in an issue and the web people will add it to the list manually"?

  164. Ge0rG

    SamWhited: NO!

  165. Link Mauve

    Ge0rG, I tried to yank Wikipedia’s popover plugin when someone suggested that a full list of all implementations would be too large, but then saw they use npm and my motivation vanished instantly.

  166. moparisthebest

    are we striving for perfection or "way better than we have currently / really good" ? because what Link Mauve has is already well past the second bar

  167. MattJ

    Ge0rG, we could always maintain DOAP files for people in an XSF repo :)

  168. lskdjf

    > or make the number collapsible? 😀 +1 for making the "Implementations" column hidable (and maybe hide it by default? unsure)

  169. lskdjf

    > or make the number collapsible? 😀 +1 for making the "Implementations" column hideable (and maybe hide it by default? unsure)

  170. moparisthebest

    been talking to non-XMPP folk a lot about XMPP over the last week, and all the technical ones have been very confused about XEPs to say the least

  171. moparisthebest

    in the "XMPP is useless because so many XEPs" "I could never implement them all" sense

  172. Ge0rG

    lskdjf: I'd leave the column in, and make the number a button that toggles display of the implementations

  173. lskdjf

    actually, if it's not hidden by default, perhaps it also doesn't make sense to make it hidable at all 🤔️

  174. lskdjf

    Ge0rG, ah, I see. I misunderstood your idea

  175. Link Mauve

    The JS already has the information needed to create the popover, I’m just not good enough at web dev to achieve a popover.

  176. Ge0rG

    Link Mauve: https://www.gwern.net/Changelog#december-2020

  177. Link Mauve

    Yes, like that!

  178. Zash

    MattJ: Us maintaining more things?

  179. Ge0rG

    MattJ: we could have a wiki page with all the DOAP pasted in.

  180. MattJ

    Zash, changing stuff in HTML or elsewhere is roughly equivalent

  181. MattJ

    I'm just saying, if we're going to allow projects without DOAP files to have equivalent data on our site, we should probably just create them a DOAP file so we can use the same automation

  182. MattJ

    and that's an "if"

  183. Ge0rG

    MattJ: we could write to the website visitors' GPU RAM!

  184. Ge0rG

    MattJ: right. That's a possible logical step.

  185. Ge0rG

    For the developers that can host their download portal but not a small XML file.

  186. MattJ

    Exactly that

  187. Ge0rG

    or maybe for developers that are allergic to XML?

  188. Zash

    MattJ, I mean the format doesn't matter. Having the projects do the work of keeping them up to date is, as opposed to adding to the XSF workload.

  189. Link Mauve

    ↑ that was my original idea, btw.

  190. Ge0rG

    Zash: I'm sure the XSF has plenty of free resources for that, counted by the amount of bikeshedding we perform.

  191. Link Mauve

    That each project has people who know the current and planned features and their limitations, and they are in the best place to keep machine-readable information about that.

  192. MattJ

    I totally agree

  193. MattJ

    But I also can't stand the cries of the victims of this decision, and if we have to compromise for a handful of projects, I don't think it's the end of the world

  194. Ge0rG

    Also my gut feeling that having a per-XEP format that describes the XEP version, the app version, support level and optional comments will be ugly in any file format

  195. Link Mauve

    I’d rather not commit us to keeping up to date with the feature set of each XMPP software.

  196. MattJ

    We are not committing to that

  197. Zash

    I tried it with that big table, but eventually gave up. And that format was much simpler.

  198. Ge0rG

    let's just keep the data in a google docs spreadsheet.

  199. Ge0rG

    one spreadsheet, all implementations.

  200. Ge0rG

    bonus feature: auto-complete over all projects for the per-xep excuse comments

  201. Zash

    cell(xep, project) := ( "yes" / "no" / ">=x.y.z" ), ", comment"

  202. Ge0rG

    Zash: one line per xep per client, because we need three data elements.

  203. SamWhited

    FWIW I wasn't suggesting that the XSF web person would have to go look up my software and figure out what it supports. Just that I would paste all the information I had into an issue and they could do whatever they do with it.

  204. SamWhited

    If that includes the supported XEPs great, if not, we didn't require those anyways whether you write a DOAP file or not.

  205. SamWhited

    The point is just that if we want to list software we shouldn't be putting a large burden on the software authors and that's what we're doing with DOAP. Putting anyone who ddoesn't want to deal with XML namespaces and schemas into a second class citizens bucket is not okay IMO.

  206. Ge0rG

    SamWhited: pasting things into an issue is the opposite of reducing our webteam's workload

  207. Zash

    Nothing with the current approach prevents storing DOAP files in an XSF repo afaik

  208. SamWhited

    Ge0rG: I'm more concerned with the workload of the software authors which we are adding to if they want their software listed.

  209. Ge0rG

    SamWhited: you are confusing your impulse to provide 100% correct and validated XML with how people tend to work to get a green checkmark on a webpage.

  210. SamWhited

    Ge0rG: I'm not sure what you mean?

  211. Zash

    In the Prosody support channel we regularly hear from people going to great lengts to catch all the green checkmarks from the Conversations compliance tester.

  212. Ge0rG

    SamWhited: nobody particurly likes the DOAP format, but it is good enough, it is there, it does the job, and nobody expects to perform automatic validation of its XML

  213. SamWhited

    I don't expect it to either, I don't understand what you're arguing

  214. Ge0rG

    SamWhited: most developers will pick an existing RDF file, replace the values, update the XEP list and be done with it

  215. SamWhited

    And now the bugs in that first RDF file are propogated down into all the other projects, yay complexity.

  216. jonas’

    do you truly believe that would be different for any other format?

  217. SamWhited

    yes, absolutely

  218. Ge0rG

    jonas’: a schema-less format wouldn't have validation errors.

  219. SamWhited

    I'm not saying it will be bug free, but less complexity means fewer bugs.

  220. jonas’

    Ge0rG, oh, true

  221. SamWhited

    Also having a single place where the format is fully documented means fewer bugs instead of just an XEP that documents a tiny part of it and links you to another schema instead of documentation.

  222. Ge0rG

    SamWhited: stop arguing and write down an informal description. Make a template RDF and run it through https://github.com/ewilderj/doap/tree/master/validator

  223. SamWhited

    I already did write down an informal description of one possibility

  224. SamWhited

    It's in the mailing list somewhere.

  225. SamWhited

    Or maybe it was here, I forget.

  226. Ge0rG

    SamWhited: if you'd have followed that path, everybody would be much happier and you wouldn't have burned through dozens of hours of people's time.

  227. SamWhited

    Still, I wasn't the one arguing, I asked about an alternative and then you started going back into the previous arguments again

  228. Ge0rG

    SamWhited: well, in that case we can all go back to doing productive things again.

  229. SamWhited

    So, back to the original question: regardless of what format we use I think it shouldn't restrict us from listing a client or server or what not. The more complex the format, the fewer projects will implement it (of course, maybe I'm wrong and everyone will do it except me and it's fine if only one project is left out, I dunno), so I feel like we need an alternative either way.

  230. SamWhited

    We don't want to put too much on the website maintainers, so I agree they can't be expected to go look up a clients details just because the author asked to have it listed.

  231. SamWhited

    But I also think we shouldn't require authors to learn and write DOAP. I'm hopeful some web person can agree to a middle ground.

  232. Ge0rG

    SamWhited: the web team doesn't have resources beyond adding a link to an externally hosted file

  233. mathieui

    Again, nobody ever said it would restrict us from listing it on the website. Link Mauve put them first in the example, but if we agree that aesthetics don’t matter, it could be mixed without an issue.

  234. SamWhited

    Then we shouldn't add these doap enhancing features at all regardless of the format IMO

  235. Ge0rG

    maintaining the detailed information on the XSF repositories is a significant burden without any benefit

  236. Ge0rG

    SamWhited: those features provide multiple benefits

  237. Ge0rG

    the work has been done

  238. SamWhited

    The benefit is that authors don't have to learn DOAP or modify files on their web server which they may or may not have access too if they're using one of those easy website design or blogging things, etc.

  239. Ge0rG

    there is no reason not to make use of them.

  240. Zash

    Compromise suggestion: Add a logo and screenshot field to the clients.json format.

  241. SamWhited

    I completely disagree with that statement. I mean, I do think it's nice to have, but just because something has been done doesn't mean we need to maintain and support it going forward.

  242. Ge0rG

    SamWhited: implementation develoers will have some way to host files for users to download their implementations

  243. moparisthebest

    is the argument now that XMPP devs can learn+read+implement 300+ XEPs but not copy/paste/edit a doap file?

  244. SamWhited

    Zash: what is clients.json?

  245. Zash

    SamWhited, the list of clients used by the website curretly

  246. SamWhited

    Ge0rG: not necessarily, mine is just on GitHub.

  247. mathieui

    SamWhited, software developers who don’t have access to either a website or a public repo, really?

  248. Ge0rG

    SamWhited: https://github.com/xsf/xmpp.org/blob/master/data/clients.json

  249. SamWhited

    mathieui: do we support pulling from repos? That does negate that particular argument, I thought this was a website thing

  250. Zash


  251. Ge0rG

    SamWhited: you can link to a raw file on github

  252. mathieui

    as long as it can be accessed with http's)

  253. mathieui

    as long as it can be accessed with http(s)

  254. SamWhited

    That's fair then, I assume most (all?) repos are available over HTTP in some form.

  255. mathieui

    Of course, for non-opensource implementation the repo is a big no

  256. SamWhited

    So back to "I shouldn't be a second class citizen just because I don't know how 5 complicated XML technologies work and don't want to waste tons of time learning when I could just provide the information to put on the website"

  257. mathieui

    but then the entity probably has the resources to maintain an XML file on a website

  258. Ge0rG

    SamWhited: copy&paste the template RDF.

  259. SamWhited

    Ge0rG: we've already been through this. Then you end up propogating any mistakes in that down the chain. This is just bad software engineering.

  260. moparisthebest

    I can only do CSV and all this XML is too much for me, I shouldn't be forced to use XML to develop XMPP software, we need to rewrite the RFCs to use CSV

  261. SamWhited

    And bad web design for that matter. This is how half the netscape tags became things we had to live with.

  262. Ge0rG

    SamWhited: there is a DOAP validator.

  263. MattJ

    SamWhited, and this is terrible how? Actually?

  264. SamWhited

    Ge0rG: we've been through that too

  265. Zash

    moparisthebest, `xml2 | 2csv` is the best thing since pandoc!

  266. MattJ

    Worst case, we fix bugs we find

  267. moparisthebest

    Zash, but I shouldn't be forced to use tooling!!!

  268. Ge0rG

    SamWhited: you dislike the format and are looking for excuses not to use it. This is fine. You are also trying to block everybody else from doing it / using the work they've already done. Please stop with that.

  269. SamWhited

    This work is garbage that will harm the XSF by making fewer projects be listed on the page, so yes, we shouldn't use it without modification.

  270. Zash

    moparisthebest: `csv2 | sed | xml2` then 😉

  271. MattJ

    SamWhited, your argument seems to be that because RDF has a schema, we are compelled to use it. Or we can create a custom format from scratch with no schema and that would be just fine.

  272. SamWhited

    I think that's a bullshit argument. I've written plenty of XEPs that had implementations that had to change after the fact, I didn't necessarily like it, but that's how we come to the best solution.

  273. SamWhited

    MattJ: yes, more or less, assuming some level of simplicity. I don't especially care if there is a schema or not, but I shouldn't have to read that schema to know how to write it.

  274. SamWhited

    If someone wants to write a schema, fine.

  275. mathieui

    SamWhited, I believe a possible addition to the current XSF website CI could be a tool that pulls the new doap files and validate the schema

  276. SamWhited

    And I shouldn't have to import external namespaces, namespaces and namespace prefixes are just an anti-pattern.

  277. moparisthebest

    Zash, and now you are expecting me to deeply understand the entire complexity of sed just to develop xmpp in csv? I just want to write CSV

  278. SamWhited

    But the point is mostly just complexity. This is all too much stuff that I'm not going to do. If I'm alone in that maybe it's fine and the XSF doesn't need to care, but I suspect I'm not and that outside this group there will be plenty of people who won't want to deal with it.

  279. mathieui

    (that would help notify software authors that their files are invalid, and prevent any mistake)

  280. Zash

    moparisthebest, leave that to Link Mauve or me then. I'm sure we can demangle your csv

  281. SamWhited

    mathieui: that's definitely something we would need to do either way I think

  282. mathieui

    SamWhited, yes

  283. mathieui

    I was thinking that in any case it is kind of required

  284. SamWhited

    But okay, my question was answered, sounds like this will be the only way and you can't just submit information if you want your client listed

  285. Ge0rG

    mathieui: in the end it will make the website CI fail on publishing unrelated page updates!

  286. mathieui

    Ge0rG, I was thinking of the CI pull requests only

  287. SamWhited

    Ge0rG: you don't have to make the publish fail, just alert that "file X was invalid this time and its entry won't show up in the table"

  288. Ge0rG

    SamWhited: yeah, that's the theory.

  289. SamWhited


  290. SamWhited

    I don't understand that statement, I thought you were just saying to mathieui that CI wouldn't work?

  291. Ge0rG

    SamWhited: I was saying that care needs to be applied so that CI won't fail for somebody else

  292. SamWhited

    oh sure

  293. SamWhited


  294. Ge0rG

    as a good software engineer you probably know that. But maybe you don't test it when implementing the CI addition, and in the end it fails in a different way leading to the website becoming unpublishable

  295. Ge0rG

    Or you run into a network timeout when pulling the remote spec file.

  296. SamWhited

    yah, I agree, we'd need CI for this regardless of the solution and if the solution involves downloading external files that CI shouldn't stop the whole website from publishing.

  297. Ge0rG

    and with XML being XML, well... you know the issues

  298. Link Mauve

    “16:01:33 Zash> Nothing with the current approach prevents storing DOAP files in an XSF repo afaik”, in my current deployment, they are stored in $XDG_CACHE_HOME/xmpp-doap after having run the script, I could store them in the directory that will be served on the web instead, that way we don’t have to use the repository for every change.

  299. Ge0rG

    Link Mauve: storing them permanently will add another hidden cache

  300. Link Mauve

    It is a well-known cache.

  301. Ge0rG

    also it won't really solve any of the problems, just slightly mitigate them.

  302. Link Mauve

    mathieui, my current tool kind of already validates that it at least is valid RDF/XML.

  303. Link Mauve

    I already caught Dino updating to invalid language tags as per BCP47.

  304. Link Mauve

    It’s based on the sophia crate.

  305. Ge0rG

    I tried to build the validator, but gave up after reading this: > error CS0006: Metadata file `Redland.dll' could not be found

  306. mathieui

    Link Mauve, I was saying, in the CI pipeline for the website merge requests, not for the website integration

  307. Ge0rG

    mathieui: but that would make unrelated PRs also fail

  308. Link Mauve

    That also wouldn’t catch updates that are done without a PR, for instance synchronised to a client release.

  309. mathieui

    Ge0rG, you can get the diff of a PR and run it only if a file is added (which is the only point)

  310. mathieui

    and yes, the website thing needs to also validate and ignore the invalid ones, of course

  311. Ge0rG

    maybe just providing easy-to-use tooling to validate an RDF file would suffice?

  312. Ge0rG

    Like... host a validator? 😁

  313. Link Mauve

    “16:20:19 SamWhited> Ge0rG: you don't have to make the publish fail, just alert that "file X was invalid this time and its entry won't show up in the table"”, the way my tool works atm is that it will reuse the previously valid cached version in case the latest downloaded file was invalid this time.

  314. SamWhited

    I was forgetting this is all javascript too so CI wouldn't catch it. It doesn't seem great that things would just dissapear from the list and the old one would be used.

  315. Link Mauve

    It’s actually Rust.

  316. Ge0rG

    Link Mauve: that would work, except for server timeouts

  317. Link Mauve

    The JS is only for the presentation on XEP pages.

  318. SamWhited

    Oh, nevermind then, if it's on the backend we can add some alerting presumably

  319. SamWhited

    As long as there's some sort of alert that "Dino is now failing, please inform the authors"

  320. Link Mauve

    Ge0rG, timeouts are also handled (thankfully louiz’s forge was down at the time I wrote it :D), and will go the same path.

  321. Ge0rG

    Link Mauve: are you doing all downloads in parallel? Because otherwise you'll end up with cumulative timeouts possibly exceeding the CI job lifetime

  322. Link Mauve

    SamWhited, yeah, currently it’s a warning being printed, I’m sure with some emailing integration it could do that automatically.

  323. Zash

    Link Mauve, is there a rust csv parser? 🙂

  324. Link Mauve

    Ge0rG, yes.

  325. Ge0rG

    Link Mauve: awesome job!

  326. Link Mauve

    Zash, https://crates.io/search?q=csv

  327. Zash

    obligatory "thanks, a blank page" <insert js rant>

  328. SamWhited

    Oh boy, wait until you realize that you can only log in if your project is on github.

  329. Link Mauve

    SamWhited, no, you need a GitHub account because that’s what they use as their authentication mechanism, but you can host your project anywhere.

  330. SamWhited

    or rather, if you have a github account. I guess the project doesn't have to be there.

  331. SamWhited

    Yah, that.

  332. Link Mauve

    Which I’m not fine with, but I understand the reasoning.

  333. Link Mauve

    Authentication is hard.

  334. Ge0rG

    At least it's not "login with facebook"

  335. moparisthebest

    Zash, no JS required https://lib.rs/search?q=csv

  336. Zash


  337. Link Mauve

    moparisthebest, oh thanks, I’ll use it starting from now.

  338. moparisthebest

    np, I find it handy

  339. MattJ

    Holger, since XEP-0045 differences are flavour of the month, do you happen to know if ejabberd supports additional data in the MUC registration form? i.e. this one: https://xmpp.org/extensions/xep-0045.html#example-71

  340. MattJ

    and if it does, when the user is already registered, does it include that form in a jabber:iq:register type=get?

  341. MattJ

    According to https://xmpp.org/extensions/xep-0045.html#example-70 the form should not be included if there is already a registration

  342. MattJ

    But if custom fields are supported, I don't see why you wouldn't want to provide that info to the client...

  343. MattJ

    and allow them to modify the registration

  344. Ge0rG

    And can we have DOAP support for individual features?

  345. Zash

    Oh glob

  346. Holger

    MattJ: Would have to check but the whole registration thing is outdated in ejabberd anyway, you register against the MUC service rather than individual rooms.

  347. Holger

    MattJ: I'd be motivated to change things to make Siskin work 🙂

  348. MattJ

    Ok, I'm sticking to XEP-0045 for now unless Siskin doesn't like it (early indications suggest it's fine)

  349. ralphm

    Something's come up, can't make it today.

  350. ralphm

    (the Board meeting, that is)

  351. dwd

    Someone else want to Chair, then?

  352. MattJ

    "Go for it?" :)

  353. MattJ

    First item on the agenda: XML or JSON

  354. dwd


  355. Zash


  356. dwd

    Blank Verse.

  357. dwd


  358. dwd

    1) Roll Call?

  359. MattJ


  360. dwd


  361. Zash

    Seve, arc ?

  362. MattJ

    I don't think Seve will be joining us today

  363. MattJ prods arc's alarm clock

  364. dwd

    OK, unless arc is about we have to can it. And I'm inclined to can it anyway without Seve and ralphm.

  365. MattJ


  366. dwd

    2) Try Again Next Week.

  367. dwd

    Let's try again next week.

  368. MattJ

    Pity, I was hoping we'd at least make it to the eternal debate: vim or nano

  369. Zash

    What about FOSDEM or Summit?

  370. MattJ

    Every board meeting results in: it's up to SCAM

  371. MattJ

    Pretty clear someone from SCAM needs to weigh in on that

  372. Zash

    Who was SCAM‽

  373. larma

    Maybe add GSoC to the list of things to think about?

  374. dwd

    larma, We did, and (IIRC) I said I'd do something. We all also agreed to look at something else. We are lacking minutes from that one, and my memory is shot.

  375. larma

    Ah, great

  376. larma

    What "something else"

  377. dwd

    larma, But loosely, we noted that GSoC student time and money is halved this year, and we were talking about making up that shortfall ourselves.

  378. dwd

    larma, The something else was a similar thing to GSoC for under-represented groups, as I recall.

  379. larma

    Hmm. I was actually thinking that I like their idea of smaller projects

  380. larma

    At least if that means to have more projects/students accepted

  381. dwd

    larma, I don't think that's the implication here. I think it's just intended to be workload reduction due to COVID.

  382. Zash

    I'm not seeing any activity in SCAM since October.

  383. larma

    dwd: I understood the announcement such that the change is meant to persist and not related to covid

  384. lskdjf

    > larma, I don't think that's the implication here. I think it's just intended to be workload reduction due to COVID. To my understanding that is not the case. Google said they do it to open gsoc to more people and increase diversity. They think it makes it easier for non-US people to take part due to the summer break times. And for people with summer jobs. And they opened gsoc for people from further institutions.

  385. lskdjf

    ^ dwd

  386. lskdjf

    And I can totally see all those points, that's why I liked the change towards shorter projects.

  387. dwd

    Ah, then I misunderstood.

  388. Zash

    Board members: Who's head of SCAM now?

  389. Zash

    Guus, daniel, nyco?

  390. nyco


  391. Zash

    Hey nyco. You're listed on the website as a member of the SCAM team. Do you know what the status of that team is? I'm wondering because I haven't found any activity since October.

  392. nyco

    for me, I have not been active for at least that amount of time sorry for this it means I don't know how to answer your question 🙂

  393. Guus

    I assume that technically I am - but I've been equally inactive

  394. dwd

    TBH, I think it's too late to arrange a Summit for the "usual" time. I'm not convinced that';s even a sensible thing to do anyway if we're not in Brussels.

  395. Zash

    I'm getting the impression that only pep. was active, and they left the XSF.

  396. nyco

    We can do something online, my company can provide a BigBlueButton

  397. SamWhited

    pep left the XSF? Is there info on that somewhere?

  398. SamWhited

    I was gone for a while, so I'm still catching up on the stuff I missed.

  399. MattJ

    Just a "shift of priorities" I think

  400. flow

    I think I would love an online summit with ~15min talks where people talk about what they did with xmpp recently (given that they are enough people wo want to hold such a talk)

  401. nyco

    yes, definitely something simple

  402. nyco

    we can't have a 2 days long open discussion with 20 to 50 active participants

  403. Zash

    Sounds good

  404. arc

    Dwd sorry! I was conked out hard this morning.

  405. arc

    But yeah SCAM is running fosdem con and we need to get our stuff in to them toward that end.

  406. marc

    > I think I would love an online summit with ~15min talks where people talk about what they did with xmpp recently (given that they are enough people wo want to hold such a talk) +1