XSF Discussion - 2020-06-02

  1. Alex

    Memberbot is still online for our member meeting today. If you have not voted yet you can still do so

  2. Link Mauve

    Is Davide Conzon here? If so, do you have a JID which federates with the rest of the Jabber network?

  3. Neustradamus

    Alex: after the ending, it will be possible to test the memberbot solution to have no instead of No?

  4. Neustradamus

    I have sent you code to test in real several months ago...

  5. Alex

    I cherry picked the code

  6. Alex

    It's there already

  7. Alex

    Master branch is broken and does not work. I need help to get ithis code fixed. People pushed non working code without testing it

  8. Alex

    Master branch is broken and does not work. I need help to get ithis code fixed and working

  9. Holger

    Someone (Alex?) mentioned that these application time windows are outdated: > Applications from prospective new members are accepted during the first two weeks of every quarter (i.e., the first two weeks of January, April, July, and October). How does it work these days?

  10. Alex

    Holger: usually I try to align with the timelines we had in previous years according to the wiki. Happy to agree on fixed timelines when it helps

  11. Holger

    Alex: Nah, fine with me. So next round would be early August AFAICS.

  12. Alex


  13. Holger

    I planned to apply for some months now and kept being too late to the party so I thought I'd add a reminder to my calender, that's all :-)

  14. Alex

    Just create your application page now and I will add it to the Q3 application page

  15. Alex

    Or I ping you when the Q3 page is created

  16. Holger

    You sound as if I was able to get things done *before* it's almost too late.

  17. Holger

    :-) Hopefully my calender will do the trick this time. But thanks a lot!

  18. Seve

    happy to hear that Holger !!!

  19. jonas’

    Holger, I may also add you to my mental nagging list ;)

  20. jonas’

    like I pester Link Mauve all the time about the reapplication ;)

  21. Link Mauve

    Holger, welcome to the club! :D

  22. Holger

    Heh, glad I'm not alone.

  23. DebXWoody

    Hi. https://xmpp.org/extensions/xep-0373.html#discover-pubkey "Note that the result may contain multiple pubkey elements. Only the public keys found in the most recent item MUST be used." I don't get this. Why should there more than one public key? Which one is the most recent item?

  24. Daniel

    That doesn't feel right

  25. Daniel

    It should probably say that the node should be used and configured as a singleton node

  26. pep.

    "most recent item", is that the thing that's not-really-well-defined? (most recently created vs updated?)

  27. pep.

    (or is that defined now?)

  28. pep.

    Daniel, why?

  29. pep.

    I don't think 373 forces a single key per account

  30. Daniel

    But in one item

  31. pep.

    ah right

  32. Daniel

    According to the quoted wording

  33. pep.

    Well the quote suggests there might be multiple items, not multiple things in an <item/>

  34. Daniel

    I think our knowledge and understanding of PEP was different when the xep was written

  35. Daniel

    > Well the quote suggests there might be multiple items, not multiple things in an <item/> Yes. And you can avoid that was proper singleton nodes

  36. Daniel

    Which the authors probably didn't really know

  37. Daniel

    And/or implementations were more broken back then

  38. pep.

    Right, and different nodes for different keys

  39. Daniel


  40. Daniel

    Not sure if one would do that today

  41. Daniel

    I was just Reacting to the quote

  42. Daniel

    I didn't check the xep

  43. pep.


  44. DebXWoody

    There is a second question. I think it's not required to push the public key on the PEP. The client should be able to lookup for the key on the local keyring. I implemented it via lookup of checking the userid as XMPP URI in the local keyring. If there are more than one public key, should it be encrypted to all keys?

  45. pep.

    "the [only] client"?

  46. Daniel

    I guess since you are one of the first people to implemt this I guess it's on you to use your best judgment and provide feedback

  47. Daniel

    Personally I would probably only implemt lookup and not mix in third party key sources

  48. DebXWoody

    There are already same problems with the gajim plugin :-(

  49. pep.

    If you don't push your public key on PEP, how are people going to encrypt to you? Am I missing something

  50. Daniel

    I wouldn't even use the local Keychain that is used for 'regular' pgp

  51. pep.

    yeah I wouldn't either

  52. DebXWoody

    I would :-)

  53. pep.

    Sure, that's left to the implementation anyway

  54. pep.

    Is that only for profanity? Any other clients you're pushing that to?

  55. DebXWoody

    yes, profanity and a small gtk application.

  56. DebXWoody

    Ok, I will try to write down some notes and send a mail on the mailinglist.

  57. DebXWoody


  58. Daniel

    Isn't the possibility of having multiple keys inviting the same problems that omemo has

  59. Daniel

    Aka not being able to do tofu

  60. Daniel

    But having to resort to BTBV

  61. pep.

    Daniel, wasn't there talks about a "master key" at Summit?

  62. Daniel

    Even if few people actually do it the fact that it is allowed means I have to have trust ui for that

  63. pep.

    on the account

  64. pep.

    That being independent from $e2ee, so you could have OX or OMEMO behind I guess

  65. pep.

    Maybe somebody(tm) should write this down somewhere

  66. flow

    OpenPGP keyrings can consists of multiple keys

  67. flow

    OpenPGP keyrings can consist of multiple keys

  68. DebXWoody

    I did already started in German: https://codeberg.org/xmpp-messenger/eagle/wiki/BS-XMPPOXOpenPGP I will try to work on it. Maybe in the wiki?

  69. pep.


  70. flow

    the design question is if the data/metadata node split is still required, given that we could to payload less notifications

  71. flow

    the initial version of OX, had no split, then we split and now it looks like we do not need the split

  72. flow

    singleton nodes are not relevant here

  73. flow

    I *think* you can argue in favor of the data/metadata node split if we want to support multiple keyrings per user, which we do now

  74. DebXWoody

    There can be more than one Key for a UID, but I don't like it. The user has to decided which key / key he would like to use.

  75. Daniel

    Singelton nodes and metadata spilt are two different issues

  76. Zash

    metadata split?

  77. Daniel

    The quoted paragraph is already requesting what should only contain one key

  78. flow

    Daniel, right, my point was that there singleton nodes only help collect garbage, they don't offer an advantage when it comes to determing the current keyring(s)

  79. flow

    Zash, xep373 § 4.1 and 4.2

  80. Daniel

    The quoted paragraph says you might get multiple items in return

  81. Daniel

    Which wouldn't be the case if the node was a singleton

  82. flow

    Daniel, I don't have the paragraph in front of me, which one was it again?

  83. Daniel

    > Hi. https://xmpp.org/extensions/xep-0373.html#discover-pubkey > "Note that the result may contain multiple pubkey elements. Only the public keys found in the most recent item MUST be used." > I don't get this. Why should there more than one public key? Which one is the most recent item?

  84. flow

    in any way, you could also simply request only the latest item

  85. Daniel

    That was the initial question

  86. Daniel

    And what I was Reacting to

  87. flow

    Uh, that is multiple pubkeys per item

  88. flow

    xep373 ex7 uses max_items=1

  89. Daniel

    Which makes the quoted paragraph even more confusing

  90. flow

    no wait, that is a request on a data node

  91. flow

    Ahh I guess I see now

  92. flow

    that is why the second sentence hints towards using max_items=1

  93. lovetox

    flow you could add a paragraph that says singleton node has to be used

  94. Daniel

    Even max_items=1 is just a work around for a proper singleton node

  95. flow

    well from a protocol POV there is no need to use a singleton node

  96. pep.

    id="current" etc.?

  97. Daniel

    pep.: yes. Plus max items 1 on the node config

  98. lovetox

    flow either your XEP wants to request a single item

  99. Daniel

    Not on request

  100. lovetox

    then it should also enforce singleton node

  101. lovetox

    or not then you dont need maxitems=1

  102. Daniel

    I'm not saying the xep is wrong or anything

  103. Daniel

    Just our best practices have changed

  104. Daniel

    Wrt to PEP

  105. flow

    sure, the question is, if older versions of the keyring could be beneficial in some cases

  106. flow

    I can not answer that, and hence I am a little bit reluctant to specify the singleton node as a must

  107. Daniel

    Isn't the key supposed to be stripped down?

  108. flow

    Daniel, could you elaborate on max_items being just a work around for proper singleton nodes?

  109. Daniel

    So what kind of information would change?

  110. Daniel

    flow: well one limits the request the other actually let's the server store only one

  111. DebXWoody

    There is no need to have different versions of the public key.

  112. flow

    Daniel, right, I say that those are for different use cases

  113. lovetox

    flow are you aware whata singleton node is in pubsub?

  114. flow

    lovetox, yes

  115. Daniel

    If the intent is to make historic variants of the key available the xep should state that as a feature

  116. Daniel

    Otherwise it comes of like an accident

  117. lovetox

    ok, so max-items=1 request always the last item, so why would you have a node that stores unlimited items

  118. lovetox

    if you always only request one

  119. flow

    as I said, I do not have an answer if having the history of the pubkey is benefical or not. Hence this part of the XEP is deliberatly designed so that we can experiment with it

  120. lovetox

    no its not, you looked at other XEPs back at that time and copied what they did

  121. lovetox

    now its a design decision

  122. lovetox

    ok :)

  123. Zash

    Not sure if it fits this use case, but there's a thing in XEP-0060 about payloadless notifications that could be nice for certain PEP uses. Avatars for example, if it had been designed with that in mind.

  124. Daniel

    It really doesn't come of as deliberate

  125. Daniel

    But noted

  126. flow

    So the XEP saying nothing about singleton nodes but recommending to use max_items=1 when requesting, while I followed the whole OMEMO singleton discussion does not come as deliberate?

  127. Daniel


  128. lovetox

    anyway this discussion is not relevant client side anyway, as a client has to use max_items=1 anyway because we cannot depend that all other clients respect the singleton node

  129. flow

    I feel a little bit accused, but anyway. I mean the arguments in favor of keeping are not strong, I know, but I also do not see any harm in keeping the history

  130. lovetox

    its just a server thing to not store unlimited items

  131. flow

    sure, I hope servers have a quota mechanism of some sort

  132. Zash

    There was a brief period after adding support for multiple items in Prosody and before adding limits where it it could store unlimited items.

  133. pep.

    well not declaring it a singleton node tells clients this can be a list, right? (then I'm not sure why the max_items=1 at all if it's not meant to be a singleton node)

  134. flow

    pep., because in most cases you want the most recent version of the key

  135. pep.

    Does max_items=1/singleton have anything to do with this?

  136. pep.

    (sorry I'm not sure I followed all of the above)

  137. Daniel

    Can you give an example for when the historic version of the same key is useful?

  138. flow

    with either of them you get the most recent version

  139. pep.

    flow, ah so a client can request max_items=1 for the "latest" but the server storing more?

  140. flow

    Daniel, no, but can you list all examples and show that none of them benefits from prior data? ;)

  141. flow

    I mean, I can not right now, and it is not unlikely that there is none

  142. flow

    But at least in this stage I wouldn't close the door for it

  143. flow

    And again, I don't see any harm, since servers have incentive to purge old items anyway

  144. pep.

    There's gonna be an update of 373 at some point anyway, for SCE :p

  145. pep.

    Or maybe 374 rather(?)

  146. DebXWoody

    AFAIK, the local Keyring, the keyserver and WKD doesn't provides historic versions of public keys.

  147. flow

    pep., well actually SCE's design was inspired by what xep373/374 do

  148. pep.

    flow, I know

  149. Daniel

    Right. So if you can't give an example for why one would want such a feature and if the feature is not mentioned anywhere then this is the reason that I believe the feature was not deliberate

  150. pep.

    But now that we have a SCE..

  151. flow

    Daniel, if I don't know if it is a feature or not, then I would hardly spell it out in the xep

  152. flow

    pep., sure, but at the current stage of SCE would switching OX to SCE provide any benefit and justify the version bump?

  153. pep.

    Might as well bump while there isn't many impls.

  154. flow

    bumping as soon as there is more than one experimental impl is hard, and we should also bump in batches

  155. flow

    that is, I would not bump for SCE alone, but if I had to bump, then sure, why not

  156. pep.


  157. flow

    I am not sure why this is disappointing?

  158. flow

    If we have learned one thing, then it is that version bumps should be taken carefully, and coordinated

  159. pep.

    Becaue I never get why people fear updates

  160. pep.

    It's just a thing that happens and we deal with it

  161. flow

    I don't think I fear updates

  162. flow

    But the fallout of version bumps can be significant

  163. flow

    In fact I am happy to bump, esp. in the 'experimental' stage

  164. pep.

    I only know of 2 implementations atm, gajim and DebXWoody's, 373 is not used. I'm not sure what's preventing a bump at all

  165. flow

    but I would not bump for every "tiny" thing

  166. flow

    well for one, as of 5 minutes ago, nobody suggested a bump

  167. flow

    then, the far more important design decission when it comes to OX, is not SCE, but the metadata node split

  168. flow

    then, IMHO, the far more important design decission when it comes to OX, is not SCE, but the metadata node split

  169. DebXWoody

    what is SCE?

  170. pep.


  171. pep.

    Stuff that 373 does, but not specific to OX

  172. DebXWoody

    Ok, I saw,.. but forgot :-)

  173. flow

    pep., btw, smack has also an OX impl

  174. pep.


  175. lovetox

    flow what do you refering to when you talk about a meta data node split

  176. lovetox

    there is already a metadata node

  177. flow

    lovetox, right, the question is if we could go instead with payloadless notifications

  178. lovetox

    i would not classify this as "far more important"

  179. lovetox

    this was a idea by someone, never impl in any xep and tested

  180. flow

    well if we could get rid of the split, then it would reduce the complexity of the protocol somewhat

  181. flow

    which is always desirable IMHO

  182. lovetox

    its not complex, we have that split in 20 other xeps

  183. lovetox

    completely changing the syntax of how messages are transmitted ( SCE )

  184. flow

    well that does not mean that we have to continue that pattern if something better is feasible

  185. lovetox

    that is indeed a big change that should be made rather sooner than later

  186. flow

    is it really *completely* changing the syntax? IIRC SCE re-uses a lot names from OX

  187. lovetox

    it breaks that what i meant, it does not really matter by how much

  188. DebXWoody

    Notes I have in mind about OX: https://wiki.xmpp.org/web/Tech_pages/OX

  189. Alex

    hey guys, anyone ready for our member meeting?

  190. jonas’ is

  191. Zash


  192. jonas’ also forgot about it, but I’m still ready!

  193. Alex bangs the gavel

  194. Alex

    here is our Agenda for today: https://wiki.xmpp.org/web/Meeting-Minutes-2020-06-02

  195. Alex

    1) Call for Quorum

  196. Alex

    as you can see 33 memebrs voted via proxy, so we have a quorum

  197. Alex

    2) Items Subject to a Vote

  198. Alex

    new and returning members, you can see all applicants here: https://wiki.xmpp.org/web/Membership_Applications_Q2_2020

  199. Alex

    3) Opportunity for XSF Members to Vote in the Meeting

  200. Alex

    anyone here who has not voted yet and wants to do so? Membernot is still online. Also accepting votes over other channels

  201. jonas’

    Kev, you around?

  202. jonas’

    I seem to recall that Kev had issues contacting memberbot

  203. Kev

    I am. Yes, I wasn't able to vote.

  204. Kev

    (Because xmpp.org won't S2S with my server)

  205. jonas’

    how are you in this MUC then?

  206. Kev

    How do we actually do voting in person?

  207. Kev

    Different server.

  208. Alex

    Kev, you can send me your votes via private message if you want, or email

  209. Kev

    Memberbot knows me on my personal server, rather than work.

  210. Kev

    Alex: Or would it be easy to tell memberbot to know me at this address?

  211. Alex

    Kev, can whitelist also another Jid if you want

  212. Alex

    Kev, yes

  213. Alex

    send mme teh Jid and I will add it

  214. Kev

    There we go.

  215. Kev


  216. Alex

    ya, try now please

  217. Alex

    restarted the bot, just in case

  218. Kev


  219. Kev

    Thanks Alex.

  220. Alex


  221. Alex

    anyone else? Otherwise I start counting

  222. Alex

    onay, working on the results then

  223. Guus rolls a drum

  224. Zash


  225. Kev

    (Thanks for the ping jonas’ too)

  226. jonas’

    Kev, you’re welchome :)

  227. jonas’

    Kev, you’re welcome :)

  228. Alex

    4) Announcement_of_Voting_Results

  229. Alex

    when you reload teh page at: https://wiki.xmpp.org/web/Meeting-Minutes-2020-06-02#Announcement_of_Voting_Results you can see the results

  230. Alex

    all new and returning memebrs were accepted. Congrats to everyone

  231. Alex

    5) Any Other Business?

  232. pep.

    None here

  233. Alex

    I need to update memberbot for our next voting to mmae sur ethe latest code on master works. Rigt now its throwing exceptions. I may ask for help here from more experiences python folks ;-)

  234. Alex

    I think something broke with the update from sleekxmpp

  235. agustin cordero


  236. Alex

    6) Formal Adjournment

  237. Alex

    I motion that we adjourn

  238. Guus

    Thanks again, Alex.

  239. pep.

    Thanks Alex

  240. Zash


  241. moparisthebest

    thanks Alex!

  242. Alex bangs the gavel

  243. pep.

    agustin cordero, hi

  244. Alex

    thanks everyone. Will updatethe lists tomorrow morning and send out mmeeting minutes to the list

  245. Guus

    My python skills are nonexistent

  246. Kev

    Thanks Alex.

  247. mathieui

    Thanks Alex

  248. lovetox

    i wish i could unsubscribe a thread on the standards list

  249. jonas’

    lovetox, open your sieve filters, match on References/In-Reply-To and discard;

  250. jonas’

    in this case, you probalby want to match on a References header containing DB7PR02MB49561FD17292B534CAE51C60BC8D0@DB7PR02MB4956.eurprd02.prod.outlook.com

  251. lovetox

    filters, yeah such thing exists on my mail client, never needed it until now :D

  252. jonas’

    I’m *nearly* surpirsed that kmail doesn’t have a shortcut for creating a filter based on a thread…