XSF Discussion - 2017-02-22

looks like today is the last day of the 0280 LC. Time to open some more PRs

Could somebody have a quick view if https://github.com/ge0rg/xeps/commit/0ff5f4f30baca8a1cf5cc9fe5af55bbffb7d879c provides a clearer language? Original: https://xmpp.org/extensions/xep-0280.html#which-messages New: https://op-co.de/tmp/xep-0280.html#which-messages

please :)

Any native speakers, please?

Ge0rG: overall, I'd say I like the new wording better. It's clearer, and the specific meaning of the RFC-CAPITAL words is better IMO.

Only thing I'm thinking of is the third sentence. The original says (correct me if I'm wrong) a message of type="error" that is in reply to a message that itself was eligible for carbons, should be carbon-copied as well. To me it implies that other messages of type "error" that /aren't necessarily/ in reply to a message that was eligible for carbons don't have to be carbon-copied.

But in the revised form, it says that messages in reply to another message eligible for carbons are the __only__ messages of type "error" that may be carbon-copied.

I know it's a little bit nit-picky, but in my eyes the two sentences don't mean quite the same thing.

devnull: you are right. I have implied the last rule here

That being said I don't really know the spec itself, so it might not matter anyway. I'm not sure.

devnull: CCing an error only makes sense if the error-causing message was CCed as well

devnull: from original: "A <message/> is not eligible for carbons delivery if it does not meet any of these criteria." - if this rule is applied, I can make the 'if' an 'iff'

Right. It's a little stronger of a statement.

I'm all in favor of bold statements.

SHOULD is really MUST except for odd cases. I thought the consensus was that Carbons' choice of what to archive was deliberately loosely defined. This is a major change.

s/archive/carbon-copy/

I'm still asleep.

Carbon's choice to let implementations choose what's copied was a deliberate change to get through the previous LC, yes.

I think the proposed change makes things less clear, rather than more clear.

But I thought that was the exact time to use SHOULD/MAY--when there's a degree of choice between implementations.

SHOULD doesn't mean there's a choice.

It means there may be rare times where it's appropriate not to, but you can expect things to break unless you do it.

Kev: my gripe is with the "A <message/> is eligible for carbons delivery if it is of type X and condition Z" wording. Do you happen to have a more concise suggestion?

I'm really not a fan of all the MAY or MAY NOT in that spec.

"a <message /> SHOULD be delivered with carbon copies if it is..." ?

There shouldn't be any MAY NOT, because that's not 2119ish.

I can downcase the SHOULD/SHOULD NOT in the diff to make it less formally required, then the MAY/SHOULD from above should apply

Ge0rG: You could extract the 'is eligible if' out to the top of the list with something like 'If following these rules, a message is eligible for carbons delivery if any of the following are true:' or such, I guess.

devnull: that would achieve the exact opposite of my goal ;)

Kev: thanks, I like that.

Now I've started a rewrite of the MUC rules based on the SHOULD/NOT wording, but I might be able to manage that.

Kev: should I make it an 'iff' while I'm at it?

I'm not sure it adds much, given they're optional rules anyway.

I really need to read up on why they have been made optional.

Short version: We couldn't agree on MUST rules.

isn't that exactly what a standards committee is for?

If we make them mandatory, I want them done 'properly' for future use in a mamsync-ish world, while (at least) Dave is firmly opposed to any changes that would make current implementations of the spec not compliant.

Kev: your stance sounds very reasonable

it’s experimental, there should be nothing wrong with implementations suddenly being incompliant.

Kev: mamsync and MIX

The counter argument is that it's de-facto Draft just by the number and state of implementations.

Ge0rG, A standards committee can either agree on a set of rules, or note that there isn't a single set of rules.

I don't agree with the argument, but it has legs.

Kev: the <private/> -> <no-copy/> change mandates for a version bump

Kev: the discussion(s) during the LC of 280 show that it’s not a draft yet for reasons.

if we are bumping anyway, we can as well do it properly this time.

Ge0rG, I actually wouldn't complain about that. What I didn't want to see was a bump for some small case.

Ge0rG, While versioning does mean we're stable against incompatible changes in XEPs, we do have a problem in allowing the old (and often well-deployed) versions of XEPs to be easily found, though. I can think of a few XEPs where the old version has similar deployment to the current.

Ge0rG, And as an SDO, part of our job is to reflect reality as well as dictate what that reality ought to be.

dwd: how is it bad to have an old version be easy to find (as long as it is explicitly marked as old)?

(I think dwd means the problem is the other way round – it’s hard to find versions of XEPs which are old but well deployed)

dwd, Kev: do I have your blessing to move forward with defining 'SHOULD' rules based on current practice and what I have gathered so far for a new version-bumped 0280?

Ge0rG, No. You need consensus from standards@, not permission from an Editor and a Council member.

dwd: I'm approaching you as two of the Elders Of XMPP, not in any formal function

preparing a PR may help to have a focused discussion on standards@ though, imo

