XSF Discussion - 2017-12-07

jonasw: I said previous that the motivation xep1 gave for reissuing LCs is for outgoing Council. I came up with some motivations of my own in response to your mail. I don't think that was inconsistent :)

Kev, as I said (at least in one of my drafts), I think that is fine.

I’m still not entirely sure how your original argument actually applies, but it doesn’t matter now, since I find your current argument fully convincing.

The point I'm making is that it wasn't my original argument, it's the one in xep1 and at that time I didn't bother coming up with any of my own (until you mail asked to)

I think my current arguments are stronger than the one xep1 makes, but I would.

oh, I didn’t realise that the argument is literally from XEP1

I was sure that I read something along the lines of (from you) "I think the original reasoning back then was ..."

"The motivation in xep1 is ..."

damn

sorry

I didn’t have my coffee yet

(I can always make that excuse, I never drink coffee)

but I also didn’t have my water yet, which is probably worse

But I would be amazed if anyone not on Council does the level of review that Council should do.

jonasw, same here haha

(Indeed, the questions that the Editors ask them to during LC don't come close)

I found your review of the compliance suite very thorough by the way, that’s way beyond what I as a developer would be doing.

That's roughly the point I'm making - I would expect, for a compliance suite review buy Council, them to have gone through everything in the suite and checked if it's sensible, checked if anything not in the list needs to be, and checked that the list is consistent. For non-compliance suites I'd expect Council to do much more review than that - for non trivial XEPs I expect Council are probably spending an hour+ per advancing XEP to review properly. I really wouldn't expect non-Council to be putting that sort of work in.

Kev: can't we solve the bookmarks issue by requiring servers to transparently synchronize both storage formats?

Ge0rG, that’s an interesting idea

Ge0rG: I think 'requiring' might be hard here, but we could add a server feature to 48 that does that, I think, yes. And I think we could do so without bumping namespaces or worrying about it being Draft, due to it being a new server-only feature for a XEP that previously wasn't server.

Bookmark need to be changed, first have atomic bookmarks

if it’s announced by a feature, I don’t see any reason not to, draft or not, previously server side or not

edhelas: no need to go nuclear!

eheh

no but we have PEP, and multi-items tags now

edhelas, in spec, yes

I'd like, in 2017, to be able to solve a bookmark in a PEP-Pubsub item

in deployment mmmm

edhelas, I have bad news for you.

Bookmarks are atomic at the moment, no?

no they aren't

Kev, but not very fine grained

Pretty sure they are. It's a single payload.

you just save the whole list in an item, so you have race condition issues

Race condition issues doesn't make it non-atomic :)

Kev, you know about the issues though, don’t you?

I'd love to have a bookmark XEP that works like this one https://xmpp.org/extensions/xep-0330.html#usecases

aioxmpp has a weird read-modify-write loop up to three times or until convergence, whicever happens first

edhelas: In the sense of one bookmark per item?

Kev Yes!

we’re not entirly sure it ever converges even if everybody does that algorithm, but it should.

I think that would be fairly sensible, in a world where bookmarks weren't based on iq:private primarily, yes.

yah, a server would have to implement that read-modify-write loop then :)

Zash what is the status of multi-items in Pubsub/PEP nodes in Prosody

See, XMPP is all about database update synchronization.

edhelas, you should first ask what the status of private and persistent pep is ....

I think that the publish-only-if-the-parent-state-is-right XEP would do the job too (for something not frequently changing).

jonasw persistence is there in ejabberd and Prosody now afaik

atomic compare-and-publish for pubsub, Kev? :)

jonasw: M-Link's is excellent as well ;)

edhelas, is it though? I thought only with a community module.

anyways, I wanted to go for errands like an hour ago. the XSF is eating my time!!k

SamWhited, what’s the status about the XEP-393 update? I’m still missing the opt-out and a formal grammar…

(or opt-in, even better)

I've just added a notification to the XSF Board meeting calendar item, that's on the XSF shared agenda. Could someone please make sure that Google doesn't do something stupid like adding that notification to everyone's agenda?

I've set it to 11 minutes, just to make it slightly different from the default.

jonasw: I'm not sure that we're adding an opt out yet. A football grammar seems fine, if unnecessary, but it's not something I'm going to spend time doing right away

menh

I see absolutely no reason not to add an opt-out, to be honest.

*formal, even

I liked the idea of you writing a football grammar. Let me have that, please.

I thought that football grammer is a nickname for some type of grammar representation :)

