XSF Discussion - 2019-10-10

Ge0rG, do we really want to add a deferred xep with a likely namespace bump in the future to the compliance suites?

flow: which one?

0. Welcome

Who do we have?

_o/

o/

Guus, Seve?

ola

Hi!

1. Minute taker

Would be good to have one again, since we have had no minutes for a few meetings now.

I can't today, sorry...

I'd love to automate that minutes process like we could each one of us have two windows open: 1. this chat 2. a real-time collaborative text editor... then we would each and all be responsible

Would be happy to try.

I've used that way of doing in many places: awesome for the agenda huge for misunderstanding reduction excellent for winning some time (no one has to review/rewrite/refaco notes afterwards)

Sorry, I tend to have meetings back-to-back after this one at the moment

Right

WE have the logs.

Logs are insufficient, of course.

long and hard to read

no-one apparently finds minutes worth the trouble

so logs are what we have.

that's too much work with collab text editing, the load is balanced by the number of participants

I don't think that's an acceptable stance towards our membership, to be honest.

agree, we should deliver better than the logs

then memberhip should step up. We can stop doing these meetings if you feel strong about it.

Ideally, we'd have an appointed scribe for all our meetings, but I'm ok with trying out nyco's suggestion for now.

I'm moving on in the meanwhile.

Here, sorry

and I'd timebox meetings...

ok, let's try today?

nyco: I try to keep them within 30 min.

2. Badge Design

https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=fr

I've contacted Robert Martinez on this, hope he responds before next meeting.

Thanks

3. Review of Roadmap Page

I have looked at this really old page again.

Oddly enough, some of the items are still a bit current.

please help me on: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=fr

E.g. the part on Jabber Identifiers (PRECIS) came up again a few weeks ago

From the few responses on the XMPPWG mailinglist over at IETF, it seems there's not really a solution for this yet.

My own topics that I think could be on a roadmap page are:

1) Work on the things I recently blogged about regarding references, reactions, etc, and how that could be handled with MAM

2) Calling in the new(ish) reality of multiple devices that aren't always connected, but still would want to receive calls.

Ralph, instead of defining a roadmap (that's an XSF roadmap, not a board roadmap), we might want to discuss topic candidates on the member list?

3) e2ee. I think we need to make clear here what things are covered (plain body, full stanza) and which are not (e.g. meta data).

ralphm: that sounds like a Council roadmap actually ;)

Ge0rG: it does, maybe, I am listing what I think could be on it, I'm sure the Council has opinions, and I've also sent a message to Dave on this earlier today.

ralphm: XEP-0423 comes with a "Future Development" section that's looking for content, deadline is next Wednesday for an LC request, November 5th for Draft

Are we discussing the content of the roadmap, or if we want to have a roadmap?

Guus: I'm just following the agenda, the items above haven't really been handled for weeks, and I did some work on it

Guus: I don't intend to make a full discussion on it today, just share what I have so far

Seve: probably both

ralphm: if you are motivated, please contribute in https://github.com/xsf/xeps/compare/master...ge0rg:cs2020?expand=1 / https://github.com/ge0rg/xeps/tree/cs2020

I see

Ge0rG: thanks

I think the XSF or Board roadmap should be different from the XMPP protocol roadmap, though

XSF Roadmap should include marketing, org topics, sprint planning etc.

I think it can include anything that we feel significantly benefits the XSF or XMPP.

Right

if an important goal is to have a specific XEP published, I don't mind it being on that roadmap.

also compliance badges.

I'm not interested in individual specs per se, but more like: we should have a solution for things like references (e.g.)

and our emoji character

and then see how we can achieve that

I agree with Ge0rG that xsf roadmap is different from protocol roadmap

Guus: I'm not trying to protect my turf here, but I think that we get less done by mixing up the different bodies of the XSF

yes, protocol != xsf

pep.: well, so far it hasn't. We could change that, of course, but I'm not sure, really.

so everything related to SCAM, commTeam, iTeam included