Ge0rG: I think it would be interesting to see what such a spec would look like, at least. Other than getting me to stop yelling about not liking stuff, my opinion's not worth much though.

That is, I don't think you need anyone's blessing to write the patch. (Getting it merged is another matter...)

Kev: incorporated your wording idea, https://github.com/ge0rg/xeps/commit/f0e432c15ee3b811a4065abc4baa158ba5fae0c9 / https://op-co.de/tmp/xep-0280.html#which-messages

Ge0rG, If you can build a case to break compatibility, and the majority of those implementing or planning to find it compelling, then please do so.

the MUC and the is-not sentence are removed as the same meaning is covered by the "if and only if". A separate diff will be presented for MUC cases

-xep workgroup queues

Guus: XEP-0142: Workgroup Queues is (Deferred, 2005-05-09) See: https://xmpp.org/extensions/xep-0142.html

dwd: "break compatibility" would mean "require implementations to run two versions for some time"

The previous debates about 0280 on standards@ have shown that consensus is impossible to reach. I'm attempting the "MIX mode" here, by trying to write down what is the most elegant solution in my eyes.

Ge0rG, You're welcome to suggest a specific solution, of course. But you do need to obtain consensus.

dwd: if I fail to obtain consensus, 0280 will return to 'Experimental' and do yet another round?

Ge0rG, I think we *had* consensus over the current loose case.

dwd: last year's LC failed due to lacking consensus in the private/no-copy debate, IIRC

How would consensus be achieved? No opposing voices on standards@? A majority vote in members / board / council?

Ge0rG, Same as the IETF, I've always assumed. In practise, that's a majority of the Council believing there is consensus.

Council

Ge0rG, for reference: https://www.zash.se/carbons.html

(and don't think that's a complete list)

I can't imagine that an experimental xep becomes carved in stone because it is widely implemented. At least the server implementors could provide both versions in parallel to make the upgrade path easier without breaking anything

I've added more controversy to https://op-co.de/tmp/xep-0280.html#which-messages in the form of new MUC rules.

Ge0rG, indeed...i mean that's what we have namespace versions for

if we wouldn't want to change anything because *implementations*, then we might as well disregard any namespace versioning ✏

^

Tobias, Sure, but if a spec has lots of implementations and yet is in Experimental, one has to wonder if our standards process has failed.

Or just it's something that needs solving sufficiently badly that people want to implement regardless. That doesn't mean it's the *right* solution.

Kev: +1

dwd, sure...nevertheless it shouldn't stop changes to carbons under an incremented namespace

So you're saying the process has failed, but we don't yet know why?

No, it means the process is working.

The point of experimental XEPs is to get implementation experience, no?

The process is only failing if we then say "Oh, people have taken part in this experiment, so we can't make changes".

jingle file transfer is at its 5th namespace i think...swift doesn't work with all of them, it could with some work with more versions than it currently does

And to improve based on that experience

*namespace version

Kev, Either Carbons works well enough for widespread deployment (which it clearly does), and its status doesn't reflect that because our process is broken, or else we haven't managed to produce anything better, in which case our process is broken.

Right. But the reason we haven't accepted (rather than produced, as there were solid suggestions IIRC) that 'anything better' is people clinging to "there are implementations, so we can't change things".

Which *is* a failure of our process, as I said above.

dwd, what's the issue with allowing changes to carbons under an incremented namespace version?

Incidentally, I *do* think that the wooly wording makes it 'good enough' (although I don't remember the nocopy implications and whether that should block it).

Kev: no-copy was suggested as a reusable replacement for the <private/> element that is only defined and used in 0280.

then there was a long debate about the merits of MUST-NOT-when-private and SHOULD-NOT-when-nocopy

Kev, As for implementation experience, that's not what Experimental is for. It's for discussion. Draft on the other hand means "appropriate for further field experience", and one can argue the market has decided on that.

and now it looks like at least the author and some other people agree to remove <private> and to use <no-copy> instead. And IMO this is a privacy-affecting and breaking change, so it requires a bump

Ge0rG, Please do work on building consensus. And note Zash's list of implementors; I'll be especially interested in seeing if those people want to update.

dwd: I am confident that was not the original point of Experimental. Maybe we've changed over the years so it's now what we say it's for.

Kev, I look forward to your proposed changes to XEP-0001. :-)

dwd: I'm pretty sure I will fail to gain consensus in the sense that all implementors agree to follow the bump.

Ge0rG, Consensus, not unanimity.

dwd: That'd be the xep1 that says it wants people to implement Experimental XEPs?

Ge0rG, doesn't have to be all, the majority of the actively maintained would be enough

Kev, "While implementation of an Experimental protocol is encouraged in order to determine the feasibility of the proposed solution, it is not recommended for such implementations to be included in the primary release for a software product" ?

dwd: I had the pleasure to coordinate a CVE with a dozen of client-only implementors in the context of Carbons, recently. It was a multi-week process which involved just a single-line change in the code.

it's probably also the one that says Experimental XEPs can be expected to receive major changes

dwd: Sounds like it's encouraging implementation to me.

