XSF Discussion - 2019-09-19

Who is currently responsible for the next compliance suites?

MattJ: me!

Oh, nice :)

MattJ: say that again after you tried convincing me to add something.

We'll see :)

maybe he knows of someone else that is going to suggest something that Matt thinks is a bad idea.

MattJ: you might bribe me by rewriting the introduction section with something useful

No, Ge0rG guessed it in one attempt

Did we agree that splitting a XEP doesn't require council?

MattJ: I can't give a definitive answer to that, valid for all circumstances.

Editorial changes are up to the editor?

to the author, normally.

iirc the MIX split wasn't put through council

I don't really mind either way, just would be nice to know how many battles I need to fight

And with whom

Doing most productive standards-based stuff feels like a battle

:D

MattJ: you could start by saying what exactly you plan.

Ge0rG, and extend the duration of the battle? :)

MattJ: this is getting too meta for me

Me too, just wait for the PRs

scary

inb4 over 9000 XEPs

Just split the existing ones on each heading.

When are we finishing the XEP-0060 split?

Zash: after everybody implements MIX

everybody including libpurple?

is "everybody implements MIX" the new "when duke nukem forever comes out"?

Pidgin with MIX support running on Hurd

jonas’: yes.

It used to be PlayStation 3 vs DNF vs DM8000 for me, but eventually, all three happened.

In-progress MAM diff: https://matthewwild.co.uk/uploads/stdin-s2ilB8Kj

Board meeting time

Ralph sends his apologies.

Seve is here, being very mobile

:D

MattJ , nyco_ ?

Here

_o/

thx to Daniel for the minutes

Carré!

MattJ do you want to take this one?

what?

0) Present: Guus, MattJ, nyco_ and Seve

Any minute-taking volunteers?

that awkward moment when everyone's looking at the same person.

I'll do them this time.

and while volunteers ponder, anyone with topics for the agenda that are not already on Trello?

Thanks Guus

None here

Thx Guus, no new item from me

1) Topics for decisions

1.1) CC by-sa, https://github.com/xsf/xmpp.org/pull/409

is the full webiste under CC by-sa?

also the XEPs?

From a quick skim of the discussion, it appears we lost the licence from the website?

because we have a lot of contributors

https://github.com/xsf/xmpp.org/graphs/contributors

117

no need for a CLA, I guess

The XEPs have their own policy

that PR is obsolete anyway, we can trash it

I can add a CC by-sa (latest) in each newsletter individually, at no cost

I remember something happened and that PR had to wait for some reason, but can't remember why

there is no legal terms, nor any terms of service

From what I read in the PR, Goffi wants the newsletter to explicitly state that it's CC By-SA licensed, so that its content can be translated shared on other sites.

IANAL

I see no problem with that in itself

JC mentions that the entire website probably _should_ be under this license anyway

We may just be missing to add that on every newsletter and that would be it?

for the newsletter, on my side, no worry to make it CC by-sa explicity, for all starting from now, or individually

Goffi mentions that it still is not, and by adding the license at least to the newsletter, the problem thta he's having would be fixed.

that's a micro issue, what about the macro ?

Well, we can first add it to the newsletter, and then resolve the website

If we at one point had the website under https://creativecommons.org/licenses/by-sa/2.5/ and the license reference got lost during a website makeover, I have no issue in adding https://creativecommons.org/licenses/by-sa/2.5/ to each newsletter.

I think allowing distribution and translation of the newsletter is higher priority

Definitively

https://creativecommons.org/licenses/by-sa/4.0/

why only 2.5?

https://wiki.xmpp.org/web/News_and_Articles_for_the_next_XMPP_Newsletter#Thx_and_CTA.2C_Call_To_Action_.28remove_this_mention_before_publishing.29

added

2.5 is what we had. I don't know what the differences are between 2.5 and 4.0

so it this PR obsolete now? in which case we can reject it

1.5

differences between 4.0 and 2.5 is 1.5 :)

you're welcome... :/