Ge0rG putting something on a roadmap does not imply that other bodies are suddenly working on something.

I agree that we should have a high-level protocol strategy defined by Board + Council, though

let's come to some kind of actionable conclusion here

yes please

in relation with the IETF, and probably other standards bodies

I definitely believe the Board should be able to set high-level goals that can guide Council

We are still primarily a standards organisation, and of course those things mentioned by nyco need to be addressed, and could /also/ be on it.

and that has happened in the past regularly

Right

I'd note in passing that Council has zero power, as defined in our documents, so actuate any of these roadmap initiatives.

Guus: well, the action I had was reviewing it, and I did

We've danced around 'priorities' and 'roadmap' often. I'm not against someone simply providing a PR with a suggested roadmap update, and for everyone to provide feedback on that.

But e.g. the goal would be "End-to-end encryption", it's Council's reponsibility to decide whether that's OMEMO that gets put into the Compliance Suite

dwd: indeed, so that's another reason it is also a Board topic

+1

for how long have we not done "official" interop testing? that could help OMEMO implementations, btw

I personally think it would be good to stimulate development in certain areas. Maybe with small scale topic-specific get-to-gathers, or something, to get things moving.

Board could assign some resources to do official interop testing. Also to making our wiki mobile-ready finally.

ralphm: "sprints"?

(I meant /protocol/ development, really, but having implementations is good too of course)

sprints are awesome so far, we could use more focus and some sort of direction, indeed

5 minutes left.

Good to see various topics raised here. I'll take that make and see if I can create a comprehensive list from it.

^make^back

ralphm: 👍

the list can be collected here, though: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=en

thanks

4. Board & Council elections

So we're having them soonish, and we need (more) candidates.

To have a roadmap, we need to have some sort of commitment for it. I think having a global XSF roadmap is good, I would first think about what do we want to fit in the roadmap and check after if we need to split it into two (XSF/protocol) or not

I personally think it would be great to have people on Board who are not directly involved with protocol or software development.

Sign up here: https://wiki.xmpp.org/web/Board_and_Council_Elections_2019

+1

I do not yet have anyone in mind.

businessy people, yes or marketingy people

I second that opening

Well, we've always been open in that regard, just recently haven't seen candidates in that regard.

ralphm: isn't it better to look for people who are competent at PM, rather than for people who are incompetent at XMPP? ;)

PM?

project management

Project Management.

wat

could have been Product Management as well

Ge0rG: oh, I meant 'not necessarily involved'.

But having a broader scope is always interesting.

people who are incompetent at XMPP are very, very, like very valuable to us!

we could use those profiles to greatly simplify our "message"

nyco: but that shouldn't be a requirement for runnung for Board

At some level I find this quite amusing

indeed

So, I'd like to ask anyone currently on Board or on the floor, to think about this, and maybe provide suggestion to me.

ralphm: suggestion of potential board candidates?

time

I shall definitely give it some thought

ralphm, are you thinking about some specific skills?

Ge0rG: we're not limiting applications in any way. There's still an election of course, and we already have candidates that have run before.

Ge0rG: yes

new blood is cool as well

Seve: not really

5. AOB

as I said, "project management" is a good skill to have.

?

We need more focus in these meetings

maybe also "has an hour or two per week for Board matters"

not forcefilly PM

and/or have more than 30 minutes

Guus: we're already at AOB?

we're not getting our item list done

or really commit and engage

I'm raising that as an AOB item 🙂

And if we didn't spend valuable time at the 'minute taker' item, then we'd have more time to discuss things.

Ah

I'll propose a solution on the "minute taker" problem for next week

we've had a couple of trello cards on there for weeks, without addressing them.

Guus: and we addressed them today, yay.

agree, we don't consume cards fast enough

Many of the other items are awaiting feedback

Maybe we can be more async?

But point taken.

Sure, we can still do stuff on the board list. particularly around financials

I think we should strive to discuss less details in meetings - unsure how that works out in practice though.