Ge0rG: So you have contact data of most relevant people! :-)

Certainly not saying what you originally said, which was that Experimental XEPs weren't for implementation.

Holger: would you implement a bumped carbons that fixes MUC-PMs in ejabberd?

Kev, Sure. But not in the way Draft does: "the specification will be basis for widespread implementation and for deployment in production environments. As a result of such implementation and deployment experience, the protocol may be subject to modification, including changes that are backwards-incompatible."

Indeed.

So from 0001, it is legitimate and expected to make breaking changes in both 'experimental' and 'draft'. Thus I would not consider "gaining consensus from implementors" a requirement for moving an XEP forward.

I don't think "There are different stages of implementation" is the same as "Experimental XEPs are for discussion not implementing", which was with what I took issue.

Kev, OK, I'll accept that.

Ge0rG, also Experimental changes don't have to go though council, while Draft changes have to go though council

BTW, while we are at "breaking changes". My Carbons improvments depend on an addition of an element into XEP-0045, which is "Draft", but has no namespace version.

Kev, Nevertheless, I'd still argue that Carbons is de-facto Draft given the state of implementation.

/ s/depend on/would be even better with/

Ge0rG: I think ejabberd's 0280 code complies to your new text, and if it doesn't it will be fixed, yes.

Kev 9:59 ? :)

Oh, nice copy/paste.

Holger: what about private/no-copy?

Kev 9:59 The counter argument is that it's de-facto Draft just by the number and state of implementations. :)

Ge0rG: I'd continue to honor both. Or does it help anyone to ignore <private/>?

the state of the implementations was nicely reflected by the CVE, not?

Heh.

Holger: honoring both is perfectly fine, my point is rather: you should indicate that you honor no-copy by advertising the new namespace

Ge0rG: I mean I understand why you'd want to remove if from the spec for cosmetic reasons.

Tobias, In as much as there were a lot of them, in production software, then yes.

Ge0rG: Sure.

Ge0rG: ejabberd already advertises support for :1 and :2, we can easily add :3 to the list :-)

Holger: could you kindly review https://github.com/ge0rg/xeps/commit/5881e42fe7e56adb13ab29c46e1d88b903fdf07b and https://op-co.de/tmp/xep-0280.html#which-messages for readability and potential logic issues.

Ge0rG, BTW, I have no clue why you'd equate breaking changes with no need for consensus.

dwd: I'm not sure how you draw the conclusion that I do that

[11:04:21] ‎Ge0rG‎: So from 0001, it is legitimate and expected to make breaking changes in both 'experimental' and 'draft'. Thus I would not consider "gaining consensus from implementors" a requirement for moving an XEP forward.

I also think that's outright wrong, and that it's not expected to make changes to a Draft XEP, but that the option is there if needed.

*breaking changes

Kev, The following sentence in XEP-0001 agrees with you: "Although such backwards-incompatible modifications shall be avoided if at all possible, deployment of a Draft protocol in mission-critical application may not be advisable."

Ge0rG: "Clients SHOULD ignore carbon-copies of MUC-PMs related to a MUC they are not joined to." Are outgoing clients expected to add <x/> tags to PMs as well, or how would other clients detect outgoing PMs?

dwd: 0001 allows to make breaking changes in 'experimental' and 'draft'. Therefore I do not consider the statement "client implementors can block breaking changes to such an XEP by denying consensus" as a valid excuse.

Holger: yes, that would require changing 0045.

Holger: a client could also disco#info the bare-JID of course.

Holger: and a carbons-enabled server that knows about the MUCciness of the MUC could inject an <x/> into the carbon

Holger: maybe I should put all of these into a separate section?

I wouldn't like the idea of requiring clients to do a disco#info.

Holger: me neither

Ge0rG: Aren't those details a bit out of scope?

Holger: they are in-scope for both 0045 and 0280.

Holger: unless we want a new XEP that only covers MUC-Carbons

I'd add the <x/> tagging to 0045 so that we can avoid cluttering 0280 with a list of possible strategies.

Holger: that is exactly what I plan to do. But it will be even harder to get consensus for that.

Holger: so "add <x/> tagging everywhere" --> 0045. "use <x/> tag for carbon-filtering" --> 0280

That would be my solution, yes. The downside is that the filtering then depends on modern 0045 implementations, but in my book that outweighs the ugliness of disco#info / MUC presence tracking.

Holger: and a server still could inject <x/> tags into messages it knows are from/to a MUC.

Right.

I'm not going to propose _that_ into the XEP ;)

Yes that's unnecessary.

Are there other corner cases with carbons? Transports? MIX? anything I forgot about?

I think direct MUC invitations (XEP-0249) are not carbon-copied although that might be desirable?

Holger: which rule do they fail at?

Ge0rG: type=normal messages are only copied if they have a body.

0249 explicitly forbids a body, IIRC.

do we need a <copy/> xep334 hint?

do we want one?

I think we do (and I suggested that before).