Guus, what evidence do you have that 2.5 is what we had?

JC's comment in https://github.com/xsf/xmpp.org/pull/409#issuecomment-369945588

Right, I was looking for more

pulling up wayback machine now...

Like an evidence? :D

In the interests of getting things moving, I motion that we publish the newsletter as cc-by-sa in future, and tackle the larger issue of the website separately

agreed

ok, all newsletters from now on are under latest CC by-sa anybody against that?

+1 for that motion

Seems like we're in agreement - Seve?

I raise the question: what version

I motion "the latest"

Just thinking about if the XSF apart from the author could have the rights?

but I'm totally +1 with it

4.0 seems fine to me, unless someone has a reason to object

we are pointing to news, that we write, there will be some copy-pasting though, which is legally authorised

I don't have a reason to object.

Can't find a reference to an exact version in the wayback machine on short notice (it ... is .. slow).

no, not 4.0, but "latest", which means when a new version is published, we auto-upgrade

nyco_, I'm not sure you can just do that

you can

let's not auto-upgrade. We don't know what we're agreeing to, by doing that.

or want to

Right

I got lawyers in my coworking space, I'll confirm

then when a new version of the license is published, we raise the question again

cool

or we can just trust the license issuer to be just more competent than we are

Ok, I'll respond to the PR with our feedback

thx MattJ

Thank you

1.2) DOAP

so we agreed to not auto-update?

(for the minutes?)

No auto-upgrade, no

Hi, I’m here to answer any question you have about 1.2.

Guus, the PR is for 4.0 on the newsletter, so I think that's what we will go with for now

ok

if anyone objects, shout, but I think that can be addressed separately

DOAP PR is https://github.com/xsf/xmpp.org/pull/409/files

Nope

Copy/paste fail. DOAP PR is https://github.com/xsf/xmpp.org/pull/594

I'm having concerns

Technical or philosophical?

I have just asked my lawyers: you can publish content under "CC by-sa or later"

> Technical or philosophical? can it be another option?

nyco_, thanks for the info

- DOAP as a protocol seems pretty new/unused - no updates in its git history for over a year. Is this the right tool to be used for this? - Adding more details to software listing on the XSF website is a slippery slope, as discussed before. - Asking for DOAP data would add hurdles for new projects to be listed - some projects already don't take the effort to do this simple listing - I don't want to make this more difficult.

1) doesn't concern me. I think the alternative is making up something of our own, which has zero tooling/etc. - DOAP is RDF, which has a bunch of existing tooling and projects around it

- DOAP is used at least by CPAN (Perl repository) and PyPI (Python repository), I expect other ones too, and there were minimal additions I had to add to support our usecase.

DOAP data should be optional for new projects (or any projects) to be listed. The more you provide, the better. But that should not block

AppStream might be another to look into.

DOAP could structure the community a lot, as well as contribute to SEO

2) I'm curious what the concrete problems are here. In the past discussions have been about how we can objectively verify someone's support for a certain protocol. Here they are self-reporting, and we just state that

3) it's optional, not a hurdle

3) if some projects do it, your listing has to do it to 'keep up'

For your third point Guus, I expect DOAP to allow relaxing the renewal requirement, for instance if a project just got a new release in the past year we could automatically consider it as the most recent renewal and avoid the manual one.

Guus, and I'm fine with that - I think it's a great thing for a project to have

Link Mauve good point.

Guus, that means more incentive for projects to become better

this specific DOAP format may seem overkill though

The exact rules are of course to be discussed.

nyco_, I agree, but it can be automated

and I don't see a better/simpler format than someone we just cook up ourselves

nyco_, the main reason I went for this format was that it was already used elsewhere, had existing parsers, and so that other people could use them for different purposes than what we originally thought about.

*than something

In this example you can see here: https://linkmauve.fr/extensions/xep-0048.xml Where it says "Software support", I would appreciate a lot a link or a comment to a page explaining how this data/support info is obtained, so we state it is not crafted by us

Link Mauve : that's what I used "may"