async would be added capacity, indeed but needs more organisation, commitment, engagement

details arise in meetings, so let's set them free to expand

Ok, so let's all review the topics on the trello board and see how we can cross them off

I disagree. I think we should use meetings to plan for discussion/processing of details, not to handle them.

I'm sorry, but didn't we do just that?

as a for example: we discussed items to be put on a roadmap, instead of 'how do we update the roadmap'

Seve is right about async work, or out-of-meeting progress

there's a lot of things that we could do more abstract in these meetings, if we plan the legwork outside of these meetings.

My phabricator comment was about this exactly. Trying to find a way we improve as a team. I do feel we need more time to discuss (not in meetings but in general at least)

Like nyco said, that takes additional work though

How to update the roadmap doesn't need a discussion, what's on it does and I'm glad we discussed it.

once again I agree with Seve that ideation happens during meetings, in real-time sync

right

However it may make sense to have separate meetings for deeper discussions around various topics

ah, good idea

30 minutes is often not enough to cover one topic in detail

and that happens quite often, it seems

We spend >90% of the meeting time discussing one thing

MattJ: ok, we can maybe plan ahead to extend a next meeting for a specific topic

I usually reserve a 1 hour slot for this meeting

As mentioned earlier I don't have room in my schedule to expand this meeting in its current timeslot, but sure, I agree in principle

but try to keep it within 30min, to cater for the possibility a topic needs more time

I did also, and will endeavour to return to that, but not for at least the next few weeks

noted

Thanks Guus for raising this

6. Date of Next

+1W?

I can not make it next week.

but don't let thta stop you

Oh, right it is vacation for me, too.

+1

So I might not make it either

Maybe skip one?

sure

Depends on the remaining three 🙂

I"ll definately not make it.

+2W then

please review before you go: https://mensuel.framapad.org/p/2019-10-10-XSF-board-o5Yl05hJfT?lang=en

I should be available next week if nothing happens, but it all depends on what do we need to discuss, I guess

Let's try to indeed do some homework before the next meeting.

And review the pad by nyco

Sounds good!

7. Close

Thanks all!

Good meeting, thank you and have some nice vacation :)

Seve: 👊

tx

thx all, bye

oh and New Vector (Matrix) has raised 8.5M

Yes, that's great news for them.

yep, they've proven consistency, they're rewarded

We should found a start-up company called "New Zimpy" to acquire funding for pushing forward our implementations.

Ge0rG, jingle file transfer

we are going to bump jingle ft?

flow: so you are saying it is a bad idea to implement Jingle-FT?

for CS-2020, I don't care much about the state of the XEP, but rather about what implementors need to consider

It depends on what message you want to convey

Note also that if you 'require' jingle ft 3 or 4 clients will have a chance at making that

If you require both http upload and jingle I think you are down to 2-3

Not that this should stop you

But be aware of that

Daniel: that's an interesting point. Should we have "optional" features?

And it's not like other clients will implement jingle over night

Optional features defeat the purpose

There are already profiles

Daniel: you mean the compliance suite Levels, or something different?

Do we need a new one? "Core", "Advanced" and "Super Plus"?

that would make more sense than having optional features

(not that i like having super plus; but it still makes more sense than optional features)

Daniel: I agree on that

You can include a "Gajim level" somewhere in there

(just teasing :p)

i mean if you make jingle part of it i think Gajim and Conversations will be the only clients to make advanced im

I don't want to overengineer that CS, so I'd rather force some clients to fall from Advanced to Core right now.

(they might already?)

I have no idea.

poezio is probably still in the race

but you lose it if you include jingle

I'm not worried about poezio dropping from the race

with libcaca avatars?

Ge0rG, tct!

pep.: I can't bother to remember the implementation details

yes it's not a race

but CS2020 should set some realistic goals maybe?

Ge0rG, https://mpv.io/manual/master/#video-output-drivers-tct

is it realistic to have a client that can't send files if you are on j.c.d?