Ge0rG: Then again, if the receiving client bookmarks the room on invitation, the other clients will follow. As everyone (*cough*) is using PEP bookmarks these days, this will be instantaneous ...

Holger: yes. Right. But even then, what if you are not on your primary client right now?

Holger: I'll change the invitation wording to include both directed and mediated

So servers will have to search for <x xmlns='jabber:x:conference'/> ...

Holger: some MUCs also send a captcha request per normal message from bare JID prior to allowing you to join.

But I'm sure it's fine to deliver that to any subset of the user's client, as long as it includes the one joining

I mean generally there's two options, either we teach 0280 about each such special case, or we teach the XEPs that define the stanzas in question to mark them appropriately (using 0334 hints or whatever).

*clients

Holger: MUC-PM should only be reflected to MSN sharing clients. How can you teach that?

'sent' ones, that is

MUC PMs should die, but it seems they don't, no matter how often I repeat it!

They're special and I think it makes a lot of sense to mark them as such, regardless of 0280.

But apart from those, I'd try to avoid adding all sorts of weird rules to 0280 and rather have the sending entity mark stanzas appropriately.

Holger: you can't just kill them, they are useful

Holger, indeed...need to add some code to Swift that it will uses the real JID if it's known

I mean this is really about addressing an account vs. addressing an individual client. If I did XMPP from scratch I'd carbon-copy everything sent to the bare JID and nothing sent to a full JID.

Currently, I'm getting something between zero and two copies to my clients, and sometimes I even can't respond.

We're not doing if from scratch so I'd go for hints instead, whereever it makes sense.

Ge0rG: My usual rant is that MUC PMs are only useful to the very small circle of active XMPP community members, i.e. to us. Nobody else uses anonymous rooms. But I figure we are not a negligible part of our target audience :-)

Holger: no, MUC-PMs are useful to people who use clients that don't auto-fallback to the participant's real JIDs

All clients would do that if they weren't all written for geeks.

Holger: 0045 is a pretty horrible specification. You can't argue that implementations of it are broken because they are geek-focused

I'm only arguing against "MUC PMs are useful".

We're reimplementing them in MIX because we're still geek-focused.

Holger: IMHO, proxy-JIDs in MIX are another, much more severe, side-effect of the geek-focusedness

Holger: it doesn't take very much to fix MUC-PMs though.

Well same thing in my book. Anonymous rooms.

Anyway I'm aware that I'm quite lonely with my view, and I don't want to spam this room by repeating myself.

Holger: and there is MUC-light for non-anon easy chatrooms

Yes, and MUC/Sub. Everyone does his thing because there's a strong demand and we don't get done with MIX.

> it doesn't take very much to fix MUC-PMs though. I'm all for your 0280 updates.

+ PM tagging.

Yay! \o/

Why is &xep0249; creating both a note and a hyperlink?

so if you print the document you got still all the useful information

updated https://op-co.de/tmp/xep-0280.html#which-messages - must return to work now

Phew, just made it with #434 before the LC ends.

Ge0rG: XEP-0280: Rewrite of the 'Messages Eligible for Carbons Delivery' section #434 https://github.com/xsf/xeps/pull/434

Ge0rG, Raise it on the mailing list, please.

dwd: raised. ✏

Hey all, I won't be able to attend today's Board meeting.

ralphm: you won't miss anything, last week's board meeting is still ongoing :D

Ge0rG, :-p

the longest one ever

I've noticed that many topics consists of an |-separated list.

Some of the items are often key-values

Zash, I did argue that Subject ought to be dropped in MIX because it's never used as a subject; just as a set of URLs and a description.

dwd: So it could be derived from name, description, other named fields in disco

And you could supposedly generate a legacy topic for MUC compat (if you have that) from that as well

Maybe the actual topic should go back into each message?

Sane real time threaded UI would be .. interesting

yes.

Who's here for the board, then, excusing ralphm?

_o/

Think that might be a bit *too* quiet…

meh

MattJ: Are you around?

3/5 for quorum, BTW.

Thought as much

so... :'(

Here

