XSF Discussion - 2019-02-09


  1. MattJ

    Good morning

  2. MattJ

    I'm going to upgrade xmpp:xmpp.org, which means this room will be (hopefully briefly) unavailable, and you will need to rejoin

  3. MattJ

    Hopefully for the last time, because the next version preserves room occupants between restarts :)

  4. MattJ

    Wait. Or am I?

  5. MattJ

    Looks like an OS upgrade will be needed first

  6. lovetox

    Do we get MAM here then?

  7. lovetox

    or at least a history that doesnt save chatstates

  8. MattJ

    MAM is the goal, yes

  9. lovetox

    great šŸ˜Ž

  10. jonasā€™

    lovetox, are you confusing this room with jdev@?

  11. lovetox

    maybe, does this one not save chatstates :D

  12. jonasā€™

    I donā€™t think it does

  13. jonasā€™

    but I havenā€™t been using a non-always-on client in MUCs for a while now, so I donā€™t know

  14. jonasā€™

    okay, Iā€™ve officially been doing too much XMPP. when I type x in my browser bar, the first suggestion is not xkcd.com anymore, but xmpp.org.

  15. zinid

    jonasā€™, I keep you even more busy :) check the inbox :)

  16. jonasā€™

    holy smokes, I knew you were one of those russian spammers!!!! (jk)

  17. zinid

    jonasā€™, haha, two more to come! (but not now)

  18. zinid

    jonasā€™, this time when you find the problems with the document tell me and I will fix them prior to the Council discussion, in order not to waste their time

  19. jonasā€™

    zinid, okay

  20. Ge0rG

    I have a vague feeling that the council members are on council because they like wasting their time with taking apart protocols...

  21. zinid

    really?

  22. zinid

    I thought they mostly take apart XSF rules :)

  23. Ge0rG

    zinid: those are a special kind of protocol.

  24. zinid

    Ge0rG, yeah, I learnt recently SEX is also a protocol

  25. zinid

    how is it going btw? where is the protoxep?

  26. zinid

    "how is your SEX life by the way"

  27. Ge0rG

    zinid: I haven't decided yet whether to make it a proto XEP. Need to read through OX and MLS first

  28. Ge0rG

    Also, surprisingly, some people dislike the name

  29. zinid

    ha, I told you. The wrong community. Rename to FAP.

  30. zinid

    btw, I tried to read the MLS I-D, but fell asleep after a few minutes. Really not my stuff.

  31. Maranda

    zinid, very satisfying thanks šŸ¤£ šŸ¤£ šŸ¤£

  32. zinid

    Maranda, hello ;)

  33. Maranda

    Good mornin' šŸ˜ø

  34. dwd

    Wasn't SEX the thing that was "post operational transform" and could transfer an empty XML doc in only 9,000 stanzas and half a gig?

  35. Zash

    dwd: SXE?

  36. dwd

    Oh, yes. That's the one.

  37. Zash

    What sort of amazing compression were you using to get that into half a gig?

  38. dwd

    Zash, Good point - these days, compression isn't allowed Because Security.

  39. pep.

    Looking at Outreachy. "FOSS communities need to have secured funding for at least one intern ($6,500)", that's.. not going to be possible?

  40. Zash

    Somewhat out of reach for ~3 people working in their free time without any formal organization, yeah.

  41. pep.

    Ok so outreachy for diversity in this community is a no-go, unless companies can chime in maybe.

  42. Zash

    Something something discrimination against poor FOSS projects!!!!11!1eleven

  43. pep.

    Yeah, so like 90% of FOSS

  44. rion

    I'm trying to understand one thing about Jingle. For example I have got a session-initiate request. iq-from and "initiator" are different for some reason. so I send back iq ack to iq-from and then session-accept to initiator jid. What if for example I receive content-add from initiator jid as iq-from now instead of original iq-from? How should I treat it?

  45. Zash

    pep.: Tho, we could still talk to them

  46. pep.

    Do you know who to ping and how to approach them?

  47. Zash

    Not really

  48. Zash

    pep.: "Hi, we're a bunch of FOSS projects around the open IM protocol XMPP" and invite the organizers to some event to talk about encouraging diversity in FOSS projects. Like a sprint or somesuch.

  49. Zash

    Something along those lines

  50. pep.

    How to reuse Matrix marketing 101: https://ppjet.bouah.net/im-protocols-interop.png (I took a few liberties)

  51. Zash

    oh lawd

  52. Zash

    https://en.wikipedia.org/wiki/Xmpp#Connecting_to_other_protocols

  53. pep.

    Matthew, (please stop me if you're not the right matthew), I'm looking at the Matrix and the french state talk, and you list a set of features for the protocol, notably e2ee _and_ server-side search. How does that work?

  54. pep.

    What do you look at if your server doesn't have plain data

  55. Matthew

    the idea is that you run your own server somewhere trusted to index the data

  56. Matthew

    https://github.com/matrix-org/matrix-search

  57. Andrew Nenakhov

    Those ee2e freaks never cease to amaze me. First they trust no one and demand end to end encryption. Them they understand that total privacy is kinda inconvenient, so they are willing to totally compromise their e2ee to have nice fearures back

  58. Matthew

    (the idea is also to run the server clientside; eg in the desktop apps, to have better control over the plaintext)

  59. Matthew

    weā€™re not trying to do homomorphic encryption or anything fancy

  60. pep.

    Right, so it's more of a client-side feature ish

  61. pep.

    Does the data come from the client, or is the indexer actually plugged on the network

  62. Andrew Nenakhov

    Why not run just your own server and not bother with e2ee?

  63. Matthew

    Andrew Nenakhov: because it sucks if someone pwns your server

  64. Matthew

    and servers tend to be slightly easier to pwn than endpoints

  65. pep.

    I don't actually agree with the last comment, but I do with the previous one.

  66. Zash

    Got stats on that?

  67. pep.

    And as a server admin I'd like to not be able to see my users' data

  68. Matthew

    pep.: in the linked project, the data comes from the network

  69. Matthew

    we are having second thoughts on whether thatā€™s the right design

  70. Andrew Nenakhov

    You mean than android phones that can pe pwned with a png oic?

  71. Matthew

    zash: just common sense that itā€™s easier to pwn some random crappy homerun vps than an iphone

  72. pep.

    Matthew, you mean an iphone not pin-locked? :P

  73. Matthew

    also, itā€™s easier to find servers and theyā€™re tend to be turned on all the time

  74. Matthew

    and they gather more data and metadata than a client

  75. Matthew

    *shrug*

  76. Andrew Nenakhov

    > And as a server admin I'd like to not be able to see my users' data I mean, the only security threat that e2ee helps is server operators. If you are your own operator you dont need to protect against yourself

  77. Zash

    So nothing to back that up?

  78. pep.

    Andrew Nenakhov, not sure if I read your message correctly, but yeah, as a server admin I'd like not to be able to sell (give) my users' data to any government or whatever

  79. Andrew Nenakhov

    > And as a server admin I'd like to not be able to see my users' data That's easy. Never look at it.

  80. pep.

    read my last message

  81. Andrew Nenakhov

    Oh right. Do not host servers with data from strangers.

  82. pep.

    What have strangers to do with that

  83. Zash

    Don't host servers to begin with. Or use computers! Moving into the woods and growing potatoes is the final solution to all tech problems!

  84. Andrew Nenakhov

    If you have a known people who's data might be asked for retrieval by government, you'd better not have them on your server in the first place

  85. mathieui

    why?

  86. Andrew Nenakhov

    This obsession with encryption is unhealthy. :-/

  87. Andrew Nenakhov

    If users want e2ee, fine

  88. mathieui

    people who are in trouble with their governments do not have the right to use IM?

  89. Andrew Nenakhov

    Just dont ask for server to nicely find your chats from last year by fulltext

  90. pep.

    Matthew, do you have resources describing what e2ee in matrix protects from (what goals)? or can you summarize it quickly?

  91. Andrew Nenakhov

    As a person who was visited by FSB thugs 4 times last year pressing me to have backdoors in our app... I do more than most people to protect rights of users to use IM

  92. Andrew Nenakhov

    I also know that 80-90% of e2ee users in russia are junkies

  93. Zash

    Beware selection bias :)

  94. Andrew Nenakhov

    Like, literally, junkies and their drug suppliers

  95. pep.

    So what

  96. pep.

    It's not worth giving options to the other 10%?

  97. Andrew Nenakhov

    So im allergic to e2ee demands. )) Because i have a very accurate mental image of an average user

  98. Andrew Nenakhov

    Also worth noting, that junkies are MUCH more inclined to pay for their privacy than those other 10%

  99. pep.

    I'm not denying that what I'm seeing is also crypto junkies. That doesn't mean I'm excluding legimate cases entirely, (whatever legitimate means)

  100. Matthew

    pep.: https://docs.google.com/spreadsheets/d/1Bv2Pf4rz62nB8omDFoolRmONmU47zIeGewJBbPeADoM

  101. pep.

    Thanks

  102. Matthew

    is some brief notes on matrixā€™s e2ee threat model from a while back

  103. Andrew Nenakhov

    Somehow these who love freedom and are offended by idea of being spied upon rarely pay. I guess that has to do with them treating e2ee as their constitutional right

  104. Andrew Nenakhov

    And noone pays for constitutional rights)

  105. Matthew

    (btw, itā€™s a pleasure to be having constructive xmpp<->matrix convo; bridging ftw)

  106. pep.

    :)

  107. pep.

    I know right, bridging ftw: https://ppjet.bouah.net/im-protocols-interop.png :P

  108. Matthew

    i saw :p

  109. pep.

    Do you know a bit about OMEMO, and do you think that'd be compatible with Olm?

  110. pep.

    As in, is that even bridgable

  111. Zash

    Didn't they differ in some tiny part like IV or somesuch?

  112. pep.

    that would suck

  113. pep.

    hmm, the certificate changes incorporated in synapse 0.99, that seems a bit meh. Judging how people never update their deployment, you're basically cutting off federation with them on a 3-months (was it?) notice

  114. pep.

    Where did I read that again

  115. Zash

    It was in the talk IIRC?

  116. pep.

    There's a bit in the talk, but not the notice period

  117. pep.

    https://github.com/matrix-org/matrix-doc/pull/1711/commits/f30e6851127874739659ffe2b2c211c4db6e50f0#diff-14fe96e0952d0411db3e9ecbbddce789R53 I remember reading this

  118. pep.

    Or my browser remembers, rather

  119. pep.

    "Once everybody has migrated off to v3 rooms, we'll be killing off v1 rooms", so, almost never :x

  120. Zash

    Let me tell you about Groupchat 1.0

  121. pep.

    I was going to mention it yeah

  122. Zash

    That was "The old thing" back when MUC was first written

  123. Matthew

    the difference is perhaps that weā€™re in position to upgrade a bit more ruthlessly and proactively

  124. Matthew

    and can massively cheat because thereā€™s only one usable server

  125. pep.

    That surely simplifies lots of things. You're not in control of every deployment though

  126. pep.

    I think that's the biggest barrier

  127. Zash

    I'm sure we could have done that in 2003 when jabber.org was still The Place

  128. Matthew

    of course, but if we ship synapse 1.0 that refuses to talk to self-signed certs and put it on the disproportionately large matrix.org, i suspect folks would get around to chucking a real cert on their servers

  129. Matthew

    and weā€˜ve given a month for folks to sort themselves out

  130. Matthew

    it remains to be seen if thatā€™s enough

  131. Matthew

    but iā€™d prefer to set a fast tempo for this sort of thing, and coincide it with the 1.0 etc

  132. Matthew

    and yes, i bet in the jabber.org days you could have done similarly for xmpp

  133. Matthew

    and yes, i know omemo, and it is compatible with olm (in fact the omemo xep at one point adopted olm). but that doesnā€™t help when the underlying protocols are entirely different

  134. pep.

    I was just curious to know if it was compatible enough to work over a bridge

  135. Matthew

    itā€™s like saying that xmpp and nntp both use tls, and then being sad when they canā€™t talk to one another

  136. Zash

    There comes a point where if you do that, you would be cutting yourself off from the wider federation.

  137. Matthew

    no, you always have to reencrypt e2e over a bridge

  138. Matthew

    or have a multihead client

  139. pep.

    yeah ok

  140. Zash

    Matthew: I don't think the low-level protocol matters for that. OTR "works" over any transport.

  141. Matthew

    zash: only because otr is used for plain text payloads

  142. Zash

    It'll be more a matter of how what bits goes into OMEMO and OLM and whether they can come out the other end

  143. Zash

    Matthew: So is OMEMO

  144. Matthew

    whereas omemo and olm encrypt entire objects aiui

  145. Matthew

    or at least olm does

  146. Zash

    No, OMEMO is jsut the plain text body

  147. Matthew

    oh, ok

  148. Zash

    That's one of the problems some people have with it

  149. Matthew

    well, i guess we could do a dialect of olm which only encrypts the plaintext body, but thatā€™s a bit bleurgh

  150. Zash

    Right

  151. Matthew

    especially as matrix is about syncing objs rather than IMs in the end

  152. Matthew

    weā€™re going to take a look at replacing olm and megolm with mls, anyway

  153. Matthew

    which at least might get everyone on the same ratchet

  154. Matthew

    but youā€™d have the same problem of what layer you encrypt at

  155. pep.

    yeah

  156. Matthew

    in terms of the body or the whole stanza (or event in matrix terminology)

  157. pep.

    What I'd like to have, is a client implementing the component interface, and being able to run bridges etc., this way I wouldn't care about these bridges decrypting and reencrypting

  158. Matthew

    basically, e2ee + bridging = sadpanda

  159. Matthew

    unless you run the bridge clientside, but then youā€™re basically back at a multiheaded client again.

  160. Zash

    and the cycle continues

  161. Matthew

    loads of the matrix bridges are built that way tho (whatsapp, imessage, signal etc)

  162. Matthew

    inderd

  163. Matthew

    and indeed

  164. Matthew

    i donā€™t think itā€™s that unreasonable to say that if you want e2e you should be on the same network tho

  165. Matthew

    assuming you have bridged public rooms and insecure bridged dms

  166. pep.

    I don't think it's reasonable to say that to users. They don't understand they're using Matrix or XMPP and they really don't care. Or at least my mom doesn't :)

  167. Zash

    That basically goes with all more advanced native features

  168. Matthew

    then perhaps there is more use for a ā€œjust the payloadā€ e2e dialect

  169. Matthew

    for bridging purposes

  170. Zash

    When doing bridges, there'll usually be things that can't be translated. So you end up with the lowest common denominators.

  171. Matthew

    have filed https://github.com/matrix-org/matrix-doc/issues/1871 fwiw

  172. pep.

    :)

  173. vanitasvitae

    Matthew: nice to see you in this room :) Had some enlightening talks with matrix folks at fosdem

  174. vanitasvitae

    Very excited that you seem to have found some solutions to the "fingerprint flood problem" :D

  175. Matthew

    cool :) glad you were able to sync with folks on our side

  176. Matthew

    and yup, cross signing is looking promising

  177. Matthew

    although we still have some thinkos in the current spec

  178. Matthew

    and need to do a 3rd rewrite

  179. Matthew

    https://github.com/uhoreg/matrix-doc/blob/cross-signing/proposals/1680-cross-signing.md is the 2nd iteration of it

  180. Matthew

    in case thereā€™s anything of interest there.