This isn’t just about xmpp.org, but for any consumer to derive data from our list of XMPP software.

Seve that link doesn't work for me.

Link Mauve : good point, that's why I mentioned SEO

https://i.imgur.com/lx9zSpJ.png

Guus, Chromium is known to have issues with running JavaScript on XSLT-transformed pages, you may prefer to use a pre-rendered page.

Do we want to apply this before the spec has been ironed out?

Guus, maybe you can check my screenshot

Link Mauve I got a 404 actually, but nevermind. Seve's screenshot is useful.

I quite dislike that XEP example, by the way

that software support table is awesome

because?

I'd hate for discussions around 'why is my implementation not listed'

"because you didn't provide a DOAP file"

Because you didn't provide

"here's how"

ok MattJ, you win this time

That's why I'm saying we need that other page explaining this

Seve, good point, we can add any such link once we have one written. :)

I don't like how that almost forces people to use this at all.

I don't get that "force", please explain?

Guus, it doesn't force, but obviously if they do this then they benefit

and I really see no problem - why wouldn't you do it?

It's not like we're asking for money

I have some other frontend/interface points to discuss, but maybe that should go into another conversation

By not complying, you're at a disadvantage.

So why not comply?

Guus, the idea was to do it similarly to the w3c HTML5 pages, which for each section (for us each XEP I guess? At least for now) you can see which browsers support the feature.

What are the barriers?

I share Guus' concerns about putting pressure on software projects owners, who are already struggling

nyco_, this removes the annual renewal requirement already, so they can spend their time elsewhere

We may even create a web page where you can input your software data and it will generate a beautiful DOAP file for you to host on your website.

why not comply: time/money and a spec that's not ironed out.

To me, that gives you more reasons to keep up with your project. I find it a bit "weird" to have a client but not a list of what do you support, etc

MattJ there is still non-code maintenance to be done

Guus, note that this PR doesn’t modify the XEP page at all atm.

https://caniuse.com/ ?

It only adds the data to Pelican for further use.

>We may even create a web page where you can input your software data and it will generate a beautiful DOAP file for you to host on your website. Problem solved! ✏

moparisthebest, this kind of website could perfectly use the DOAP data we will gather.

Link Mauve : agree a form can simplify people's lives

Link Mauve true.

nyco_, I can add that as an actionable.

I am strongly strongly in favour of this, and we can only make it better and easier over time

moparisthebest : and the shiny new https://www.caniemail.com

I see absolutely no reason why any project would be barred from participating

I feel the same excitement!

we need our own canixmpp.com

That was the reason I proposed this PR as early, so we can discuss it and figure out the points to be resolved before going full out with it. :)

yeah, looks like we can build so much with only the small adoption of a format

The meeting is over time. Do we want to vote on approving the PR in this meeting, or provide some actionable feedback on it?

looks like we have a consensus that DOAP can be cool

we have not agreed on the details and next steps yet

that's my feeling

I would like to ask for some frontend tweaks if possible (in the sense of, if those can be done by somebody)

Seve, there is no frontend yet (in this PR)

Ah, right hah :)

This is just some tooling to fetch the data

I went too far

and then more PRs can follow, which actually do something with it

Seve, note that there is no frontend work in this PR, it only adds a "doap" entry for each software we have in our lists, and a simple Python parser for them.

If the question is only to add a link to software listing on our website (but I think that the PR also includes some kind of script?), I'd not object to just that.

what does the parser do?

so let's continue that discussion on the next board meeting?

I would be ok with voting for this PR

Yeah, I think we're going to have to call this one unfinished. I have another meeting to attend in a few.

Guus, it parses a DOAP file and adds the data to Pelican’s internal structs, for further use.

Feel free to continue discussion afterwards

I could remove it from the PR if you want to only add the doap URLs.

2) Date of next

+1w

+1 ✏

+1w wfm

I need to run too.

Thank you everybody! thanks Link Mauve for being present, that helps a lot

and Guus for the minutes, we love you!

