XSF Discussion - 2021-03-12

  1. Guus

    Where is defined how a domain best regards the status of a remote entity, when the federation between the two domains gets disconnected?

  2. Zash

    Look at the circumstances of the disconnect and then ... do something. Or nothing.

  3. jonas’

    Guus, what do you need that status for?

  4. Guus

    jonas’ Presence status (are contacts on a remote domain for which federation got disconnected considered offline?) or MUC room occupancy (are they still part of the room?)

  5. Guus

    jonas’ Presence status (are contacts on a remote domain for which federation got disconnected considered offline?) or MUC room occupancy (are they still an occupant of the room?)

  6. jonas’

    going by the bare bones standards and extrapolating from there, presence status should not be affected by a link going down until you run the next presence probe

  7. jonas’

    the next presence probe will then either succeed (yay) or fail to establish s2s (at which point you have a proper type='error' presence you can s et)

  8. jonas’

    the next presence probe will then either succeed (yay) or fail to establish s2s (at which point you have a proper type='error' presence you can set)

  9. jonas’

    of course, you may decide to run a bunch of presence probes (e.g. up to 5% of the remote roster entries or something) right away when a federation link dies with abnormalities (such as layer 3/4 errors, <shutdown/> stream error or things like that)

  10. jonas’

    Guus, reverse question: how do you define "federation between the two domains gets disconnected"?

  11. Guus

    jonas’ the last s2s socket between the two being disconnected, I suppose.

  12. Guus

    which is interesting if not bidirectional.

  13. jonas’

    yeah, I wouldn’t take any judgement based on that alone -- some domains for example close sockets which aren’t used in a while

  14. Guus

    jonas’ that's actually what caused me to start thinking about this. Re-connection can occur to a different host, which introduces some nastiness in our implementation.

  15. Guus

    fwiw, I tend to agree with you - but could not find any documentation on it.

  16. Kev

    OTOH you may have some situations (we have) where as soon as a link goes down you know it’s disconnected and want to act accordingly.

  17. Kev

    (Never with ‘real’ S2S though, I think)

  18. mdosch

    > yeah, I wouldn’t take any judgement based on that alone -- some domains for example close sockets which aren’t used in a while I'm not even aware what my server does. Have you set anything in that regard in your prosody?

  19. jonas’

    mdosch, I had a module loaded which does that for a while on s.j.n, but I unloaded it because it was suspect of having a memory leak

  20. jonas’

    but I still see s2s dropping off between crawler runs, so at least some other domains close their s2s when idle

  21. mdosch

    I also see closing of idle connections in my log but I never bothered to check whether it's mine or the remote server doing this. ^^

  22. mdosch

    It's the remote > Session closed by remote with error: connection-timeout (Idle connection)

  23. jonas’

    prosody doesn’t do it by default

  24. mdosch

    siacs, blabber, fu-berlin. Seems to be all ejabberds indeed.

  25. Ge0rG

    There is one other server that closes s2s to me and then their DNS fails

  26. menel

    I often loose presence in the conversations muc due to remote idle timeout. (Ejabberd) and its not reestablished by its own for some time.

  27. Ge0rG

    If only there was a XEP to discover loss of MUC connectivty.

  28. Zash

    In theory it should reestablish s2s when needed. In practice...

  29. mdosch

    grep -cE quicksy\.\*Idle /var/log/prosody/prosody.log :( 70

  30. mdosch

    That seems to be… a lot.

  31. menel

    mod_s2s_keepalive didn't help, I suppose it doesn't affect the remote idle timeout only mine

  32. Holger

    The real question is why re-establishing a new connection fails.

  33. menel

    True ,but on my side of the logs there is nothing.. Or maybe I try debug first.. Let me check

  34. Holger

    I mean why would the old, idle connection survive under circumstances where a new connection can't be established?

  35. Kev

    In theory, you should be able to throw away S2S at any point without any user noticing.

  36. Kev

    In theory :)

  37. menel

    Its only conversations muc, I will look

  38. mdosch

    COM8: Mar 12 12:15:49 s2sin5609d9a60bf0 info Incoming s2s stream xmpp.uwpx.org->chat.diebesban.de closed: Your server's certificate has expired

  39. mdosch

    jonas’: Sell o.j.n

  40. mdosch


  41. Zash

    Is it a good thing that, where with dialback you either got bi-directional connectivity when it was done, with SASL EXTERNAL you can easily end up with only working connectivity in one direction?

  42. COM8

    mdosch: Yes, know about that but due to the current situation I do not have access to my server :(

  43. mdosch


  44. COM8


  45. Kev

    Zash: Oh, you didn’t even always get bidirectional connectivity with dialback :D But I grant it was much harder to end up with one-way stuff.

  46. Zash

    Oh I may actually have either one-way or zero-way dialback with someone.

  47. Zash

    Eh, excuse to push for moar XEP-0288 😀

  48. menel

    Can ejabberd do it?

  49. Zash

    5 second search turns up no evidence that it does

  50. menel

    Yeah, sorry i was lazy, i know i could have just searched😞

  51. Sam

    Another thought, would anyone be interested in a weekly "office hours" session where projects can talk about whatever they want? Eg. a recent improvement to your client, or a year in review, or "one weird trick for making a living in open source" or whatever it is your project does? I'm trying to find ways to make the community more engaged across projects and thought it might be good for engagement

  52. Sam

    Might send out a sign up form and just see if anyone signs up for it.

  53. Ge0rG

    Something like the monthly(?) xmpp meetup?

  54. Sam

    There's a monthly xmpp meetup? (but yes, I guess so)

  55. Ge0rG

    Sam: https://wiki.xmpp.org/web/Meetups/Berlin

  56. Sam

    I'd say this is different just by virtue of being online first and not focused on any geographic area. Probably shorter too.

  57. Ge0rG

    used to be a physical gathering pre-pandemic, then a German jitsi call, but also held in English when there are non-natives

  58. Sam

    At several jobs I've been at we've had a weekly lunch-and-learn sort of thing. You sign up for a slot and can present about whatever you want for a few minutes. I've learned a little about a lot of interesting things from them, and think something similar might benefit this community.

  59. Ge0rG

    Ah, the lunch break plus plus thing.

  60. Sam

    (added the Berlin one to my calendar though, thanks)

  61. Sam

    Although their blog doesn't want to load, so but we'll see.

  62. Sam

    I got access to a BigBlueButton instance recently and am looking for excuses to try it out and see how it compares to Jitsi too, so this may just be an excuse to use that :)

  63. Guus

    Sam: organize one, see if there's interest.

  64. Sam

    Guus: that's what I'm doing here :)

  65. Sam

    Maybe it's worth just sending out a signup form instead of asking though

  66. Guus

    ah, yes.

  67. Guus

    In context of MUC's 'ghost users' handling (https://xmpp.org/extensions/xep-0045.html#impl-service-ghosts): > To help prevent ghost users, a MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user Is there harm in not explicitly checking if the error is in relation to a stanza that the service has previously sent to the user (by considering the user a ghost when a stanza is being parsed that has the user's address in the 'from' attribute, and the user is an occupant of the room that the stanza has been addressed to)?

  68. Kev

    Yes, if you allow ‘normal’ errors to be counted as ‘can’t reach’ errors. No if you ensure you only count ‘can’t reach’ errors, I think.

  69. Guus

    I'm trying to see if I can prevent doing archive lookups to see if the error matches something that was outbound - stuff like that, but I'm also keenly aware that making assumptions could open a vector for abuse.

  70. Ge0rG

    There is also the situation of PM errors ;)

  71. Ge0rG

    Kev: what are the legitimate cases where an occupant could send an error to the room or to another room occupant and not get kicked?

  72. Guus

    I'm only considering the errors listed in the XEP: "<gone/>, <item-not-found/>, <recipient-unavailable/>, <redirect/>, <remote-server-not-found/>, and <remote-server-timeout/>"

  73. Kev

    Ge0rG: “I can’t handle this type of message”, “I don’t allow PMs from people not in my roster”. Anything the client likes, really.

  74. Guus

    (which is what Kev means with 'can't reach' errors, I think)

  75. Ge0rG

    There is also a list of potential error causes at the bottom of https://xmpp.org/extensions/xep-0410.html#performingselfping

  76. Guus

    Ge0rG I'm talking about receiving errors on the service-side. What you refer to would be receiving errors on the client side, I think.

  77. Ge0rG

    Guus: well, my errors also contain s2s errors

  78. Ge0rG

    I'd love to have more explicit lists of error reasons.

  79. Guus

    I'm not following how that's relevant for the service-implementation that I'm working at. I don't see how it would be affected by those errors (which would flow from the local domain of the client to the client, and never touch the target MUC service, I tihnk?)

  80. Ge0rG

    Guus: all MUC interactions go through the MUC service

  81. Ge0rG

    so you have s2s in all directions

  82. Kev

    Guus: I send a PM to you. The MUC server routes it, but can’t reach you, it generates an error. That error could be used to bounce you.

  83. Kev

    And is fine to do so, I think. It doesn’t matter what stanza caused us to realise we can’t reach a user, we can’t reach them all the same.

  84. Guus

    I'm confused - are we just agreeing with each-other here, or are you pointing out something that I missed?

  85. Guus

    I'm basically asking if it's safe to consider an occupant 'ghost' if a message with it as the 'from' arrives at the MUC service for processing, when it has one of the aforelisted errors.

  86. Kev

    I’m agreeing that’s safe, whether it’s a MUC message or MUC PM as long as it’s that type of error, yes.

  87. Guus

    if your PM was to be forwarded by the service to me, but the service can't reach me, it'd bounce (reverting the to/from addresses), where it'd be processed matching what we described above, I think.

  88. Guus

    yey for elaborate agreement. 🙂

  89. Kev

    I note that where the MUC server is collocated with an IM server, you can’t use other bounces for the recipient, it has to only be bounces ‘to’ the MUC service.

  90. Kev

    So the “arrives at the MUC service” bit of your text is important to be taken literally, not just “arrives at the server hosting the MUC service”.

  91. Guus

    oh, I didn't even consider that scenario.

  92. Guus

    but, to entertain the thought: why wouldn't any connectivity-related error be usable?

  93. Guus

    (if the MUC service and XMPP domain are colocated)

  94. Kev

    You’re virtual hosting good.im, muc.good.im, bad.im. I have bad.im blocked by my server, and I’m in a MUC on muc.good.im. A user on bad.im tries to send me a stanza.

  95. Guus

    ah, more scenario that I didn't take into account. We can not host more than one primary domain.

  96. Kev

    S2S fails to my domain from bad.im, generates a bounce. That bounce mustn’t be used to remove me from a MUC on muc.good.im

  97. Kev

    Doesn’t matter, does it? It still applies - I’m blocking just.im, but not blocking muc.just.im :)

  98. Guus

    fair - but is that even a real-world applicable scenario?

  99. Guus

    (still, I wasn't going to implement the processing like that anyways, but I'm grateful for understanding your reasoning)

  100. Kev

    I don’t know. Whenever I’m confident a thing won’t actually happen in the real world...

  101. Guus


  102. Guus

    But my first implementation was on the other end of the spectrum. It would bounce a user only from the one room that the bounce is addressed at. I was considering if I could bounce the user from all rooms.

  103. Guus

    But my first implementation was on the other end of the spectrum. It would drop a user only from the one room that the bounce is addressed at. I was considering if I could drop the user from all rooms.

  104. Kev

    There’s always a danger that someone uses an inappropriate error for a non-remote-server bounce. But it *should* be safe enough.

  105. Kev

    Although I have a bad feeling about item-not-found

  106. Kev

    And recipient-unavailabel for that matter.

  107. Guus

    your implementation doesn't do this?

  108. Kev

    I don’t recall, it’s quite possible we do.

  109. Kev

    I think if you want to be safe, ensure that the error is sent to a room the user is in.

  110. Kev

    So that e.g. mediated invites don’t cause funny behaviour.

  111. Guus

    yeah I'm doing that

  112. Kev

    Maximum safety is only kicking from the room that the error is for, but scenarios where that matters are looking a bit stretched.

  113. Kev

    Hmm, actually.

  114. Kev

    I think you might want to just stick to the MUC that the error is for. And if you want to ensure other MUCs do the right thing, trigger a ping from the other MUCs.

  115. Guus

    that's what my first implementation does (only kick from the addressed room)

  116. Kev

    I’m thinking about scenarios where a stanza from a room crosses paths with the user leaving the room.

  117. Guus

    I'll keep things simple for the first implementation anyways.

  118. Guus

    Optimizations can be applied later.

  119. Guus


  120. Sam

    Who has access to the XSF Calendar? dwd or Guus maybe?

  121. ralphm

    I do. What do you want changed?

  122. ralphm

    Sam: ^

  123. Sam

    I was hoping I could get the office hours added: https://wiki.xmpp.org/web/XMPP_Office_Hours

  124. Sam

    (also someone on the comm team was curious who had access)

  125. Sam

    (also, thanks Daniel for stepping up and taking the first slot! I was concerned my current talk ideas would be far too boring, but A/V calls with OMEMO will be a great one to kick things off!)

  126. dwd

    Sam, I promise I'll do a talk on Messaging In A Pandemic, as soon as I've completed this project at work. But thanks for organizing this.

  127. dwd

    Sam, And also for this: https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/?include_text=1

  128. dwd

    (Which, folks, is in WG Last Call in IETF's kitten WG)

  129. Sam

    dwd: excellent, thanks!

  130. Sam

    (both for doing a talk and for advertising the LC, I probably should have requested feedback from this group)

  131. dwd

    Yeah, I meant to share that on standards@

  132. ralphm

    Sam: starting today?

  133. Sam

    I'll write something up, sharing it here is a good idea.

  134. Sam

    ralphm: starting next Friday

  135. ralphm


  136. Sam

    (the 19th, I believe)

  137. Sam

    yes, that's the one. I can add.

  138. ralphm

    Assuming one hour

  139. Sam

    Yes please

  140. Sam

    I didn't actually think about a time, but that seems sane

  141. Sam

    ralphm: you might link the wiki page in the description or "Where" fields: https://wiki.xmpp.org/web/XMPP_Office_Hours

  142. dwd

    Sam, Your TLS channel binding looks almost embarrassingly simple, but I wanted to look at the OpenSSL APIs for this and see if it's as obvious as it looks. I'll have a handful of editorial fixes for you.

  143. Sam

    dwd: Thank you! It's almost not even worth writing an RFC for. The thing about TLS exporters is that this is basically what they already are anyways, all we're doing is registering it with IANA and making up a string.

  144. Zash

    I think it was, possibly so simple I didn't understand it. Unlike the rest of OpenSSL.

  145. Sam

    I would almost have preferred if we just got rid of all the old channel binding stuff and say "TLS Exporters are channel binding now, everybody make up your own names for your community" since we don't have to do the algorithm ourself anymore

  146. Zash

    Hard part (for us, Prosody) would be getting it into LuaSec and then into distros and figuring out how to get it hooked into the right things.

  147. ralphm

    Sam: looking good like this I think?

  148. Sam refreshes and waits for his calendars to sync

  149. Zash

    Irks me to have to do `if TLS.version == 1.3 then foo else bar` 🙁

  150. ralphm

    Great idea, BTW

  151. Sam

    LGTM, thanks for adding it!

  152. Daniel

    Sam, can you not just make message styling your first talk? or does this take more preperation

  153. Sam

    Daniel: I could if you don't want to be first, I just don't have it fully prepared yet (and also a lot of people really hate message styling, I didn't want the first one to be something a lot of people don't care about or actively dislike)

  154. Sam

    A/V and OMEMO sounds a lot more interesting to me too, so I think it would be a good one to start with

  155. Daniel

    I don’t mind being first. but i rather hear something about message styling than an intro to xmpp tbh

  156. ralphm

    Sam: FWIW, it appears that you also have write access to the XSF Google calendar.

  157. Sam

    Fair enough; maybe I'll swap those around and save that one for a day when nobody else puts something on

  158. Sam

    ralphm: huh, TIL, sorry to bug you for it then

  159. ralphm

    Gladly done, no worries

  160. Daniel

    as far as i understood it the target audience is mostly people in the XMPP-verse, no?

  161. Sam

    I think that can change from week to week, it's whatever the presenter wants to talk about really.

  162. Sam

    Zash: re channel binding, I tend to agree about the TLS version. The problem is that I'm almost certain that certain old ciphers in TLS 1.2 won't actually create unique keying material. If you're confident that you can avoid those, you can likely use this on TLS <1.3, I just don't know how to provide good advise for doing so safely.

  163. Zash

    Which "this" is that?

  164. Sam

    You can use this channel binding mechanism, I mean

  165. Sam

    dwd: RE your channel binding feedback (sorry, when I cleaned out my roster a while back I lost everybodies JIDs): would you prefer a separate "Use with Legacy TLS" section, or just moving that one paragraph into the security considerations? I could see it going either way

  166. Sam

    (or maybe a "Use with Legacy TLS" section that's a subsection fo "Security Considerations"? I dont' know what's normal)

  167. dwd

    I would personally seperate out the legacy TLS stuff into its own section. Could be a subsection in Security Considerations or a new section or a part of 2.1., I'm not fussed.

  168. dwd

    Also, dwd@dave.cridland.net as always.

  169. Sam

    Will do; thanks

  170. Zash

    dwd, if you have a moment, could you look at why I can't reach you from zash.se?

  171. dwd

    I have no idea what's going on with my S2S, actually. Half a dozen sites I can't reach ATM, but I have zero time to go look properly.

  172. Zash


  173. Daniel

    > I think that can change from week to week, it's whatever the presenter wants to talk about really. OK. Let's see where this will lead us then. Personally I would really like to have a thing where I can meet other XMPP developers and workshop new ideas. We have other events that have a more broader audience like the XMPP meet-up. Those can be fun as well but it's not exactly a place where I can get feedback for my new protocol design ideas

  174. Sam

    Oh I think this would be great for that too; feel free to schedule more general round-table style discussions or new idea presentations

  175. mdosch

    nmap -p5269 nimbus.dave.cridland.net Starting Nmap 7.80 ( https://nmap.org ) at 2021-03-12 16:26 CET Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 3.22 seco

  176. mdosch

    Zash: dwd ^

  177. dwd


  178. dwd

    There's a security group I've messed up.

  179. dwd

    Oh, -Pn you'll need, sicne it doesn't (most likely) ping.

  180. dwd

    Yeah, ports are indeed open (I thought so, since that's how I'm sending stuff...)

  181. Ge0rG

    Ports. Used for sending stuff since 1300 BC.

  182. mdosch

    Weird, I tried earlier if your not reachable from my server as well and it seems my message didn't go through. Now I looked at my logs and I see this:

  183. mdosch

    Mar 12 16:22:14 s2sout5609d936daa0 info Outgoing s2s connection mdosch.de->dave.cridland.net complete Mar 12 16:34:43 s2sin5609d9cf3bf0 info Incoming s2s stream dave.cridland.net->mdosch.de closed: stream closed Mar 12 16:34:43 s2sin5609da20bd90 info Incoming s2s stream dave.cridland.net->mdosch.de closed: invalid-namespace

  184. Zash

    I see it get a connection, but then it times out

  185. dwd

    That's all very weird.

  186. Ge0rG

    I can telnet-trigger a not-well-formed, so LGTM

  187. theTedd

    oh, so *now* you people are willing to do talks 🙄

  188. Zash

    Don't say yay before it actually takes place

  189. dwd

    theTedd, Yeah, sorry. This project I'm doing will generate (at least one) talk, but it's likely to "finish" around 3rd April, currently.

  190. mathieui

    theTedd: don't jinx it

  191. theTedd

    dwd, that wasn't directed at anyone specifically, and in your case emergencies are urgent in nature

  192. theTedd

    mathieui, jinx jinx jinx 😋

  193. Sam

    dwd: so I can expect to see you go put your name on right now for mid to late April?

  194. dwd

    Let me get free and clear, and un-burnt-out enough to write a talk. :-)

  195. Sam

    but you could go ahead and reserve a spot to make it all full :)

  196. Ge0rG

    nothing gives as much motivation to prepare a talk as a fixed time slot assignment

  197. theTedd

    deadlines make the world go around