XSF Discussion - 2019-11-20

  1. nyco

    a question: https://fosstodon.org/web/statuses/103166428834063205 @sofia@chaos.social @xmpp hi there! i was wondering if XMPP has any standards or plans for self-verifying IDs? like if my public key (or it's hash) is a4244aa43ddd6e3ef9e64bb80f4ee952f68232aa008d3da9c78e3b627e5675c8 then my id could be a4244aa43ddd6e3ef9e64bb80f4ee952f68232aa008d3da9c78e3b627e5675c8@jabber.ccc.de and so everyone who knows my id automatically has a verified, secure channel to me.. sofia @sofia@chaos.social oh, the same question goes to @matrix , too! it may even be more relevant to #matrix because i think they have a single default e2e encryption scheme, unlike XMPP. #selfVerifyingID

  2. !XSF_Martin

    Like adding your omemo ID to your jid in conversations?

  3. !XSF_Martin


  4. !XSF_Martin

    If you add me with this link in conversations you'll automatically have my omemo key verified. Don't know if it's included in the omemo xep and other programs support this too.

  5. !XSF_Martin

    Maybe Daniel can clarify.

  6. Ge0rG

    !XSF_Martin: I think the underlying idea is to use your key-id as an identifier instead of the localpart of the JID

  7. Ge0rG

    if followed consequently, the domain part will be merely a routing identifier, i.e. "I'm currently holding my temporary state at jabber.ccc.de, but tomorrow it might be fancyjabs.biz"

  8. !XSF_Martin

    Where is this more unique/verified than your jid?

  9. Ge0rG

    The Matrix folks are in the process of retrofitting this mechanism after they found out that having a server responsible for your identity is a "dumb" idea ;)

  10. !XSF_Martin

    Oh, so that would need some sort of registry?

  11. Ge0rG

    !XSF_Martin: no. it would need servers to verify your proof of key ownership

  12. Ge0rG

    !XSF_Martin: but the resulting protocol would be a different subset of Zooko's triangle

  13. Ge0rG


  14. !XSF_Martin

    As a self hoster my domain and my jid on my website is proof enough for me. 😂

  15. Ge0rG

    nyco: does that help in answering?

  16. nyco

    nope, I don't understand this discussion, sorry... :) I suggest some of you (who have fediverse accounts) engage the conversations, or you suggest me a text answer that I will post as @xmpp

  17. Ge0rG

    nyco: text suggestion: In the federated XMPP IM network, user identity is always enforced by the respective servers, allowing for human-readable identifiers, and there are no current plans to change this. You could create an overlay network, where user accounts would authenticate to a server by their keypair, and the username part would be a hash or fingerprint resulting from this. To be secure, that approach would require that a client signs every piece of information that is stored on the server or transmitted to other systems, and each other system will have to verify that signature. The domain part of your ID would become merely a "drop box" for the data sent to you, as you could re-register with your key pair on any other domain, and XMPP would be just a routing layer for your overlay network with your currently-used server as a single point of failure. Eventually, you will realize that XMPP is not a perfect routing layer for such a protocol, and that there are better protocols for the requested traits of Zooko's triangle <https://en.wikipedia.org/wiki/Zooko%27s_triangle>

  18. Ge0rG

    I hope this take isn't too cynical

  19. flow

    at some point you end with the "dead drops" that vuvuzela.io uses

  20. Ge0rG

    Vuvuzela: > Vuvuzela is a private chat application that hides metadata, including who you chat with and when you are chatting. Also Vuvuzela: > Create your Vuvuzela account [_] I am not a robot (reCAPTCHA)

  21. Ge0rG

    Only reinforces me in my opinion not to trust things hosted on .IO domains

  22. David Cridland

    nyco, I think you touch on the answer there. Using hashes as addresses (which was first discussed for email, incidentally) has problems because you end up with a fixed (ie, non-agile) encryption mechanism. Moreover, what if a key is compromised? To have access to the key ends up implicitly granting access to the identity, so if your key is changed then so must your address. XMPP has tried overloading portions of the address with meanings other than routing; it really is a painful problem when those meanings diverge.

  23. David Cridland

    nyco, An alternative solution is a secure method for binding a key to an identity. X.509, for example, uses a trusted third party to verify this, PGP uses a web of trust instead for much the same result. Many E2EE solutions use an-person verification solution (QR codes, fingerprints, etc), or simply "leap of faith", where you prove consistency rather than identity.

  24. David Cridland

    nyco, FWIW, I don't think the question refers to Zooko's Triangle, since the question doesn't care about human readable names, but that notwithstanding, Ge0rG's answer is correct.

  25. Ge0rG

    While the question does not refer to it, I still think that it's a valuable hint in understanding the problem space.

  26. Ge0rG

    Even though I disagree with the Wikipedia list of things that have "solved" Zooko's

  27. Guus

    What's the most up-to-date specification that we have on message deletion?

  28. Guus

    or ephemeral messages?

  29. Guus

    There was some discussion on this a while back, but did that ever make it into a XEP?

  30. Zash

    Guus: You mean actual deletion/retraction or the whole routing 2.0 thing?

  31. Zash

    https://xmpp.org/extensions/xep-0424.html and https://xmpp.org/extensions/xep-0425.html are new

  32. Guus

    424 is what I'm after

  33. Guus


  34. Link Mauve

    “09:14:13 Ge0rG> Only reinforces me in my opinion not to trust things hosted on .IO domains”, yet you use poez.io!

  35. Ge0rG

    origin git://git.poez.io/poezio (fetch) Damn it.

  36. pep.

    Ge0rG, re hash as localpart, there could be non-trivial infrastructure added (DHT etc.) to allow this, and then a different bind method etc.

  37. pep.

    The rest of the addressing would be the same

  38. pep.

    It's not done at the moment, but un the same way we now have a CA XEP we could have a DHT xep :P

  39. Ge0rG

    pep.: you'd only lose one of the basic aspects of XMPP

  40. pep.

    how so

  41. Ge0rG

    that servers are responsible for managing accounts on them

  42. Ge0rG

    a completely different question: a friend of mine is looking to integrate with Google Firebase via XMPP, and I can't even understand how Google is making use of XMPP for that API from the official docs

  43. Ge0rG

    are there any resources for people who *do* know how XMPP works?

  44. ralphm


  45. ralphm


  46. Zash


  47. Guus

    > but who will be where will be announced closer to the event.

  48. pep.

    Ge0rG, servers could still be responsible for managing accounts on them. A user could choose where to have their account managed, and could also easily decide to move them around

  49. Guus

    Interesting to find out if we get more space this year!

  50. pep.

    (that's one possible answer to <moved/>)

  51. Zash

    People lose their keys. Massive pain to have a key be your identity.

  52. pep.

    Thaat's their issue, and it's always been

  53. pep.

    They currently lose their password it's the same story

  54. jonas’

    a password can be changed

  55. Zash

    Has Summit 2020 dates been set?

  56. jonas’

    if your identity is tied to your key ...

  57. pep.

    jonas’, the operator has the responsability to decide if they allow giving access to a potential attacker :)

  58. pep.

    I prefer to leave this responsability to the user themselves tbh

  59. pep.

    Zash, yep, before FOSDEM

  60. Zash checks https://wiki.xmpp.org/web/Conferences/Summit_24

  61. pep.

    it's been twitter somewhere and on the wiki yeah

  62. pep.

    it's been tweeted somewhere and on the wiki yeah

  63. pep.

    ralphm, any idea why Matrix is not included in the realtime lounge again?

  64. pep.

    Why they can be separate from everyone else

  65. pep.

    Next year can we have XMPP splitted as well if so?

  66. Zash

    Marketing reasons I assume

  67. pep.

    Why can't we have marketing as well

  68. Guus

    pep. Probably history: the Realtime Lounge predates Matrix.

  69. Guus

    at the time, joining forces gave better chances of all related projects being accepted.

  70. pep.

    That doesn't really explain it to me. "Hey Matrix! We're going to put you in the realtime lounge", done.

  71. Guus

    That suggests that Fosdem organisation re-groups they applicants.

  72. pep.

    I already raised this "issue" a few months ago fwiw

  73. Guus

    The realtime lounge is being asked for by a group of related projects. Matrix did their own request.

  74. David Cridland

    Ge0rG, The Firebase XMPP interface is actually a legacy one, which is why the docs are sparse.

  75. Guus

    We could ask them to join us, or we could ask for our one spot

  76. pep.

    Guus, maybe we need to do the opposite then? Request a slot for XMPP itself

  77. Ge0rG

    David Cridland: what's the official FCM API if you need upstream messages?

  78. David Cridland

    I thought it was HTTP/2 for the shinies - you need messages from device to backend, do you?

  79. Ge0rG

    I already know from Android development that you need at least one full-time developer just to keep up with Google changing APIs

  80. Ge0rG

    David Cridland: exactly

  81. Guus

    pep. yes we could do that. I'm not sure if that improves our chances of getting a spot though.

  82. Seve

    If we can apply to both, I guess is fine. Otherwise we would risk it and lose the spot entirely, is it?

  83. David Cridland

    Ge0rG, Send a normal push and then have the app callback with an XMPP session? :-)

  84. pep.

    Guus, well Matrix is getting their own.. I'm not sure why not

  85. David Cridland

    Also, didn't know there was Saturday-only and Sunday-only stands.

  86. Ge0rG

    David Cridland: was that ironic?

  87. Guus

    because there's a status quo. Also, other projects in the realtime lounge put in quite some effort to get things organized.

  88. ralphm

    pep. we can totally have XMPP marketing there, and we've done that since forever

  89. David Cridland

    Ge0rG, Not entirely. But I don't know that it's a terrible idea - I find the feedback from Push pretty poor at the best of times.

  90. ralphm

    Doing it as the Realtime Lounge just gave us a better chance of being accepted, than each individual project (XMPP, Jitsi, other RTC projects) on their own

  91. Ge0rG

    David Cridland: https://firebase.google.com/docs/cloud-messaging/android/upstream clearly says that you need FCM XMPP for that

  92. David Cridland

    Ge0rG, Oh, still? Well, that's good I suppose.

  93. Ge0rG

    David Cridland: feedback from your developers doing Push regarding reliability / real-time?

  94. pep.

    ralphm, people see "Matrix" and they don't see "XMPP"

  95. pep.

    We're not playing on the same field

  96. Zash

    pep.: XMPP isn't a FOSS project

  97. ralphm

    Zash: the dates were announced even by e-mail on several mailinglists on Aug 11, including summit@.

  98. David Cridland

    Ge0rG, You might be able to make some sense out of the Python asyncio FCM library, I know that uses XMPP.

  99. ralphm

    pep. on the schedule you mean, yes, that is true. On the floor, they totally see XMPP.

  100. pep.

    Zash, that's another problem sure. XMPP unlike Matrix is not a standard, an implementation, a company, etc. all at the same time

  101. Guus

    Note that we get a lot of benefit from bundling forces. Saul does most of the organizing and often is manning the devroom too.

  102. Guus

    Our exposure on the floor is pretty good

  103. Ge0rG

    David Cridland: let's move this into private chat. I'm currently looking at Smack as an FCM client library

  104. Guus

    (we could improve the look and feel, but there's definitely a XMPP presence - basically all of the lounge is XMPP)

  105. pep.

    Ge0rG, I think our exposure is pretty bad, but that's another topic

  106. pep.

    In the corner where nobody goes

  107. Guus

    Yeah, we've asked for more space in a different location

  108. Guus

    but that wouldn't change by going alone - if anything, we'd get less space.

  109. Guus

    but that wouldn't change by going at it alone - if anything, we'd get less space.

  110. David Cridland

    FWIW, +1 to different location - we're very much in the corner at the moment. But also quite happy as a group.

  111. Guus

    For years, XMPP effectively took all of the floor space that is ment to be shared with a few projects - so we're not doing bad there.

  112. Guus

    Yeah, the location thing has, again, be asked for explicitly. But that's out of our hands.

  113. Zash

    It's a pretty cozy corner FWIW

  114. Guus

    The corner isn't to bad, but it now has to many stands in it

  115. David Cridland

    ralphm, Oh, my wife says to ask you for green hoodies this year.

  116. pep.

    Who decides for the hoodies btw? Can anybody see the swag before it gets printed?

  117. Guus

    So, by doing our own application, we'd reduce the chance of being accepted, run the risk of getting less space on the floor, will have to do our own organizing (especially for the Dev room). Only to get 'XMPP' printed on the folders? For me, that's not enough added value.

  118. Guus

    pep. we desperately want people to provide content there!

  119. Guus

    last year, Dave and Ralph came up with designs

  120. David Cridland

    I didn't!

  121. Guus

    but please, suggest stuff

  122. Guus

    the bottle openers were yours!

  123. Zash

    And as noted, FOSDEM is more for FOSS projects, which XMPP isn't.

  124. David Cridland

    Oh, the text, in which I missed a better gag.

  125. Guus

    See, we need better content pep. - dwd has been failing us! 😃

  126. David Cridland

    The original (grey) hoodies were my design, though.

  127. Zash


  128. David Cridland

    I think we should do pens and notebooks if we can, must be a "messaging" joke there.

  129. Zash

    Letter openers?

  130. Zash

    For extra fun at the airport

  131. Guus

    empty cans with strings.

  132. Zash


  133. Guus

    we'll brand them "Matrix" >;-)

  134. David Cridland


  135. Guus back to fixing bugs left by on 'dave' in our codebase

  136. Guus back to fixing bugs left by one 'dave' in our codebase

  137. David Cridland

    A new t-shirt design would be good, if we could think of one.

  138. David Cridland checks name

  139. David Cridland

    Can't be me then.

  140. Guus

    stream management.

  141. David Cridland

    That was Jonny.

  142. Guus

    fun things happen when a client reconnects using the same resource

  143. David Cridland

    Oh, interesting.

  144. pep.

    Guus, isn't that what is done nowadays? :x

  145. pep.

    (using the same resource)

  146. Zash

    Replacing the previous one instead of resuming it?

  147. pep.


  148. Guus

    There's a couple of things going wrong. Long story short: the new session is kicked after the TTL for the original session elapses.

  149. Guus

    But with various periodic tasks, and behavior different between clients, and a requirement of a previous session to have existed, made this hard to reproduce 🙂

  150. Zash

    Reference to the resource instead of the session itself?

  151. ralphm

    pep., I shared my designs with several people involved with organising for the Summit / FOSDEM before they went to print

  152. Guus

    Zash yup

  153. Guus

    ralphm Do we still have orange ones? I ruined mine 😞

  154. ralphm

    David Cridland, suggestion of 'Green Hoodies' noted.

  155. Zash

    Green like the logo?

  156. David Cridland

    ralphm, It'd be quite fun to have a rainbox of colours available.

  157. Zash

    Logo colors?

  158. ralphm

    Guus: a couple, but maybe not all sizes. I'm not at home right now, but can check.

  159. Zash

    Photo shoot with people arranged in the shape of the logo, with proper colors?

  160. Guus

    David Cridland pretty expensive too, if you want to do them in all sizes.

  161. Guus

    ralphm thanks

  162. ralphm

    David Cridland, the problem with many color options is that I would want to know upfront who wants which size/color.

  163. David Cridland

    FWIW, I have to admit I don't much like the sleeve print. Perhaps I'm too old and uncool for that.

  164. MattJ

    Potentially anyone travelling from the UK with merchandise for sale at FOSDEM may be in an interesting situation next year

  165. ralphm

    David Cridland, quite

  166. David Cridland cries

  167. Link Mauve

    MattJ, nah, https://twitter.com/julianpopov/status/1185664196178042880

  168. ralphm

    MattJ, why? You'd leave before brexit, but come back after :-D

  169. Link Mauve

    The XMPP logo we printed on the flyers for Capitole du Libre last weekend was much darker and less shiny than on a computer screen. :(

  170. MattJ

    Would that make me an exporter from the EU??

  171. Link Mauve

    Paper is hard.

  172. ralphm

    Also, the better plan recently has been shipping it to my address, as we also have a van for the event.

  173. Ge0rG

    ralphm: add some XMPP-branded sweets and you can spray "free candy inside" on the van door

  174. Guus


  175. ralphm

    Yeah, our region is market leader in that stuff. Should be easy.

  176. ralphm

    Reminds me of the Breaking Bad session at RealtimeConf: https://vimeo.com/77799055

  177. ralphm

    Oh, how I miss RealtimeConf

  178. MattJ


  179. pep.

    hah that's a cool session

  180. Zash

    pep., did you have Prosody stickers btw?

  181. pep.

    I did

  182. pep.

    There's like 5 left

  183. ralphm

    pep., 'cool' doesn't even begin to describe this. This was a conference with its own novel, graphic novel, and play + soundtrack (played live in between the sessions)

  184. ralphm puts on https://benmichel.bandcamp.com/

  185. pep.


  186. pep.

    thoughts about having the muc service also provide an http upload/jingle component or sth to upload files? For when the user server doesn't provide it.

  187. pep.

    Maybe there are times where it makes more sense to have it on the muc at all rather than the user's server.

  188. Ge0rG

    pep.: I totally agree. It's also a minor privacy leak to see your private server's HTTP URL in a MUC

  189. Zash

    pep.: Not opposed. Authz via affiliation or such?

  190. pep.


  191. Ge0rG

    Zash: via occupancy?

  192. Ge0rG

    Maybe the MUC domain should just allow the 0363 IQs to all JIDs that are joined to at least one MUC

  193. MattJ

    Interesting that you could then upload the files to a MUC service and then post the links elsewhere

  194. Zash

    O(rooms) lookup?

  195. pep.

    MattJ, I guess that's "already an issue" anyway? you can create an anonymous user on most public servers and upload something there

  196. pep.

    Or even just any real account

  197. MattJ


  198. Zash

    If it's tied to a single room then it could automatically be broadcast on upload too

  199. Ge0rG

    Good luck figuring out the race conditions between the sending client's message and that

  200. nyco


  201. nyco


  202. pep.

    "A web page is slowing down your browser. What would you like to do?"

  203. nyco

    indeed, it may be slow weird on my old computer and tab-overloaded browsers I don't have this warning