And to you all for running the board. :)

You should run next year!

see: council and board elections! 🙂

i think having the software list on xmpp.org list the compliance suite status is very helpful (and somewhat overdue) for users. it is fine to get your weekend project listed on their. but users need to be able to quickly figure out in what state a client is before clicking the link. and doap files seem to be a good way to figure that out automatically. also the reverse thing (show which software supports a given XEP) is nice as well. especially for libraries. (the list should be less in your face and also collapsible; but that's details)

The design of the table in the XEP was edhelas’s work, kudos to him for that, but that’s a first attempt.

We obviously can improve on it. :)

Now that Pelican has access to the status of the XEPs per client, we could automatically select the relevant compliance suite badge.

peli-who?

The website generator used for xmpp.org.

i see

yes that would be super helpful. i mean right now the user will have to click through each website to find something that is actually good

it might also bring more visibility to the compliance suits themselves

sonny, you may be interested, ↑

Link Mauve, yes! I'm working on the proposal today and will send it to you

for review

sonny, the whole DOAP thing might play well with it.

indeed

See the messages since 15:50:49.

> i think having the software list on xmpp.org list the compliance suite status is very helpful Daniel: for that, a simple tuple of `"compliance-suite": 2019` and `"compliance-level": "advanced-im"` would be more than sufficient

DOAP is significant overkill for that matter. I see how it's useful, but I really would like to have the CS level in the software listing rather sooner than later

which was one of the points of the Badge.

Link Mauve: is there an elegant way to make use of implicit dependencies in DOAP? i.e. I don't actually do anything with RSM, except for applying it in MAM

Or: I'm using 0049 only for Bookmarks

It might not be worth listing at all?

Maybe.

Ge0rG, DOAP is purely descriptive, it would be up to consumer scripts to derive data from it.

Also for user-facing lists I expect we wouldn’t show 0059 or 0049 at all, instead display Feature: Bookmarks.

“we” being any random consumer script.

Ge0rG, !

Link Mauve: so I need to enter all the dependencies manually, explicitly?

If you want to advertise them, I’d say yes.

Link Mauve: is there a mid-term URL for the style.xsl that I can use on the RDF file checked into my git?

Ge0rG, I have it at https://linkmauve.fr/extensions/style.xsl (just updated it), but I’m not sure about CORS things.

Do you even need CORS with XSLT?

> Unsafe attempt to load URL https://linkmauve.fr/extensions/style.xsl from frame with URL https://op-co.de/tmp/yaxim.rdf.xml. Domains, protocols and ports must match.

Link Mauve: so how can I commit it to source control and have it renderable?

Ge0rG, use xslt-proc as part of your website’s build system?

Or rely on the browsers’ XSLT processors by making sure you serve it with the correct Content-Type. ✏

I'm building my website from a different repository.

Link Mauve: so how's this for now? https://yaxim.org/doap/yaxim.rdf.xml

Also why is 0030 even versioned 2.5rc3?

Ge0rG, I’m not aware of short-name in DOAP, and neither is the DOAP owl.

If you want to invent new properties you have to do them in a different namespace.

so should name be the long name or just "yaxim" then?

Just yaxim I think.

As an implementation detail of the xmpp.org Pelican integration I started, it should match the name used on xmpp.org.

ah well, it will be fun with Bruno the Jabber™ Bear

Link Mauve: that list has many supplementary XEPs now, no idea which ones to kick out.

Ge0rG, otherwise it looks good. :)

Link Mauve: awesome!

Link Mauve: why is the xsl referencing ../style.css btw?

it makes self-hosting moar complicated

I think because PulkoMandy has a the sample DOAP files in a directory, with the XSLT and CSS in the parent.

ah well. I won't ever touch that again, anyway.

Is there a more elegant way to make the DOAP apply for Bruno as well as for yaxim, than `cp yaxim.rdf bruno.rdf`?

ln -s?

Also no, you’ll have to change the name probably.

Link Mauve: how am I supposed to change name and desc... yeah