I'd add XEP-0379 and Bookmarks2 if I wasn't being realistic.

you have that with http upload

j.c.d?

Daniel: you don't have that on j.c.d

jabber.ccc.de

fair enough. i ignored the part of your sentence that i was unable to parse

fwiw, poezio is already not a core client, we don't do direct invites, so it's already out of the race

if you wanted to that would be easier to add than jingle ft

It certainly makes sense to have it in some use-cases, but it doesn't to get back into the race :)

(read: I wouldn't mind implementing it, but I need a proper use-case. Also, we have more urgent/important things to fix in poezio.. (and that's not OMEMO))

after all, CS-2020 is not about a client pissing contest.

(the OMEMO bit isn't directed at you Daniel)

please?

pep.: fix MAM finally, _please_. ✏

:)

😁

i've observed muc implementations in the wild that don’t send mediated invites if the person is already a member

meaning re-invite doesn’t work

interesting

that's when Conversations falls back to direct invite

i didn’t want to hunt down the bug; just switched over

that's evil

Daniel: those are the little gems of tribal knowledge that should be written down somewhere on our wiki

and linked from the XEP

Right, Category:Errata or sth.

Or remarks

https://wiki.xmpp.org/web/Tech_pages isn't even a category

oh, it's in https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat

https://wiki.xmpp.org/web/XEP_and_RFC_Remarks talking about this

good that the wiki search doesn't find that if you search for "0045"

Ge0rG, you had an example of category btw?

can't remember

also great that it links to "[Standards] Proposed XMPP Extension: Buddycloud Channels" in the archive

pep.: https://wiki.xmpp.org/web/Special:Categories and especially https://wiki.xmpp.org/web/index.php?title=Category:Interop

Ok

https://wiki.xmpp.org/web/XEP-Remarks/XEP-0363:_HTTP_File_Upload <= that never made it into my inbox

i would have loved to 'fix' that

but now bumping NS for that doesn’t seem worth it

yeah

Daniel: https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Mediated_MUC_Invitations

https://wiki.xmpp.org/web/XEP-Remarks/XEP-0313:_Message_Archive_Management Maybe this could use more context :x

"Missing "Give the the last N messages starting from the oldest" query" as a title

flow: you authored it... ⏫

https://wiki.xmpp.org/web/index.php?title=Category:Spec_Remarks hmm. I'm not sure how useful that was though, considering everything is already on the same page.

Also apparently there's a XEP category already.

Which is exactly that, I guess I'll move that over

pep.: we could also move the "XEP and RFC Remarks" page into the category, then people would get redirected to the automatic list, even with it being less nice looking

redirected? What magic do you need for that

pep.: I did it with https://wiki.xmpp.org/web/index.php?title=Easy_XMPP&redirect=no - `#REDIRECT [[:Category:Easy XMPP]]`

pep.: IIRC you must be wiki admin to move pages, though

Forbidden dark Mediawiki magic?

Incantations that will make your fingers fall off.

or your ears. or your eyes. depending on which way they go

So whom do I need to bribe to finally make https://github.com/xsf/mediawiki-docker/issues/2 happen?

Ge0rG, not all, we need implementations of experimental XEPs, I am just not sure if a XEP mentioned in the compliance suite should have a certain amount of stability, or if it's just a pointer to the "next thing"

if compliance suites are supposed to point to the current state of the art, which experimental XEPs probably count as, then it shouldn't be included. If they are the map of the xep jungle, pointing out which xeps are (probably) ahead on the road, then you could and should include jingle file-transfer.

flow: there is the "Future Development" section for next things. XEPs in the CS should have some stability, and they should provide functionality needed by users

the CS isn't about XEP status politics

Compliance suites could also be both, but then it should be probably marked which xeps are currently considered stable and which ones are the next big thing

Jingle-FT has been there for over a decade, and I don't see any alternative to it

is there a rendered version of the proposed compliance suites somewhere?

flow: XEP stability is orthogonal to what users expect from a client