Yeah…not looking like much of a goer really :(

oh

Oh! Signs of life.

Sorry, another meeting overran

np

Right, the Trello board looks a bit out of date. Going by the last minutes, they seem a little out of sync too, anyone got an insight into where the most current items for discussion are?

…or shall we scrub down the Trello board and start with whatever's most pressing?

wfm

there was the Summit, then GSoC, now we have space

yep

So, GSoC, still an open card on Trello

we have submitted, well Kevin has

Do we know when we're likely to hear back?

27th, IIRC

(thanks Kev)

Thanks Kev

https://developers.google.com/open-source/gsoc/timeline

OK, I've added the 27th to the Trello card

In the spirit of continuing the spring clean of the Trello board: D&0 quote, still in play?

(Board is here: https://trello.com/b/Dn6IQOu0/board-meetings )

I guess that's a question for Peter?

Yup, his name's against it, so I'll leave it where it is for this week

Moving on…Marketing project, has Arc's name against it, assuming we should leave that where it is too…?

Guess so

Righto

isn't it related to FOSDEM? in which case can be closed?

Maybe. Could also be related to the SCAM team from last week - continuing support for the marketing activity

But I guess we could archive it and create a new one for SCAM support

According to Trello it was moved into "Commitments for the week ahead" Oct 19, 2016

That's quite a long week...

OK, I'll archive it

So I guess we're missing, or I am at least, background on this

Yeah, me too, I'll add something to the items for discussion for next week's meeting

OK, so, what's next...

Recruitment of editor team members…I vaguely recall us trying to address this right at the start of the year

OK, leaving that parked for now, and we're running low on time. Board priorities for 2017. An impressive entry from nyco

I think new members need to come from the pool of folk already active in the community. Given the work that Sam and others have put into improving the editor team process, there is hopefully a lower barrier to entry now

The quote was for indemnity insurance for directors, so we can have a treasurer again, wasn't it?

since the board has been elected, indeed we have no goal

to me that is the most important item

moar promotion? moar surveys? moar software? moar... what?

nyco, your list is great. As a wishlist...

but it's partial

It's already long :)

it is just me listening to a fraction of the community

The main thing that needs to happen is converting it to action items

partial, in the sense that it is not neutral

Ideally small things we can tackle, prioritized

MattJ, before actions, agreeing

yeah, and spit, get people to commit

no, no, not spit, but split!

ooooops

We perhaps don't need/want to spend usual board meeting time on that, but we could find some separate time to brainstorm

agree, more interactive, and must deliver something, not just meet for the sake of meeting

it makes you think?

I agree that everything listed would be great to have

But what are the things the board can do about it?

prioritise

get people to commit

check on the delivery?

in other words: do something

That's my point... what is 'something'? :)

what we will prioritise, like in priorities

Ok, first item on that list: "Make clients look and behave like the most modern and popular chat/voice clients on the market"

let's agree on what's most important, in one, two, or three items

How are we going to do that?

UX sections in the XEPs? :)

one action

remove old ones from our lists

maybe through financing?

like crowfunding?

Crowdfunding for what exactly? Where would we spend the money?

like bounties?

Assume we already have money (because we do)

Money isn't the issue. What do we do with it?

I'm returning all the questions to you MattJ: what is your view?

:)

Money is one issue, it was raised at Summit

but that's only one example

I wasn't at the summit, but I fail to see it as an issue

Either in the amount we have, or our ability to raise more if we need (whether that's crowdfunding, sponsorship or whatever)

make clients... modern... my contrib is my market analysis, for which the outcome is "the three generations of IM"

if we want to follow that logic, then we have to deliver on full text search in archive, chatbots and chatapps, integrations, etc.

that may that the shape of XEPs, of software

MattJ, some have money issue, it is an information

so let's put money aside?

I'm saying "we" as the XSF, to be clear

how would you "make clients modern"?

"we" can spend some, call for donations, whatever

but make client modern is only one of the so many items

there is more

so what are this board's priorities for this term?

I'm personally not a client developer. However my opinion is that client developers need more UX guidelines.

sure, I agree

But someone has to make those guidelines

I am a client developer. I'm not sure I agree.

Great :)

correct, that's why I say set the prios and get people to commit

But I'm certainly I don't want the same people responsible for protocol specs giving UX advice :)

Kev, you're oooold!

Kev, as a client developer, do you agree with the overall goal/priority of "modernizing clients"?

nyco: Maybe, but that's not to say I don't think clients need better UX. I'm just not sold on them all needing the same advice.

sure

I'm a client developer. I dont need guidelines. I mean having some would be kinda nice I guess. But it's far from being a top priority

taht's your opinion

MattJ: I think 'modernising XMPP' is a very high priority of mine at the moment, through my software and the spec work we do.

a lot of client devs are... just... dev... without any UX knowledge

Given that daniel and Kev both produced some very nice clients, I think their opinions have weight

daniel: you are a client developer who should WRITE the guidelines. Things like "DND presence from one of the user's clients overrides all other clients' presence"

so some need guidelines, maybe not advices

I think responsibility for that is shared between implementors, spec writers, Council and Board, so I'd be happy to see anyone doing sensible things.

But my idea of 'sensible things' might not be the same as others.

daniel: +1 to Ge0rG

I'd be very keen to hear Board ideas on what they think they can do to modernise XMPP.

MattJ, I have done pretty modern clients as well, many of them, so I have weight, as experience with working with iOS/Android/web devs AND UX designers

maybe we can have an Easy XMPP WG? or less-formal-group

Ge0rG, +1

so, board prios

If someone wants to take action how about supporting JC in creating inverse. That's a single page (slack like if you will) version of converse

Jc agreed to do it if he gets the funding

it is not only "modern clients", there are plenty more stuff that needs discussion

what can the board do?

The xsf could support a funding campaign

daniel: Well, sure, but if people are paying JC for work on inverse, I'd like people to pay us for work on Swift please ;)

neutrality

Quite, that begins to impinge on neutrality

daniel, now that's the kind of sensible action item I'd like to see more of :)

