XSF Discussion - 2021-01-15

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 ✏

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?

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.

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.

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

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

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

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.

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

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

Apart from XMPP, almost everything is terrible

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

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

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.

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

It just happens that DOAP -> RDF -> XML

SamWhited: could you imagine writing a simple yaml2doap converter?

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.

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

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

No, I just want this format bikeshedding to stop

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

At least the XEP table thing

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*

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.

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

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

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

I've adopted DOAP in 2019

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.

I agree with everything you just said

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

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.

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

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

Nobody is doing that

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.

Ge0rG: it can't.

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

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.

yeah, you can help improve the documentation!

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.

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

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

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

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

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

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"

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

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

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.

or json2doap, or whatever.

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

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

SamWhited: I used a text editor as my tooling.

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

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

Ge0rG: yes, I have already volunteered to do that

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

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?

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

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

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.

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

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

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

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.

or two screenshots. or an array

also multiple resolutions

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

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

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.

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

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

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

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?"

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

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?

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

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

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

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

also gamification effects!

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

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

Having this data is useful for so many things

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

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

mathieui: no need to convince *me*

err, Guus*

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

I remain skeptical and happy to be proven wrong.

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

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

(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 )

Right.

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

(not just outside the core community)

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.

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

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

Zash: badges!

YES

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

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

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

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

Oh, source code

And then parse its stdout.

It even comes in a docker thingy!

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

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

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

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

“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?

Shouldn't there exist RDF (documentation) viewers?

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"?

EMOJI!

Ge0rG, "Core Core" ... ‽

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

Zash: "Core Server"

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?

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

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

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

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

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.

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

MattJ: good point

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

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

SamWhited, DOAP is both, thankfully. :)

It's not and I think you know it.

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

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

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

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

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

Ignore :)

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

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

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?

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

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.

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

Link Mauve: which is why nobody ever achieves Draft.

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

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

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

lskdjf, good idea!

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.

lskdjf, is that better?

SamWhited, yes, I am part of these people.

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

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.

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

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

or make the number collapsible? :D

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"?

SamWhited: NO!

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.

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

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

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

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

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

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

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

Ge0rG, ah, I see. I misunderstood your idea

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

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

Yes, like that!

MattJ: Us maintaining more things?

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

Zash, changing stuff in HTML or elsewhere is roughly equivalent

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

and that's an "if"

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

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

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

Exactly that

or maybe for developers that are allergic to XML?

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.

↑ that was my original idea, btw.

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

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.

I totally agree

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

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

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

We are not committing to that

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

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

one spreadsheet, all implementations.

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

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

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

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.

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

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.

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

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

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

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.

Ge0rG: I'm not sure what you mean?

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.

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

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

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

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

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

yes, absolutely

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

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

Ge0rG, oh, true

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.

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

I already did write down an informal description of one possibility

It's in the mailing list somewhere.

Or maybe it was here, I forget.

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.

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

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

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.

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.

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.

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

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.

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

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

SamWhited: those features provide multiple benefits

the work has been done

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.

there is no reason not to make use of them.

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

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.

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

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

Zash: what is clients.json?

SamWhited, the list of clients used by the website curretly

Ge0rG: not necessarily, mine is just on GitHub.

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

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

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

https://github.com/xsf/xmpp.org/tree/master/data#software-directory-readme

SamWhited: you can link to a raw file on github

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

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

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

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"

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

SamWhited: copy&paste the template RDF.

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.

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

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

SamWhited: there is a DOAP validator.

SamWhited, and this is terrible how? Actually?

Ge0rG: we've been through that too

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

Worst case, we fix bugs we find

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

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.

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.

moparisthebest: `csv2 | sed | xml2` then 😉

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.

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.

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.

If someone wants to write a schema, fine.

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

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

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

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.

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

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

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

SamWhited, yes

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

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

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

Ge0rG, I was thinking of the CI pull requests only

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"

SamWhited: yeah, that's the theory.

?

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

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

oh sure

gotcha

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

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

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.

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

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

Link Mauve: storing them permanently will add another hidden cache

It is a well-known cache.

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

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

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

It’s based on the sophia crate.

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

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

mathieui: but that would make unrelated PRs also fail

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

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

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

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

Like... host a validator? 😁

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

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.

It’s actually Rust.

Link Mauve: that would work, except for server timeouts

The JS is only for the presentation on XEP pages.

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

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

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

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

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

Link Mauve, is there a rust csv parser? 🙂

Ge0rG, yes.

Link Mauve: awesome job!

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

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

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

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

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

Yah, that.

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

Authentication is hard.

At least it's not "login with facebook"

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

shiny

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

np, I find it handy

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

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

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

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

and allow them to modify the registration

And can we have DOAP support for individual features?

Oh glob

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.

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

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

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

(the Board meeting, that is)

Someone else want to Chair, then?

"Go for it?" :)

First item on the agenda: XML or JSON

YAML

CSV

Blank Verse.

OK.

1) Roll Call?

Here

ENOQUORUM?

Seve, arc ?

I don't think Seve will be joining us today

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

wfm

2) Try Again Next Week.

Let's try again next week.

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

What about FOSDEM or Summit?

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

Pretty clear someone from SCAM needs to weigh in on that

Who was SCAM‽

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

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.

Ah, great

What "something else"

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.

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

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

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

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

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

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

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

^ dwd

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

Ah, then I misunderstood.

Board members: Who's head of SCAM now?

Guus, daniel, nyco?

Yes?

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.

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 🙂

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

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.

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

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

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

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

Just a "shift of priorities" I think

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)

yes, definitely something simple

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

Sounds good

Dwd sorry! I was conked out hard this morning.

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

> 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