XSF Discussion - 2018-09-06


  1. Syndace

    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.

  2. Syndace

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

  3. Syndace

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

  4. moparisthebest

    Syndace: yep that is what he expected to happen

  5. moparisthebest

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

  6. !XSF_Martin

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

  7. daniel

    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

  8. daniel

    Use something like OX

  9. daniel

    The scenarios where PFS are beneficial are extremely niche

  10. !XSF_Martin

    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?

  11. daniel

    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

  12. !XSF_Martin

    > 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.

  13. daniel

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

  14. daniel

    Because of the better handling of Re retrievable history

  15. daniel

    And multiple devices sharing the same key

  16. !XSF_Martin

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

  17. daniel

    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

  18. daniel

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

  19. !XSF_Martin

    OK, so I'll stick with omemo for now πŸ˜ƒ

  20. nyco

    hey, are we gonna have the bard meeting?

  21. Zash

    who brings the lute?

  22. MattJ

    The jester

  23. nyco

    that makes two, not five

  24. MattJ

    Guus, ralphm

  25. Guus

    peekaboo

  26. nyco

    let's start

  27. Guus

    I'm entirely unprepared, sorry

  28. nyco

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

  29. MattJ

    Ok...

  30. MattJ

    0) Role call

  31. nyco

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

  32. MattJ

    Me, Guus, nyco

  33. nyco

    Matt, Guus, Nyco

  34. nyco

    Ralph and Martin missing

  35. MattJ

    Anything that isn't on Trello for agenda?

  36. Guus

    not from me

  37. MattJ

    Nor me

  38. nyco

    next board prios, exec officer

  39. MattJ

    They are on Trello :)

  40. nyco

    ah, board tenure as well

  41. nyco

    yep

  42. MattJ

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

  43. MattJ

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

  44. nyco

    no pb

  45. nyco

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

  46. MattJ

    Some concrete items in your proposal:

  47. MattJ

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

  48. nyco

    so, thx for the survey, this helps a lot

  49. nyco

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

  50. MattJ

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

  51. nyco

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

  52. MattJ

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

  53. nyco

    where is the nb of subscribers?

  54. Guus

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

  55. MattJ

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

  56. Guus

    I actually had an idea or two on that.

  57. nyco

    please

  58. nyco

    how much, MattJ ?

  59. nyco

    how many, sorry

  60. MattJ

    I don't remember

  61. nyco

    hehehe

  62. nyco

    1 ? or 2 ? πŸ˜‰

  63. nyco

    seriously, tens? hundreds? thousands?

  64. MattJ

    Heh, I honestly don't remember, sorry

  65. MattJ

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

  66. nyco

    ok

  67. MattJ

    I've asked him again

  68. nyco

    thx

  69. Guus

    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."

  70. MattJ

    Guus, I think that's sensible

  71. MattJ

    nyco, currently 141 subscribers

  72. nyco

    good, thx

  73. Guus

    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.

  74. nyco

    we could easily reach out and pass the arbitrary 200 mark

  75. MattJ

    That seems sensible to me, yes

  76. Guus

    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"

  77. Guus

    what does it mean exactly?

  78. nyco

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

  79. nyco

    from my propositions:

  80. nyco

    == 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.

  81. nyco

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

  82. Guus

    nyco, I feel that we are already doing both.

  83. Guus

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

  84. nyco

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

  85. Guus

    that has considerably dropped the amount of inactive projects

  86. Guus

    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'

  87. Guus

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

  88. MattJ

    Yes, I'm with that

  89. Guus

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

  90. Guus

    or it's been a bit longer perhaps

  91. nyco

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

  92. MattJ

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

  93. MattJ

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

  94. Guus

    wfm

  95. MattJ

    Ok, moving on quick...

  96. MattJ

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

  97. MattJ

    Anyone want to discuss any of these in particular?

  98. Guus

    not me

  99. nyco

    tenure for me

  100. nyco

    ok

  101. MattJ

    Ok, I'd like to touch on board tenure

  102. MattJ

    2) Board tenure

  103. nyco

    we're a majority πŸ˜‰

  104. MattJ

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

  105. MattJ

    At least nothing that drastic

  106. nyco

    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

  107. Guus

    I didn't find any consensus on list.

  108. MattJ

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

  109. Guus

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

  110. Guus

    on changing / prolonging tenure explicitly, I ment, Mattj

  111. MattJ

    Yes

  112. nyco

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

  113. MattJ

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

  114. Guus

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

  115. MattJ

    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

  116. Guus

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

  117. MattJ

    and what can we do to fix that?

  118. Guus

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

  119. nyco

    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'

  120. MattJ

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

  121. Guus

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

  122. nyco

    pat xep ? πŸ˜‰

  123. Guus

    maybe something for next meeting

  124. Guus

    I got to run

  125. nyco

    yeah, cool debate to have

  126. nyco

    yes, it is already 16:00

  127. nyco

    thx both of you

  128. Guus

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

  129. nyco

    I can

  130. MattJ

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

  131. Guus

    ok

  132. MattJ

    Meeting over, thanks both

  133. Guus

    thank you

  134. flow

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