I'd like to put a shameless plug of https://wiki.xmpp.org/web/Usability/Glossary - we need to get our terminology straight before we can fix usability

Ge0rG, +1

I'm an advocate of XSF neutrality, but the line has to be drawn somewhere

It even has like an actual price tag

promotion is certainly a huge prio

not sure if highest

If the XSF had so much money that they could pay a UX person to look at whatever clients people wanted looked at, and give advice, I'd be all for that, FWIW.

Kev, +1

If we can't promote or sponsor good XMPP projects, I think that's somewhat sad

MattJ: I agree, and it keeps coming up. Perhaps a board action should be to revisit what the position is on neutrality

I think we can generally agree on that a good web client is missing in the xmpp world

Indeed

Martin, we had that discussion at Summit

daniel: I think so, but which of the people working on such things should get funding? :)

I mean I'm not saying it's the xsfs job to do that

so, we are still the BOARD PRIORITIES, right? ;-)

Maybe the XSF could directly pay for some liberally licensed generally useful things?

But someone wanted an actual action item. There is one

nyco: Discussions are discussions, not a decision. There's clearly still a grey area here around neutrality.

yes

Make toolboxes of things that are useful for projects. Rather than supporting a particular one directly, help them all.

Kev, I think that would be an obvious requirement, yes (re. licensing)

but as a board, we haven't set our term's priorities

MattJ: My point was 'generally useful' vs. 'funding a particular codebase'.

nyco, if you ask most people at the moment, we should be tackling spam instead of UX :)

MattJ, that.

I also would argue that spam is a higher priority. I've started getting 3 or 4 messages a day the last few days.

No matter how good the UX is otherwise, that would probably rather kill it.

so, we should have a dedicated meeting on board priorities? or a big consultation? or a survey?

then we select our top thre prios, for example

Board has done a survey in some past years.

So, board-wise, we've run over, and we need to figure out how best to collate and then rank everything that's just been discussed, and others that haven't been. Polling the membership could be useful...?

and then we set goals and expectations, we put actions, and commit

I'm not sure it's directly led to action the membership wanted, but it might be a start.

some tasks can be paid...

Feels more transparent to poll the membership, and derive goals from there, rather than just super-charging anecdote

I'm fine with surveying the membership, but I don't think there will be prizes for guessing the results

at least we will have numbers

The non-client devs all say "UX", while the client devs say "resources are the problem, not UX advice"? :)

my delivery is some kind of ad-hoc survey... without weight at all: how can you trust me?

I think let's call the official meeting over for today, but the discussion is good :)

Kev, that's a major problem to understand

Kev: that's what the poll at the summit said I think

daniel, poll? what poll?

I think if Board can find a way to fund some research into combating spim (not just coming up with specs for reporting it, but proactively detecting it), that would be probably the Board's biggest contribution in recent years.

FWIW.

Yeah, board meeting is over I think, +1w for the next

nyco: what do client developers want

Martin, wfm

(And doesn't touch on neutrality :))

In fact (yes, I know meeting's over), I would really like Board to find something they can do in this space to advance the state of spim detection.

I know some research does exist on this.

daniel: I want the XSF to buy me a yacht.

I think I have some very very smart contacts at Uni who might find this an interesting area, with funding, in fact.

I somehow can't imagine the pidgin developer sitting at home thinking 'I would really love to implement carbon copies right now. If I only had some ux guidelines'

hehehe

well, not exactly, you put it like UX = UI

the UX of Carbons is a tough beast.

UX can explain the "why"

Ge0rG, right

https://code.google.com/archive/p/psi-dev/issues/592

perfect example

autotraslate

Why do it? It cancels the fuss with the priorities for the same login on multiple devices. I keep very helpful. May assist in the development of assistance would be read chudnenko :) visit us in the conference will discuss all =)

nyco: a perfect example for what?

of misunderstanding

something that explain the value of an evolved user experience

clearly the guys of Psi+ want to stay in the ICQ era

all the priorities usage have changed, the world has changed, and continues to change, faster and faster

nyco: we don't need to make _all_ XMPP clients _modern_. But we should give candy to the ones that are.

we talk

nyco, I use a console client, and you won't take it away from me

about multi-device now, same stuff in real time in all devices (Carbons, MAM)

nyco: I don't see where the psi+ developer said that they want to be more like icq?

I love you guys. Seriously.. it puts a smile on my face whenever I open this chat

</not-sarcastic>

oh a board member who is veeery late! ;-)

yea my phone died, im not getting alerts

im hoping the new battery arriving today fixes it.

beautifully, it shit the bed while helping me navigate through London to have open source beer at a bar basically located in an alley with some gnome developers. that was fun.

Ok, my considered proposal is this: that we (the XSF) provide a process through which XMPP software developers can submit proposals for funding projects

MattJ: Please consider my comment on spim, too, that was very very serious.

But I think what you say sounds sensible too.

Details can be hashed out, we could even put proposals to a full membership vote if we feel that's the fairest option