Kev: do you mean a soccer grammar?

This will be a Liverpool F.C. grammar (if kev can live with that), so definitely "football"

But they are playing soccer?

No, Atlanta United plays soccer, Liverpool plays football.

Ah, but they are playing the same game, right?

Yes, sorry, I'm fine stretching this joke out now

Done, even. I hate phones.

we all do

*wave*

0. Welcome & Agenda

Hi! Who do we have?

I’m here

I'm here

I'm here

nyco?

XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

He might be attending POSS

(an event in Paris that he previously expressed interest in)

Ah, yes.

he is (or was yesterday, where I saw him)

Anyone have something for the agenda?

I've added things to Trello last week

apart from those, none.

I don't think I have anything to add right now

Ok

Nothing from me

Who can take minutes?

I’m mobile, so not really in a position to, sorry :(

if no-one outside board members is available, I'll do it.

1. D&O insurance

I've talked to Peter. His full response is in Trello.

basically: if board still wants to move forward with this, he will. But he estimates it'll be not cheap.

Given his response, and no current (potential) officers asking for it right now, let's close this for now

Aren't we asking for this?

Do we know/remember why we started down this path in the first place?

(I’m happy to close it, fwiw, just curious as to why this has hung around for some long)

*so long

if it's a cheap way to help us protect from being financially pressured into doing something, I'd be in favor of getting an insurance.

Guus: I'm not asking for insurance, no.

Martin: it was put up by Laura, April 4, 2016.

I'm also not entirely sure who this will work out with people in Europe.

From what I can piece together, in 2015 there was a search for a new Treasurer, and the only applicant raised concerns about liability - I don't know if this is what triggered it

Martin: well, somebody brought it up, stpeter would investigate, that was delayed a bit, everybody lost interest.

given that we've not been financially pressured in the past ... 18 years? ... might be a non-issue.

The Foundation is not that old yet, but sure

I know it's dead-cheap in the Netherlands, but liability laws are vastly different here.

Right. I'm not even sure if a Dutch insurance would work with a Delaware company.

but if I'm the only one interested, i'm happy to let this go.

If you want to investigate that, that's fine of course.

Matt, Martin?

I’m happy to let it go

Ok, archiving.

2. Commitments

I'll let Peter know.

I saw that we asked and can reconfirm our Treasurer and Secretary for another year.

Sorry, laggy here. I'm happy to pass on the insurance. But I think we'd need actual quotes to make a concrete decision (more than "it's expensive")

indeed, both Alex and Peter are happy to take on their roles another year. Do we need nyco to make it official?

So I motion we appoint Alexander Gnauck as Secretary for another term.

+1

+1

+1

Done.

+1

+1

I motion we appoint Peter Saint-André as Treasurer for another term.

+1

+1

+!

*+1

Done

Can we have some kind of thank-you for the work they've been doing so far?

I think we have to postpone appointing the Chair again.

Guus: please note this in the minutes, indeed

FWIW, I'm happy to continue.

I just hope that nyco can attend next meeting so we can finish this.

At some point, it'd like to address unscheduled non-attendence.

I haven't yet acted on finding a new ED, so let's keep that one.

Guus: right, I did send that message to the Board list for a reason.

Yes, thanks for that.

but it did not help, sadly.

Moving on

3. Items for discussion

We only have a few minutes left.

Given the post-meeting discussion, unless there's disagreement, I'd like to remove the SPIM item for discussion at Board level right now, until there's a more actionably proposal.

wfm

that works for me.

Fine by me

I'd like to discuss board prio's with all present, but it wouldn't hurt for all of us to prepare by adding their own thoughts.

(as a commitment for the week ahead).

Guus: +1

+1

Sounds like a plan

Added a card

potential survey is based on that discussion, I think.

Agreed

That leaves us with the new card on FOSDEM sponsorship.

I think this is an interesting topic, that deserves a bit more than 3 minutes

(I'm good for another 10 minutes or so)

+1. I'm in favour of it generally, but I think we need a broader discussion on financing and fundraising

We're really bad at both, and I think it's something we need to improve on

MattJ: can you create a card to that effect?

Sure

I propose we then pick that up next week

also given the short time until FOSDEM

4. AOB

I didn't see anything for this raised today

None from me

5. Time of Next

SCAM should get into gear for FOSDEM/SUMMIT

+1W

Guus: agreed

The confirmation for stands has been extended

+1W works for me.

+1W wfm

+1W works for me too

I.e. I didn't get it yet because they are slow

6. Close

Thanks all!

*wave*

Thanks

XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

So what can we do to improve the SPIM situation?

Ge0rG: stop searching for silver bullets.

I feel that to many proposals get shot down because "that won't fix the problem"

(in general, not by you specifically)

many partial solutions will at least help. Currently, we're not making any progress.

well mainly because there are no silver bullets

if there was a perfect solution for spam, email people would have found it years ago, probably before xmpp became a thing

agreed.

Just to add to the Last Call XEP-0387 discussion, because im to lazy now to post to the list

solutions should fall neatly in 2 categories: 1. That won't help at all. 2. That might help for a little bit

obligatory link: https://craphound.com/spamsolutions.txt

lovetox: don't be lazy. Not everyone is reading this MUC

SamWhited, it seems you are not aware that 0048 on pubsub is not supported by prosody or ejabbered as of right now, so recommending that is a bit over optimistic

lovetox, not even ejabberd? I thought ejabberd can do that

only one server to my knowledge

that conversations server, because holger added it

i dont know if this has landed in the community version of ejabbered

but i doubt it

haha jonasw never saw that, thanks :)

and even if, this still is a feature then that only one server in its newest version supports, still not something that should recommended, we strife for good interop with the compliance suite

lovetox: that was discussed on standards@ I think. Or at least in the last council minutes

no, the argument revolved around what clients actually use

and yes of course all clients use private storage

nope

but even if not, we cannot recommend something that is not supported by servers

Movim relies on private PEP node for Bookmarks, only that

compliance is here so we have good interop between clients and servers

edhelas: Movim also doesn't work on my server :(

not to promote next level features

Ge0rG Prosody ?

lovetox, remember that people wanted to have MIX in there

lovetox: https://github.com/xsf/xeps/pull/554

edhelas: yeah

Ge0rG soon :)

