XSF Discussion - 2018-09-06

I thought about offline history sync a little. It would not break PFS if the sync had to be confirmed by the sending device. Like: Your device "Phone" requested your message history with "User" (someUser@jabber.org). Do you want to send it to him? > Yes > Yes and allow all requests by "Phone" for the next 15 Minutes > No > No and never allow any request by "Phone" Like this new devices could sync the history from old devices and then go on with OMEMO just as usual. This would be a one-time sync when a new device first logs in.

Sigh, ">" is for citing... My formatting :(

Should replace "offline history" with "local history" probably

Syndace: yep that is what he expected to happen

I tried to explain that nothing does that now, but it could be standardized and implemented

Syndace: I would like that. Would solve the usability issue with pfs

If you care about history (I personally don't use jabber like that and prefer email for things I need a permanent record of, but I understand why people do) PFS in general and OMEMO in particular might simply not be the right tool

Use something like OX

The scenarios where PFS are beneficial are extremely niche

daniel: ox is gpg? Omemo had the advantage to just tell people 'turn omemo' what is easier than telling to install openpgpchain (or what it is called), create key, enable PGP, choose key... Is this easier now with the gpg SOC project?

Well ox can be better integrated into the client. Clients would create their own keys and keys can be retrieved over xmpp instead of external key servers

> The scenarios where PFS are beneficial are extremely niche True, for me e2e is important, Pfs not. But omemo had the better usability except the pfs issues.

So yeah UX should in a way be even better than omemo

Because of the better handling of Re retrievable history

And multiple devices sharing the same key

daniel: will you include it in conv? Or have you already?

I have things that are higher on my priority list and I always said I want different people to lead the way with that (and they have) but I'm not generally opposed

I'd rather include that then some weird c2c mam with e2ee

OK, so I'll stick with omemo for now 😃

hey, are we gonna have the bard meeting?

who brings the lute?

The jester

that makes two, not five

Guus, ralphm

peekaboo

let's start

I'm entirely unprepared, sorry

https://trello.com/b/Dn6IQOu0/board-meetings

Ok...

0) Role call

https://trello.com/c/Al4GHsYy/311-proposed-prios-for-the-2018-2019-board-based-on-survey maybe?

Me, Guus, nyco

Matt, Guus, Nyco

Ralph and Martin missing

Anything that isn't on Trello for agenda?

not from me

Nor me

next board prios, exec officer

They are on Trello :)

ah, board tenure as well

yep

1) Topics for decisions: Proposed priorities for 2018-19 board

Firstly, thanks for reviewing the survey results and getting the ball rolling on this nyco

no pb

I regret this is late, I should have done something earlier

Some concrete items in your proposal:

1/ we keep/increase the effort on XEPs and engaging the community => SCAM and the CommTeam?

so, thx for the survey, this helps a lot

yeah, makes me think we should measure teams progress in some way number of summits, meetups, hackathons, sprints, tweets, etc.

I think we're doing fine for XEP production, I feel like we have quite a number of authors these days, which is healthy

filling our current channels (Twitter?) with relevant content, and probably add one or two more

Last I heard the newsletter is doing well also, with a healthy growing subscriber count

where is the nb of subscribers?

SCAM has been pretty dormant though - that could use some reviving

I don't think it's public, but I asked JC a few weeks ago

I actually had an idea or two on that.

please

how much, MattJ ?

how many, sorry

I don't remember

hehehe

1 ? or 2 ? 😉

seriously, tens? hundreds? thousands?

Heh, I honestly don't remember, sorry

I was just scanning my logs but can't find it

ok

I've asked him again

thx

Let's keep the recommendations from us to next board somewhat broad: "Improve community engagement by explicitly tasking SCAM and Comm WT, and facilitate where needed."

Guus, I think that's sensible

nyco, currently 141 subscribers

good, thx

I'm not sure if a recommendation to not change something makes sense, but we can let the record of this meeting show that based on the outcome of the user survey, this board chooses to not change its position on keeping the XSF implementation neutral.

we could easily reach out and pass the arbitrary 200 mark

That seems sensible to me, yes

I'm unsure what to make of what I believe was Nyco's last item: "we delegate and we call for effort to develop support of developers and outreach beyond the XMPP community"

what does it mean exactly?

the neutrality comes back very often, so I guess we have something to do here

from my propositions:

== Implementation neutrality == Given the above and the survey responders have shared+mixed views and opinions, I (Nÿco) propose to stay as it is today. Given the past discussions and perceived rough consensus, it would be nice if someone added that tag "active"/"dormant" to software projects.

thus we keep neutrality, still helping people chose, avoiding inactive/dormant projects, which could be woken up or taken over later

nyco, I feel that we are already doing both.

we are currently netural (no change there), and the software listing on our website needs to be renewed every year

https://xmpp.org/software/clients.html has no active vs dormant label

that has considerably dropped the amount of inactive projects

I feel that we're not going to improve much on what we have with this, without getting bogged down in endless discussions on what exactly qualifies as 'inactive' or 'active'

I suggest we don't improve on that further. What we have works fine-ish.

Yes, I'm with that

(the list on our website is not nearly as bad as it was 1 year ago)

or it's been a bit longer perhaps

an incremental improvement, given our lack of resources, that is very good indeed

I think we won't have much time to discuss more today

I can note the things we agreed on here in the minutes, and the things we may still need to discuss

wfm

Ok, moving on quick...

I see these topics: ED search, fundraising/finances, board tenure

Anyone want to discuss any of these in particular?

not me

tenure for me

ok

Ok, I'd like to touch on board tenure

2) Board tenure

we're a majority 😉

After reviewing the discussions on the list, I think I'm leaning in favour of not changing anything

At least nothing that drastic

I feel like even though we'd like to improve, things would be too complex, in other terms weak RoI besides I feel like we have a natural and healthy rotation

I didn't find any consensus on list.

No, I don't think it reached a consensus - I think that's for the board to reach

I still do think we should find a way to be more productive

on changing / prolonging tenure explicitly, I ment, Mattj

Yes

oh yeah, commitment, too many absences, too short meetings, non-productive meetings, no meetings properly prepared, no followup, no measure

We're all volunteers, it's a volunteer-based organisation, that's always going to be tricky

I'm not saying we need to work harder. Maybe we can be smarter about some things though

That's partly why I started the year trying to get the fundraising stuff straightened out, because it's one of our biggest failures right now I think

One thing that bothers me is that various people use terms as 'unthankful' and 'burn out' when describing work for the XSF

and what can we do to fix that?

I don't perceive it as such, but it's worrying me that others do.

I do not believe personnally it is 'unthankful' as it is somehow rewarding also given our amount of work, it is definitely far from 'burn out'

There's a bunch of "boring" tasks to be completed by relatively few people

MattJ, unsure - give more credits where due might be a starter.

pat xep ? 😉

maybe something for next meeting

I got to run

yeah, cool debate to have

yes, it is already 16:00

thx both of you

also, I will _not_ be able to make +1w

I can

Ok, well we'll mark it in the calendar anyway

ok

Meeting over, thanks both

thank you

Is there a good reason why xep333 requires the marker message to contain the original <thread/>?