cp

cp is more elegant than cp?

Template it somehow?

cp+sed>cp

Sigh.

Yeah, I think automating it is the way

Zash, that’s UUOC. :p

Re-posting my in-progress MAM diff: https://matthewwild.co.uk/uploads/stdin-s2ilB8Kj

lovetox and jonas’ ^ hopefully it addresses some of the issues you have asked about

> and also implement , and clients that depend on these fields MUST verify [...]

Good catch

Bug in the thing or in the text?

I think the text, but looks like I already fixed it

MattJ: will you also handle my preferences-as-a-tristate remark from standards@?

Tristate? Which email?

Ge0rG, preferences have been removed :)

(they will be submitted as a separate XEP)

MattJ, so assuming i use after-id and I want the second page? will i just make a new request with a new after-id or do i RSM?

Daniel, it's confusing because there is overlap, but RSM seems to not be enough

Zash: (c) from https://mail.jabber.org/pipermail/standards/2017-November/033762.html

Daniel, so I would imagine before-id/after-id should be used for filtering, and RSM only for paging (as it was designed)

and I just need to figure out if/what text should be added about that

It's great to dig out years-old mails that nobody responded to.

Ge0rG: We added that to Prosody at least, right?

MattJ, so to answer the question on the second page i'd be using RSM?

MattJ: I suppose that you'll add preferences into a separate XEP, then. That would be a great opportunity to sneak it in.

Zash: please read all of it.

Ah

Daniel, yes, at which point if you only have after-id in the query and are using <after> in RSM, you could drop after-id with no change in the results you see

But that wouldn't be necessary

right. and/or I would be in the slightly confusing situation where i have an after-id and a rsm after that are different?

Yep

If you find it confusing, just specify one or the other

One selects the query range, one selects the page

But you could change the range to begin at the start of the page you want to request, and you'll get the same results

right. so 'count' is not the full archive

Right

I suspect this will be quite a pain to implement on the server side, fwiw, need to investigate that

But the goal is to solve real problems that people are having with MAM (as clients), so I want to make sure these changes solve those problems before going much further

i always thought it was supposed to fix server side issues?

MattJ: are you going to write a security section and/or other words regarding the client having to match the query ID with running queries and verify the sender ID? If not I could maybe volunteer to do that

most clients seem to be fine with just abusing RSM for that

I can include that, yeah

Made a note

I think abusing RSM is fine in general, and I'm not even sure it's abuse... if you look at the archive as a stream of messages and the client wants successive pages

It just gets messed up in corner cases, such as where people want to fill a hole in the past

ah. because you can’t have both

Yeah

Also, <before> in RSM has a slightly different meaning

<before> in RSM means you want the page before the id you provide

before-id doesn't select the page, you'll still get the oldest page first

This probably needs some extra clarification in the doc also

MattJ: you should also have a section on "Order of events", for clients that desire a mostly-historically-linear access to the log

Rough description of what it would contain?

i.e. fetch MAM before enabling carbons / sending presence-available, then immediately close the gap :>

Right

That's originally what this section was: https://xmpp.org/extensions/xep-0313.html#sync

a nice how-to for clients

Very nice.

and then it just didn't work, because of the race

and then Bind2 never happened

so I documented the race problem and postponed the how-to for a brighter day, when it was fixed

so I'd like to make bind2 happen

or bind-not-2, whatever it takes to get something done

MattJ: MAM-sub

because it's pretty easy to fix this

just gimme MAM-sub: an atomic switchover from MAM to live traffic, given on a date/id passed by the client; auto-enabling of "sent" carbons, delivery of all received messages, similar to the Carbon rules but with no forwarded wrapper, immediate acking with mam-id of outgoing messages

ah, yeah. wiping of all MAMed messages from offline, delivery of the remaining offline messages

keep 0198 and session binding out of it.

That's not what I thought "MAM-sub" meant.

MattJ, Zash: https://gist.github.com/ge0rg/5ae3365196a0c046fc596bbf707fdc15