lovetox, I think the actual debate is whether we want the compliance suites to be something which describes what we want to have soon or what is now

I think SamWhited wants them to be a description of what we want to have.

in my opinion it should reflect something that is good right now

I don't actually understand that discussion; both of them support bookmarks in PEP just fine. Do you mean the persistence thing?

not what we hope will happen sometimes in the future

ping Zash

SamWhited, they dont, they are not supporting 223

this means all bookmarks are open world readable

which is not something that we want

maybe the xep doesnt require it strictly but it should

ENOCTX

i dont know the wording anymore

and also this is the reason why nobody really wants to implement this

Zash: bookmarks in PEP

if gajim gets bookmarks over pep, we test if the server supports 223 fully, if not, we purge the pep node

and transfer bookmarks to private storage

Not yet

lovetox, <3

good job :)

We've got persistence but access control isn't configurable yet

SamWhited, if you count "bookmarks in PEP work until the next server reboot and are also world-readable, then they’re gone" as "working", I think we might have a problem. ✏

fair enough

Zash access_control is the last missing thing to move Bookmarks to PEP in Prosody ?

persistence is one thing, support of access_model = whiteliste, the real important one

Either way, servers more or less support them and I think we want to encourage that support to be better and document what servers need to give a good experience, not just document what everything is already doing

SamWhited +1

I was pretty sure they already supported private nodes though, but I guess not?

edhelas: No idea

SamWhited, fair enough

I think the main mis-understanding is then whether the suites should document the current real deployment or the future. there seems to be disagreement on that.

SamWhited, private nodes are supported sometimes

but often whats missing is the <publish-options> feature

SamWhited, maybe add a paragraph to this in the introduction, making this absolutely clear (even though I think that the introduction -- which I haven’t read until now, admittedly -- makes it quite clear already that the suites are meant to advance, not do describe)

that lets the client discover this whithout pulling the whole node config

pulling node config in turn is also not supported by all server

lovetox, it's missing because there are problems with xdata definition

dwd: which MUA are you using? The plaintext quoting it generates doesn't make it possible to distinguish what you wrote from what you are responding to.

TIL how to force kmail to show a multipart/alternative message as html even though it contains a text/plain part.

I find it ironic that the HTML message contains *foo* by the way.

SamWhited, XEP-0001 has a minimum of 14 days. I hate that.

It has had 14 days of LC already, after that it's up to the editor

Or at least, that's how I've been treating it. First one is 2 weeks, after that I've done 1 week LCs for lots of things

hm, sure, but a re-issuance after council switch?

I’m seeing this in light of Kevins argument

which I found much more convincing than the argument in XEP-0001 by the way