flow: https://op-co.de/tmp/xep-0423.html

sure, but I also have the poor developers in mind

poor developers using the wrong MAM namespace? :D

> Jingle-FT has been there for over a decade, and I don't see any alternative to it Yet we are only slowly reaching a point where we have compatible implementations that are somewhat reliable in exchanging files

pep., poezio certainly does direct invites (if you mean 0249 by that)

Ge0rG, IMHO User Name Coloring should not be mandated by the compliance suite. If there is a client that does all the cool things but generates avatars similar to github or slack (patterns instead of single colors), that should not keep it from beeing an advanced xmpp client. Or really, if I don't want to color the names/avatars at all. It's a design thing and should be part of client diversity and choice. If you go that way you could as well mandate that clients have to do a conversation list instead of a roster for "consistency".

lskdjf: I'm sure that the Conversation list will become a thing in a year or two, and then will be added to CS

lskdjf: also nothing prevents your smart pattern avatar generator from applying the same color as other clients do

I found lskdjf is having a valid point.

Is our goal to appease client developers or to make XMPP finally suitable for normal people?

lskdjf: you are making a valid point indeed, but I disagree with that. Feel free to bring that up on standards@ and get more people behind you

I as a partly normal person am happy with my terminal not looking like a rainbow when chatting. 😃

Ge0rG, where does the "mandate the UI" end? when all clients look the same? there are different users and different use cases. Not everyone is happy with the same thing. many people actually like a roster, and they have a valid point. and if there's a client that provides them with a roster, that's good and not less XMPP-compatible.

I'm not going to get convinced, but sufficient negative feedback could certainly make me remove it again

lskdjf: I'm not saying "get rid of the roster", I'm saying "support an automatic synchronization of your open conversations over all clients"

I don't really see nickname colors as a usability but more as theming.

lskdjf: if the user wants to disable it, well, let them

> I'm saying "support an automatic synchronization of your open conversations over all clients" As a client you don't need that if you only offer a roster, though

lskdjf: well, then you aren't an advanced but just a core client. Live with it

Ge0rG, why? because some people think my preference in UI isn't the "correct" one?

lskdjf: no, because your UI preferences make it harder for users to migrate between xmpp clients

mh I don't agree with your view on what the job of the compliance suite is. but you already said you won't be convinced.

Ge0rG, another point I have is that I'd like to suggest to only mandate vcard-temp for advanced IM clients.

lskdjf: I'm not even sure why it's in core.

I also wouldn't mind seeing it removed 🤷️

I'm not an expert on vCard specs

what's the story behind the NS format (changes) btw? jabber:x:foo, https://jabber.org/protocol/foo, urn:xmpp:foo

jabber: is from before people learned how xmlns is supposed to work

urn:xmpp: is after IETF standardization

And the awkward one in the middle?

people experimenting?

That's acceptable behavior

if you don't have a urn for a namespace, you can use a url you control

I'm personally a fan of xmpp: URIs as xmlns 🙂

Yeah I also like that :)

`xmpp:prosody.im/whatever` eg

zash: but you need to stay in control of prosody.im forever. for urn:xmpp the iana is in control and going to be around for longer :-)

fippo, same applies to http://jabber.org

fippo, as a temporary solution

fippo, aren't we (the XSF) in control of urn:xmpp:* tho?

urn:uuid: is cool too, but somewhat verbose

Ge0rG, I'm kind of duplicating work that was already done on the wiki with that category :/

But I'll take the opportunity to unify all of it

Who do I need to bribe to become a wiki sysops btw

zash: the iana delegated the subnamespace to the xsf registrar

fippo, so we're in control. or can they un-delegate it? if so, it's no different than DNS based URIs?

pep.: iteam

zash: hrm, rfc 8141 doesn't say whether the iana can undelegate. lets pester one of the authors? :-)

There is no undelegation or redelegation for URN namespaces. URN namespace assignments are permanent because the whole point of URNs is permanence. However, we did not explicitly mention this in RFC 8141.