MattJ: this will solve all MAM problems, except for MUC-PMs

and it's sufficiently easy to make me wonder why it's not there yet ;)

all MAM problems?

Daniel: that was a slight exaggeration.

It will only solve the problems I'm bitching about for two years.

i've been using. gather last_id; enable_carbons, send presence, fire mam query for years w/o any known issues

sure a "get mam-id for sent messages" would be nice

(i also feel like we've talked about that a week ago)

Daniel: yes, it works, at the cost of client side deduplication

what are you going to dedup?

offline messages?

Offline, online and MAM results

Also my database schema requires messages to arrive roughly in chronological order.

well yes you need dedup but online + mam result will rarly happen

Rarely is not never

Mobile connections may be very slow, especially in Germany

sure. like i said you'll need dedup. but traffic wise or what ever you are concerned about it's not an issue

i mean you are getting like 1 duplicate message or what? who cares

Daniel: your XMPP client will never succeed while you have that attitude

Everyone knows success depends on a perfect protocol first

🤐

There is actually one other issue with synchronizing MAM. How do I decide whether to ring the phone notification sound or not?

delay

wait until catchup is complete. crossrefenece with messages received from your other instances. take chat markers into account. and then bleep once if there are messages in the new queue

Daniel: regardless of whether it's a fresh sync or just a reconnect after 10mins of lack of coverage?

yes

i mean depends on what a fresh sync is to you

I just installed the client

are you downloading the entire MAM?

i use what i described in catchup situations. first install isn’t catchup

The current beta is downloading 31 days, I'll probably limit it to 7 or so.

Great MattJ that will certainly help to fill holes

i just wonder is the field request not enough to detect fields

do we need another feature?

sure its one less roundtrip

but are we going to add extended2, extended3 now for every field we add to mam?

though if i look at pubsub i guess thats not a problem

^^

https://xmpp.org/extensions/xep-0030.html#appendix-revs > Version 2.5_rc3_ What's up with an rc version?

For 2 years?

Zash: yes

wat

Let's all show openssl how much we care about them adding SRVName and xmppAddr support to `openssl x509`: https://github.com/openssl/openssl/issues/9950 https://github.com/openssl/openssl/issues/9951

:)

Step 3: Reopen https://github.com/letsencrypt/boulder/issues/1309

Don't we need to fix the CA/B stuff before?

Boulder, the software, could support it. Imagine if the XSF ran an XMPP-only CA (again). :)

Doesn't mean Let's Encrypt has to have that feature enabled in production.

That part would probably require fighting the CA/B forum

Right. I guess we can do both at the same time

Pay for lobbies to change CA/B stuff, and implement opt-in support in boulder

lovetox: I don't intend to add an extended2, but move to draft

And the field request wouldn't cover the page flipping feature

MattJ, move to draft doesn't prevent MAM42 from adding #extended2, or #extended38

That you add it in 313 or in another XEP, it's the same to me

I originally planned another XEP, but it makes more sense here

More than prefs did

XEPlosion

in sasl anon, what's the "trace" for? If the client want to optionally give some fingerprint info? (that can't really be trusted I guess as it's not specified(?)

In the olden days you'd put your email there, for some reason. ✏

That's up to the service require such info I guess?

IIRC that's what anonymous FTP sites said in their greeting messages decades ago.

Daniel, Zash, sonny, https://github.com/xsf/xmpp.org/pull/594/commits/f4b561b7cc80a890076e6b37c5393db0eddc6915

For now it’s a text version, but I expect to use badges instead once we want to integrate it on the website.

It's not 2020 yet...

Ge0rG, I can move back to 2019 if we want to enable the badges before that.

But I think targetting 2020 might be a good idea.

Ugh, when we accepted https://github.com/xsf/xeps/pull/812 I forgot to check that xs:unsignedInteger exists: turns out it doesn’t.

This PR probably wanted to use xs:unsignedInt instead.

I’m sorry about that. /o\

vanitasvitae, ↑

Oh you're right.