I still don't see what the council switch has to do with anything; they'll still have plenty of time to review it.

I just want to know what kind of crappy council member would not comment on a last call on the list and only in the meeting...

I'm not sure I care about their input in that case

I think the compliance suites documenting what you need to be a sensible server/client in the current climate, with an eye to the future, is sensible.

So if you currently need to implement X in order to interop with large amounts of the network, we can probably put it in on that basis. Similarly if something isn't well deployed but is stable and the clear direction, we can put it in for that reason.

MIX is a direction, but not stable, so I think putting that in would be wrong.

But '49 is widely needed for interop, so I think we list that.

Maybe the compliance suites should be split into two documents. One that's an implementation report, documenting what most implementations do now. Other is more like a vision statement, describing what we want XMPP to be like in the near(?) future.

I think a vision statement might be a sensible thing, but I don't think it needs to be dated like the compliance suites, which are snapshots of what we expect people to implement at that time.

Kev: It would be tho, it'd be "what we think the future should look like, as of $today"

Yes, but we can keep that updated, there's no particular value in stamping it and calling it done.

Maybe numbered semi-immutable documents aren't optimal for that purpose

But it'd be cool to have something of a history of what we thought the future would look like

Useful for comparing later, to see which, if any, goals we got anywhere with

I think we'd probably have that just through the attic and the changelog.

I suppose

Could be a blog entry, the exact form is probably not that important

Having a vision is good tho.

Anyway, that is very much not a hill for me to die on - but I think a single living direction document would do just fine.

As is knowing the current state of things

I do think it's worth stamping a date on the compliance suites, which are meant to be "What do I need to implement right now" sort of things.

Which is sorta inbetween.

The IETF used to have implementation reports of some kind IIRC

zash: that didn't work

> it seems you are not aware that 0048 on pubsub is not supported by prosody or ejabbered lovetox: You mean because of the use of publish-options?

I think strictly speaking the use of pubsub#persist_items in the 0048 example isn't 0060-compatible, because 0060 says that publish options MUST be registered or rejected by the server, and this one isn't.

... isn't registered.

Holger: i have it on my todo list to register that publish option

daniel: Ok. FWIW I think it would make sense to just specify that arbitrary node config options can be specified as publish options and that they will always be handled as preconditions.

i agree

it's probably impossible to get that through council

my last change to xep60 took me a 6 month to push through

Though the result would be equivalent to registering each and every node config option as a publish option to be handled as precondition.

if I change the wording to something like 'any unregistered publish-option must be treated as a precondtion to the node configuartion option of the same name or reject if neither a registered publish option nor a registered node configuartion exists" the already existing entry in the publish-options registry is obsolete

and should probably be deleted in order to not confuse people with an already very confusing XEP

daniel, FWIW, I think your idea is sensible, and in case of doubt this could always be made a feature (#publish-options-config-precondition) or something

at some point the xsf will need an archaeologist to dig up why certain decisions to certain xeps where made in the past

I wish those things would be documented properly.

Every XEP should contain a strong rationale for surprising decisions.

Holger, jonasw: if you word it that way you are essentially kissing 'per item overwrite' goodby

which i'm not necessarly opposed to

daniel, how?

well if you say that any publish options that shares the same name with a node config is a precondtion; how would you create a per item override that shares the same name

Would have been easier if it the three kinds of things weren't in the same form

i guess you can still register that with a different name

what is a per-item override?

Zash yes

jonasw, read the XEP we are talking about

I have, but it’s been a while :/

jonasw, i don't really know myself :-)

jonasw: What it sounds like.

jonasw: Node configuration overrides per item.

7.1.5 Publishing Options <- just read that

Zash, at first I thought "per item override" is something abou treplacing existing items, but that didn’t make sense

is it setting options per item?

ahh

okay

that sounds ill-defined as heck

And unused afaik

no shit

I personally don’t have a problem with burning that :)

per item override or the entire xep?

not that I would matter :)

Per-item access control is a desirable feature tho

Zash, is it?

hm, maybe for the social network things

meh

the path of least resistance is to register persist-items as a precondition and move on with our lives

> Holger, jonasw: if you word it that way you are essentially kissing 'per item overwrite' goodby Sounds good to me :-)

> the path of least resistance is to register persist-items as a precondition and move on with our lives Yup, works for me as well.

created both https://github.com/xsf/xeps/pull/556 https://github.com/xsf/xeps/pull/555

feedback on the wording in 556 welcome