Sure, but any pointers on that?

does the XSF have sufficient money to establish such a funding process?

I'm not aware of any research into combatting spim, but it sounds like you might be?

what sayeth?

MattJ: 1. solve spim. 2. profit!

MattJ: I think before we do that, we should get involved in something like Outreachy

I suggest not only one prio

MattJ: I'm sure I came across some before, ages ago, but if there's serious interest in the XSF funding such a thing, I think I might have some contacts I could at least ping and discuss.

If Board wanted me to.

https://en.wikipedia.org/wiki/Outreachy

nyco, this would become a vehicle through which to turn your wishlist from that card into reality. We can use the priorities when deciding what to fund/not fund, and we can encourage software developers to apply, etc.

not only funding, maybe it is not only a prio

apparently spim is

"make clients more modern" may not even go through funding

Make things more better!

nyco, "make clients more modern" is not a fundable project

we could pay the spim senders to stop spimming.

MattJ, it could be

MattJ, fund inverse, swift, conversations...

Well I'm not going to advocate funding it :)

Ge0rG: I'll send you an invoice for not sending you spim then.

nyco, you're missing the *actionable* part

There seems to be a disconnect between "make the clients more modern" and someone actually having to write code

Zash: to the XSF

MattJ, it's not only about code

If you want to put together a proposal for someone professional to review the UX of one or more clients, that would be great

MattJ: that void must be filled with: a) help the developers understand UX problems b) provide UX guidelines c) do the coding

professional UX review should be somewhere between b and c

Ge0rG, oh no, no, no, UX is much wider than that

Kev, ok, I'll kick it into the next board meeting's topics

Thanks.

Board may have other ideas on how to help with Spim, but this seems like a discussion point.

Kev, agree with anti-spim initiative being one of the top prios... not the only one though!

Sure :)

nyco: we can't solve all UX problems. we need to learn crawling before we can grow wings.

Ge0rG, there are lots of shortcuts

Arc, is Outreachy similar to GSoC? or would individual projects apply?

nyco: like jumping from a skyscraper?

Arc, I think programs like that are worth it in their own right, and not a substitute for funding developers who are already intimately familiar with XMPP

i.e. these would be on parallel tracks

MattJ: I agree that developers should be funded, but I don't think its the XSF's role to do that. Outreachy, perhaps.

I'm concerned by the XSF's lack of diversity

Then likewise, come up with some action items

MattJ: I'm not 100% certain how projects get into Outreachy, but I know who to talk to about that. Its more formal than GSoC in some ways (they're actually considered employees/interns), but more human in others

employees/interns of Outreachy?

well Outreachy is one way to address it. Its only available to minorities; women, LGBT, and in the USA racial minorities (black, hispanic, etc). That allows it to get grants

MattJ: yes. because they really want to help those minorities not only get work experience but also a formal work history

a vast majority of Outreachy interns are women.

That works better, because most projects (possibly including the XSF) would not be set up for handling employees

well, yes. we could of course. we have an EIN. but yea i dont think we're prepared to do the rest

I'm currently establishing an employer an the process is pretty deep

SamWhited, any insight into what happened with the PR I submitted? git was acting weird (which IMHO is fairly normal for git)

I'm just curious what went wrong

Git was fine, you just included commits from the previous 0.6 version that weren't actually used in master (eg. You based your branch on an old branch)

btw what do we have these days IRT modern XMPP client C libraries?

Oh, you squashed the commits when you merged my previous PR?

Yah

Sigh

Master is always canonical in our repo

Or the source of truth, or whatever

It's not a big deal, I just rebased your new branch too

In any repo I have say over, the whole repo is a source of truth, but I know that's not the way many git users, or github, feel

MattJ: your DVCS is inferior! stop arguing! :D

I'll be more careful next time

Actually, even if the while repo was the source of truth, you must have based it on an old commit

Because the conflict was the two <initials>

Before I pushed git was acting weird, asking me to merge stuff that didn't make sense

hg does that to me all the time. And then there is this crazy text editor with three different window-things

I'm convinced that some people just have a mental model suited to git, and some hg, and that's that

you like hg too?

Some people like emacs. Some like vim. Then there is the rest of the planet.

who doesn't like hg, it just has superior usability

:-D

I disagree; I know how to use both, and I think HG is much less usable.

Tobias: hg has horrible usability. It is mockig me every time I try to use it.

*mocking

HOLY WAR!

i mostly use git through a GUI so I don't things up, which was quite easy to do a couple years ago

Yeah, CLIs have terrible usability for git

Or hg

MattJ: So they rewrote/rebased commits you published?

Zash, yes. It's a checkbox in the Github UI iirc

I don't recall if I did or not, but I probably did

waqas, sure..but even at CLI level i find hg more usable than git, but hey...either can interoperate with both repos, so hey

The data model is basically the same too

my pet peeve with hg is "hg pull" which tells me it knows what I want but it won't do it and go RTFM

Ge0rG: Didn't you say fetch?

Zash: ah, yes. it was 'fetch'

It's been a long day, and my train is arriving in 10 minutes. Good night everyone :)

`hg fetch` is some deprecated plugin that sounds like it does what `git pull` does.

again, anyone know of a modern XMPP client library for C?

But there's `hg pull --{update,merge,rebase}`

libstrophe, but it's probably not modern

C is not modern.

Define modern

it has a maintainer, work has been done on it in the last 12 months, supports session management and MAM

the list on xmpp.org includes mostly dead projects

Didn't we define a process to kill dead projects from the list?

i didnt make it to this week's meeting, but last i knew we asked Council for 2017 guidelines

hmm, maybe I'll go for Rust this time. I'm starting a new commercial project, has to be portable.

But the 2017 guidelines are not going to solve the dead projects problem

Ge0rG: my proposal was to have projects re-apply, and ask them for modern compliance information

so we need the 2017 guidelines to start that process

wasn't the consensus to just have them reapply yearly, but accept any XMPP, regardless of compliance?

Tobias: yes, but compliance information is important to ask and report still.

Arc: can't we just have the projects reapply?

nobody said they wouldn't be listed if they didn't comply.

inactive projects could be sorted lower and lower down

Arc: but now the process is blocked until a new set of guidelines is defined

Ge0rG: it can't be that hard for council...

2016 guidelines, whats new?

I love Rust, but beware: I think it's still 3 years out or so from having enough library/community/infrastructure support to be usable for complex commercial products. YMMV

Arc: 2016 guidelines are neither finished nor implementable

Can we please just start a dead projects grace period now?

im not opposed to that

Somebody needs to post to jdev then.

We are still in the eternal board meeting btw

How many?

MattJ, how many what?

Open meetings

did the board meeting not happen this week?

I saw some trello cards got managed

SamWhited: well, its portable now. I understand what you're saying

LoudMouth is dead. My fork of it needs to pivot, it was going more glib/gobject but that lacks portability, and the asm.js for gobject stuff is effectively dead

I thought gobject/glib was supposed to be super portable these days? (I'm curious, because I don't actually know, someone just told me this recently)

i could ease back into coding for the next week by refactoring into Rust

SamWhited: its not portable to asm.js/webasm nor to mobile. i wish it was. it was suppose to be.

ah, right

I've invested a lot of energy into Vala, but the Gnome foundation at this point is pivoting away from that and to Rust.

that's why I grabbed a beer with the gnome guys in London

I never did understand the point of Vala

back when I started Maja looked very promising

Vala was intended to be a GObject-native language. and it is, it works great. But its tied to GObject/Gnome.

yah, having such a domain specific language felt pointless to me; no matter how nice it was.

like much of Gnome it lacks the developer interest to really shine. even basic things like llvm support are still years off

i just browsed around, Rust seems to lack a decent xmpp client library.

I could spend about a week to refactor all of lightmelody into rust

Link Mauve sent me one recently; I haven't looked at it to see if it's "decent" or not yet though.

Can't remember where it is right now

https://gitlab.com/lumi/xmpp-rs

Can I use it yet? No, there's still a lot of work that needs to be done before this could be used for anything.

:-/

It’s very much wip, you may want to talk to lumi in jdev@ about it.

so, yea I'll be spending the next week refactoring lightmelody.

He started it right after FOSDEM.

no its ok. this kinda needs to happen anyway

Arc, your website seems down.

doing a rust refactoring is more about me than anything. i need something to keep from being bored right now, and im still on doctor ordered break until the end of the month. refactoring and learning rust should be low impact

Link Mauve: what website

lightmelody.org.

oh there's no website there, just a landing page

also it looks like the old server is down. i should actually do the migration today instead

as soon as the new battery arrives from amazon this afternoon i'll call in and get it rebooted

Link Mauve: lightmelody vs loudmouth.. goal is to be 100% api compatible with loudmouth 1.4, but shedding all the old dependencies. so eg it uses gio instead of gnet. it also adds OAuth2 auth (gsoc student project last year) and a few other key features

loudmouth is usable, just bitrotten. too many outdated dependencies.

there's a lot of software that still uses loudmouth, including some surprising ones like random games on Steam

That sounds useful!

there's an up-side; if i port it to Rust, we can solve the one API variance to loudmouth 1.4 which is the LM_Message_Type which overlaps with gobject's builtin "type" method of lm.message

it can still expose the same C API.

that way it could ALSO offer a Rust API.

somebody with pelican knowledge here?

I use it

not sure if that counts as knowledge

in the land of the blind, the one-eyed man is king.

regarding our client/library/server lists, I wonder how you'd handle data tables in dedicated files and filter them at build time

Tobias, probably a special anchor that gets replaced through sed… I don’t think rST supports inclusion of other file

there’s a PR to add some markdown syntax for this

yeah..we already use SED to insert the XEP list

makes you wonder why use pelican at all :)

pandoc all the things

better use xslt for everything

pandoc -t json | jq . | pandoc -t whateveryouwant

yeah..back to the beginning with XSLT + Server side includes

:D

the happy world