XSF Discussion - 2021-05-18

  1. moparisthebest

    qrpnxz: yes

  2. qrpnxz

    I am severly confused by s2s comm. After a lot of reading, I think I'm close to understanding. RFC-6120 states that "foregoing considerations imply" that while completing STARTTLS and SASL negotiation two servers would use one TCP connection. Good. Therefore, bidi (XEP-0288) can be agreed upon during this period. The question is then how to do two connections. After negotiating the first connection, am I supposed to end the receiving server's stream, dial the initiator (with the same `id`?? seems illegal), and negotiate that connection, after which the initiator ends their stream on the second connection, and then we can talk to each other?

  3. qrpnxz

    Because that kind of seems insane.

  4. qrpnxz

    or i guess that the two streams are supposed to have different IDs and the second stream can reply to <iq/> from the first on the other connection without any problem just by having the id of that request?

  5. qrpnxz

    ok so it looks like after SASL streams must be restarted. I suppose what you do is that the initiator starts a new stream, but the receiver instead goes and creates the second TCP conn?

  6. Zash

    When you said bidi I thought of https://xmpp.org/extensions/xep-0288.html where there's no second connection.

  7. Zash

    In standard xmpp without that, the other server creates their connection back whenever they want, usually when there's a reply or something to deliver. it's completely independent of any prior connection.

  8. Zash

    Unless you use Dialback, then there's a bunch of connections in every direction and everything is confusing and backwards.

  9. qrpnxz

    Ok i think it should be as i now understand it then. Good.

  10. qrpnxz


  11. Zash

    Dialback being https://xmpp.org/extensions/xep-0220.html

  12. qrpnxz

    dialback looks like something i never wanna implement

  13. Sam

    We should consider obsoleting dialback again.

  14. moparisthebest

    Why? DNSSEC adoption keeps going up

  15. moparisthebest

    And does anyone validate TLS certificates when doing dialback? That seems to work fine

  16. qrpnxz

    it's the other way around mate, who'd wanna do dialback after validating TLS

  17. moparisthebest

    I mean when you connect to bob.com's server, you validate it has a valid cert for bob.com before sending anything

  18. qrpnxz

    Right, with TLS

  19. moparisthebest

    Yes, dialback is still needed for validation the other direction, to prove to bob.com who you are

  20. qrpnxz

    That's also with TLS

  21. moparisthebest

    With sasl external it is, but dialback also works fine in the absence of that I guess

  22. qrpnxz

    TLS and SASL support is required, and SASL EXTERNAL is also required for servers. So there's just about zero reason to do dialback afaict

  23. Zash

    There's some servers that run with self-signed certs, some with expired certs...

  24. qrpnxz

    cron to the rescue

  25. MattJ

    I would strongly urge anyone implementing s2s today to just not implement dialback

  26. mdosch

    > There's some servers that run with self-signed certs, some with expired certs... Expired certs are probably just caused by mistakes, but why would you use self signed certs nowadays?

  27. qrpnxz

    In case the domain is irrelevant.

  28. qrpnxz

    and you don't need hierarchy

  29. mdosch

    What do you mean by irrelevant?

  30. qrpnxz

    not applicable or pertinent

  31. mdosch

    If you want to do s2s with others I think it's relevant.

  32. qrpnxz

    yes for s2s it's very relevant

  33. qrpnxz

    thought you were asking in general

  34. qrpnxz

    for things using tls

  35. mdosch

    It was about s2s afaiu.

  36. Kev

    Dialback’s pretty convenient for testing, mind.

  37. qrpnxz

    for testing what

  38. Kev

    For quickly running up a bunch of servers without having to generate a root, trust it in all the configs, issue certs etc.

  39. Kev

    For testing the server.

  40. qrpnxz

    sounds like you can also just whitelist these

  41. Zash

    I found it easier to get certs for my testing servers.

  42. flow

    plus, at some point you may want to test the code involving certs anyway :)

  43. Kev

    You *can* do it by generating a CA, committing configs with that trusted and issued certs in etc., but...

  44. Kev

    flow: Are you genuinely going to suggest that we don’t test our EXTERNAL paths?

  45. flow


  46. flow

    anyhow, all that talk about dialback being so complex actually makes me want to implement it

  47. flow

    of course, I first would need to implement an XMPP server

  48. flow

    not sure if I am up to that challenge, I like my life as client library dev very much

  49. Kev

    But tests involving TLS are desperately slow, so being able to test with dialback is quite desirable (or you can use null cyphers in TLS or something, but we compile with those disabled).

  50. qrpnxz

    i want to implement a server and client rn. So far I've not been discouraged. XMPP is rather straightforward for the most part.

  51. flow


  52. qrpnxz

    right now

  53. Kev

    So our S2S tests don’t do TLS except those that test TLS.

  54. Kev

    (Well, our in-process tests. Our integration test suite uses TLS)

  55. flow

    qrpnxz, implementing client *and* server is a huge task, fwiw

  56. qrpnxz

    i'm starting with server

  57. flow

    I was suggesting to start with the client side of things

  58. flow

    I was about to suggest to start with the client side of things

  59. flow

    but go for it, you can only learn from it

  60. qrpnxz

    so XMPP: Core AND XMPP: IM AND i have to learn GUI? no way lol

  61. qrpnxz

    how about just XMPP: Core server and done

  62. flow

    sure, that's the nice thing about XMPP, you can implement a very basic server

  63. qrpnxz

    Clients not even required really. You can just make the server if you don't plan on having other users LOL

  64. qrpnxz

    Client's not even required really. You can just make the server if you don't plan on having other users LOL

  65. qrpnxz

    hmm, i don't see a way to make TLS optional without having a dummy feature...

  66. Kev

    In what sense?

  67. Kev

    You just don’t mark it as required.

  68. Kev

    Or if you mean optional to have configured, rather than optional to negotiate, you don’t advertise when it’s not configured.

  69. MattJ

    Basic messaging between clients in Prosody was working in just a few days. It's everything after that that's the difficult part :)

  70. qrpnxz

    > You just don’t mark it as required. Kev: Core says that if it's by itself then it's mandatory by default

  71. dwd

    flow, I've implemented dialback from scratch once, and fixed it at least twice. Don't recommend... it's simple enough to start with, then gets horrendously complex as you add in TLS, BiDi, etc.

  72. MattJ

    I also think I discovered a bug in the XEP the other day

  73. MattJ

    But I haven't reported it because I can't even be sure it's a bug in the XEP, or my understanding of it

  74. qrpnxz

    dwd, basically anything that touches DNS makes me sad

  75. dwd

    qrpnxz, Yes, you have to implement, and negotiate, TLS to be standards compliant. But you can deliberately choose not to.

  76. dwd

    qrpnxz, Actually DNS is the easy bit. Unless you're talking DNSSEC, which then becomes complicated again.

  77. qrpnxz

    MattJ, i'm writing something about a problem in XEP-0288 as well, but first i'm making sure it's actually a problem and/or proposing solution ;)

  78. qrpnxz

    dwd, i see, ew

  79. dwd

    qrpnxz, Especially when deriving candidate subject names.

  80. dwd

    qrpnxz, And most interested in fixes for XEP-0288, of course.

  81. qrpnxz

    > implement, and negotiate, TLS to be standards compliant serveral places in the standard hint at situation in which you get to, for example SASL, and tls is not negotiated yet. And indeed if you you have both tls feature and something else, tls is optional.

  82. qrpnxz

    but i don't see a way to only have tls feature, and have it be optional, yet you have to show tls feature, so... a pickle

  83. qrpnxz

    well, i do see a way: a dummy feature. But kind of ugly

  84. MattJ

    If you don't have any other features how is it optional?

  85. MattJ

    The stream wouldn't be able to proceed

  86. dwd

    qrpnxz, You just don't advertise TLS, and do advertise SASL.

  87. qrpnxz

    i just specifically said that if it's the only one std says that it's mandatory by default so idk where you are getting i said that

  88. qrpnxz

    not advertising tls is not the same as optional tls, also you cannot NOT advertise tls

  89. qrpnxz

    you must advertize tls if you support it, which you must support because of the std as well

  90. MattJ

    You're saying you want a scenario where you advertise only TLS, but you want it to be optional

  91. dwd

    qrpnxz, You really can. You're no longer standards compliant, because we think you should do TLS. But if you have a compelling reason not to be standards compliant, then go for it.

  92. qrpnxz

    mattj, it's not necessary that i want such a scenario, but that it's kind of ugly the way you have to do it (dummy feature)

  93. dwd

    qrpnxz, I don't get where you're coming from with this "dummy feature".

  94. Kev

    It’s not a dummy feature.

  95. qrpnxz

    if i have tls feature, and another feature that is not tls, and tls does not have <require/>, then tls is optional

  96. Kev

    It’s an alternative mechanism.

  97. qrpnxz

    hence if i wanted to make tls optional, and i didn't have a legitimate feature to advertize alongside tls, then i'd have to create a dummy feature that doesn't exist to put along with tls, and then not mask tls as <require/>

  98. dwd

    qrpnxz, If a server doesn't advertise TLS at all - and structurally, it need not - then a compliant client might refuse to continue. But a client that *also* doesn't mandate TLS (which is most of them with non-default configuration) will happily continue without. If you have an alternate stream encryption (or similar), then a client which understands that might negotiate it in preference to TLS.

  99. qrpnxz

    A server that doesn't advertize tls is not compliant, to start. A client that does mandate tls simply doesn't use the feature *if it's voluntary-to-negotiate*.

  100. qrpnxz

    A server that doesn't advertize tls is not compliant, to start. A client that doesn't mandate tls simply doesn't use the feature *if it's voluntary-to-negotiate*.

  101. dwd

    qrpnxz, Have you noted the last bit of https://datatracker.ietf.org/doc/html/rfc6120#section-5.4.1

  102. dwd

    qrpnxz, So if the server doesn't consider TLS to be mandatory but does support it, just don't include <required/> in the stream feature.

  103. qrpnxz

    right, that adds to the brainfuck. That means that there should never be the case that TLS is the only feature and it doesn't have <require/>

  104. dwd

    qrpnxz, I don't understand why this is confusing. And yes, you're right (though <required/> would be redudant in that case).

  105. qrpnxz

    it's redundant, but it's required. They should have just writ it so that without required it's optional to be consistent

  106. dwd

    qrpnxz, Well, sure, and it is. But if the only thing the stream is offering is to negotiate TLS, and you choose not to, then you can't do anything else.

  107. qrpnxz

    it's not optional in that case.

  108. dwd

    qrpnxz, What difference does it make?

  109. flow

    MattJ> But I haven't reported it because I can't even be sure it's a bug in the XEP, or my understanding of it

  110. flow

    standards@ it maybe?

  111. dwd

    qrpnxz, I mean, sure, if TLS is the only thing offered, it follows that it *is* mandatory to negotiate, and therefore the server MUST include <required/>. But in practice, what cases fail to interoperate if it's not included?

  112. Kev

    required only really matters so you know why you can’t continue, rather than aiding interop.

  113. qrpnxz

    none, yet the server is not compliant ;) And if you want to make it optional you have to add a dummy. Not a helpful special case.

  114. Zash

    I don't understand where you got 'dummy' from?

  115. qrpnxz

    do you know what a dummy is

  116. Zash


  117. Kev

    Because no-one who wants to do tls is going to decide they’re not going to do it because it’s not marked as required. And similarly if it’s required you’re not going to be able to continue without it. It’s just useful for debug when things don’t work.

  118. Zash

    Maybe the missing piece is that if you are only offered TLS, the only way to not do TLS would be to do Dialback, which is advertised differently because hysterical raisins.

  119. qrpnxz

    perhaps you missed my message where i explain i copy here: ``` hence if i wanted to make tls optional, and i didn't have a legitimate feature to advertize alongside tls, then i'd have to create a dummy feature that doesn't exist to put along with tls, and then not mark tls as <require/> ```

  120. dwd

    qrpnxz, Why do you think you need this dummy feature?

  121. qrpnxz

    you need it to mark tls as optional if tls is the only legitimate feature

  122. dwd

    qrpnxz, Why do you think that?

  123. qrpnxz

    because that's what the standard says. If it's on it's own, it's required. Period. So if it's gonna be optional, there needs to be another feature.

  124. dwd

    qrpnxz, Ah, I see. So you want a client to go straight to SASL?

  125. Zash

    But how would you SASL without TLS?

  126. dwd

    qrpnxz, If so... advertise SASL.

  127. Zash

    And that's where in practice you'd do Dialback.

  128. qrpnxz

    Not personally, but i'm just saying that's what you'd have to do. You can't advertize SASL before TLS, and you have to advertise TLS

  129. dwd

    qrpnxz, And why do you think you can't advertise SASL alongside TLS?

  130. flow

    Why can't I advertize SASL before TLS?

  131. qrpnxz

    standard says so

  132. flow

    ref or it didn't say so ;)

  133. qrpnxz

    i will look :)

  134. flow

    we should take notes how different people interpret the standard text and see if we can clarify this in a future revision of the text

  135. qrpnxz

    you are right you can do them at the same time, thought if you didn't do SASL either then you'd need a dummy again

  136. dwd

    qrpnxz, So you want to not do SASL *or* Dialback *or* TLS? What is it that you *do* want to do?

  137. qrpnxz

    you are right you can do them at the same time, though if you didn't do SASL either then you'd need a dummy again

  138. dwd

    qrpnxz, And shouldn't you advertise *that*?

  139. qrpnxz

    I don't want to do anything like I said. Just commenting on the standard.

  140. Zash

    And then?

  141. qrpnxz

    one min

  142. qrpnxz

    and nothing

  143. Zash

    I'm lost.

  144. qrpnxz

    how can i help

  145. dwd

    qrpnxz, So you're saying that a thing you don't want to do can't be done? And this annoys you because?

  146. qrpnxz

    no, it can be done. Just you have to use a dummy maybe.

  147. qrpnxz

    the annoying part is that there's an unnecessary special case of tls being required if it's the only thing.

  148. qrpnxz

    whereas it could just be required if you put <required/>, which you must do if you consider it required anyway

  149. flow

    I think you maybe reading to much into "TLS required" in the standards text

  150. flow

    it basically says that an implementation can only claim standards compliance if it implements TLS

  151. flow

    not that you have to jump through loops in the protocol, not offering TLS is perfectly fine from a protocol perspective

  152. qrpnxz

    it says a lot of things

  153. dwd

    qrpnxz, OK. So you want the client to negotiate something which is unadvertised?

  154. qrpnxz


  155. dwd

    qrpnxz, So what do you want the client to do?

  156. qrpnxz

    > not offering TLS is perfectly fine from a protocol perspective no, std requires you offer tls

  157. qrpnxz

    i don't want the client to do anything dwd

  158. dwd

    qrpnxz, Then what on earth is the problem?

  159. qrpnxz

    i've already said to you multiple times idk what you want from me

  160. dwd

    qrpnxz, Give me an example of the thing you don't want to do but think is impossible.

  161. qrpnxz

    i already told you multiple times there is no impossible thing

  162. dwd

    qrpnxz, So why do you thinka dummy feature is needed?

  163. flow

    maybe slow down a bit and see if we can steer this into a productive and helpful direction

  164. qrpnxz

    i will tell you one more time: because if it's by itself and it doesn't say required it is still required, if you want to make it not required and there's no other legitimate feature, you must have a dummy feature

  165. dwd

    qrpnxz, OK. And what would the client do at this point?

  166. qrpnxz

    if it were optional? idk, w/e the client wanna do, or negotiate a mandatory feature.

  167. flow

    that would be SASL or dialback at this point, right?

  168. qrpnxz

    sure, if that were a feature

  169. flow

    so why not, instead of a dummy feature, announce SASL and/or dialback?

  170. dwd

    qrpnxz, OK, so there'd be another, non-dummy, feature for it to negotiate then. Where does the dummy feature come in?

  171. qrpnxz

    yes we already established this is also an option. That's why i said "if there's no other legitimate feature"

  172. qrpnxz

    yes we already established this is also an option. That's why i said *"if there's no other legitimate feature"*

  173. flow

    ok, we are going circles :)

  174. qrpnxz

    If there is another feature, then TLS feature comes back to the world of mortals and behaves normally. Only if it would otherwise be the only feature, do you need a dummy to make it optional.

  175. qrpnxz

    If there is another feature, then TLS feature comes back to the world of mortals and behaves normally. Only if it would otherwise be the only feature, then you need a dummy to make it optional.

  176. dwd

    Why would it be the only feature?

  177. dwd

    Because if you want the client to do "something else", then the server needs to advertise the feature is available at that point.

  178. qrpnxz

    it's almost always the only feature. I don't know all the XEPs though.

  179. qrpnxz

    the dummy is not for when you want to do something else, it's for when you want to do nothing.

  180. MattJ

    If you want to do nothing the stream can't proceed, that's the point

  181. qrpnxz

    it can if it's optional

  182. MattJ

    It can't, there's nothing else to do

  183. qrpnxz

    there is, if they are optional it's stanza time

  184. dwd

    MattJ, Maybe it's the equivalent of just holding hands.

  185. MattJ

    It's not stanza time until it's authenticated, which requires SASL

  186. MattJ

    (let's put dialback aside...)

  187. qrpnxz

    sasl is not required afaict

  188. MattJ

    You can't send stanzas without authentication

  189. qrpnxz

    but if it is then you put sasl next to tls, which like i said, is ofc not a situation in which you need the dummy

  190. dwd

    qrpnxz, RFC 6120 says SASL is both required and mandatory-to-negotiate.

  191. qrpnxz

    required to support, and mandatory-to-negotiate when advertized

  192. Zash

    It is a bit awkward that there's no explicit "you're done, feel free to send stanzas now"

  193. Zash

    Also awkward that an empty `<stream:features/>` means exactly that...

  194. dwd

    Zash, Well, for C2S you could advertise <bind/>.

  195. qrpnxz

    if all features are optional and there's nothing you want to negotiate, you just go ahead. I think it's for the best. Saves a message

  196. Zash

    dwd, thought we were mostly discussing s2s

  197. Zash

    but yeah

  198. dwd

    But there *is* XEP-0361 for the oddball cases where you need that.

  199. qrpnxz


  200. qrpnxz

    it's def expensive to start xmpp conn with all those stream restarts and feature lists

  201. qrpnxz

    for contrained environments. Desktops no problem ofc

  202. flow

    that negotiation ping-pong is also old-fashioned when it comes to protocol design. these days you want to just send all the stuff you want to do in a single step, e.g. bind2

  203. flow

    but I guess the negotation ping-pong is less of an issue in s2s

  204. Kev

    Depends on the environment. But yes, generally.

  205. qrpnxz

    On a related note, I may have found a problem in XEP-0288. XMPP: Core states: ``` A <features/> element that contains both mandatory-to-negotiate and voluntary-to-negotiate features indicates that the negotiation is not complete but that the initiating entity MAY complete the voluntary- to-negotiate feature(s) before it attempts to negotiate the mandatory-to-negotiate feature(s). ``` However, XEP-0288 states: ``` If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). [...] If the initiating entity chooses to use TLS, STARTTLS negotiation MUST be completed before enabling bidirectionality. ``` Now consider I serve the following: ``` <stream:features> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> <required/> </starttls> <bidi xmlns='urn:xmpp:features:bidi'/> </stream:features> ``` Core says that I MAY negotiate bidi first, but 0288 says that I MUST do STARTTLS first. 0288 should allow you to enable bidi before TLS to defuse this situation. I can't think of why that should be disallowed.

  206. Kev

    Central to a lot of how XEPs work is that any behaviour can be overriden by negotiation.

  207. Kev

    Central to a lot of how XEPs work is that any behaviour can be overridden by negotiation.

  208. Kev

    So if core says something and 288 says “But when doing 288 you should do this instead”, that is fine.

  209. Kev

    E.g. core says “There’s just <message/> <presence/> and <iq/>” and 198 says “but if you’re doing 198 there’s <a/> and <r/> too”, and that’s fine.

  210. dwd

    What Kev says, but also bidi is predicated on mutual authentication, so it'd be a bit weird to negotiate that before you decide if the other side is who it says it is.

  211. qrpnxz

    I see yeah cool np

  212. dwd

    But maybe weird is OK.

  213. qrpnxz

    i don't see how bidi is predicated on authentication, it just means says "dont' bother with another conn"

  214. qrpnxz

    in fact, it's perfectly ok to do bidi but not TLS in the XEP

  215. dwd

    Sending stanzas in general is predicated on mutual authentication. Even XEP-0361 uses out of band authentication.

  216. Kev

    And if you do TLS, pre-TLS state is tainted.

  217. Kev

    So you couldn’t negotiate bidi before doing TLS and continue using it afterwards.

  218. dwd

    Kev, That's a good point.

  219. qrpnxz

    i don't see such predicate in 0361, it merely recommends it

  220. Kev

    361 definitely only works bilaterally :)

  221. qrpnxz

    oh i think ik what you are talking about kev, gonna look up the quote in the std

  222. qrpnxz

    here: ``` The initiating entity MUST discard any information transmitted in layers above TCP that it obtained from the receiving entity in an insecure manner before TLS took effect (e.g., the receiving entity's 'from' address or the stream ID and stream features received from the receiving entity). ```

  223. qrpnxz

    bidi would be such an information

  224. qrpnxz

    therefore if you do bidi first, no more tls

  225. Zash

    You'd get another set of stream features after TLS and the stream restart

  226. qrpnxz

    and contraversly, if you do tls, it must be first

  227. qrpnxz


  228. qrpnxz

    *contrapositively lol

  229. dwd

    However, you may have a point - it's useful for the receiving entity to know if bidi is intended as early as possible, ebcause otherwise it'll start to open connections. (Or might do; Metre certainly will).

  230. Zash

    I think in Prosody bidi is not even advertised until after TLS and certificates have been verified and such

  231. qrpnxz

    0288 doesn't require it do advertise before tls, only recommends it

  232. Kev

    dwd: But if you’re making such decisions, they have to be reversible, right?

  233. Kev

    Because the bidi before TLS is tainted.

  234. dwd

    Kev, Yes, but you could at least hold off on opening return sessions.

  235. Kev

    Although I’m not sure what decision you’d make based on an *outbound* session having bidi advertised.

  236. qrpnxz

    but you really gotta do it before sasl, because after sasl it's assumed you aren't gonna send anything else on that conn

  237. Kev

    As on an outgoing session it’s the other end that can elide the second stream because of bidi, not you.

  238. Zash

    What's all this about opening return sessions early?

  239. Zash

    That sounds like a Dialback thing

  240. qrpnxz

    uhh, not sure

  241. dwd

    Zash, It's a non-bidi-thing.

  242. Zash

    Hm, without dialback, something to verify that bidirectional connectivity is possible would be good...

  243. qrpnxz

    that's what XEP-0288 does

  244. Zash

    One-way s2s is a bit annoying when it happens

  245. dwd

    Kev, Yes. So, you're a server. You get an inbound session claiming to be from example.org. You're advertising bidi. Until the inbound session has negotiated bidi, then you can save some time by initiating an outbound session to example,org. This is safe (in terms of auth, etc) even if the inbound session cannot authenticate.

  246. Zash

    XEP-0288 isn't all that widely deployed

  247. dwd

    Kev, But, if the inbound session then negotiates bidi, it was a waste of effort.

  248. qrpnxz

    no way i personally waste time on outbound connection before auth, and bidi has to happen before auth, so problem solved for me lol

  249. Kev

    dwd: Yes, but I don’t know what advertising bidi does here. Because it’s you that’s advertising it on the inbound session, so you don’t know if the other end is going to use it later to determine whether to open the return session or not.

  250. dwd

    Kev, Right, because we don't negotiate until later. If, as qrpnxz says, we negotiate early, then this changes.

  251. dwd

    Kev, Even if we'd *later* have to renegotiate...

  252. dwd

    qrpnxz, It's very rarely a waste of time, and often makes things significantly faster to get to stanza exchange.

  253. qrpnxz

    if you advertise bidi with tls, you can do bidi and no tls (unless TLS is required, then you must do TLS first). If you advertise bidi with SASL, then you can enable bidi, and after SASL you will have a bidi connection. Or if you don't enable it and then do SASL, then it's one way

  254. qrpnxz

    dwd, yeah it's a tradeoff of waste of resources on non-auth and time save for successful auth. I choose not letting people waste my time without auth every time tho

  255. moparisthebest

    .onion domains are a widely deployed reason to still support dialback I think

  256. MattJ

    Prosody's mod_onions just accepts any *.onion certificate

  257. qrpnxz

    onion does touch dns though, and i cant think of you you wouldmt trust that conn

  258. qrpnxz


  259. qrpnxz

    jesus i rly messed up that msg

  260. qrpnxz

    h8 typing on phone

  261. qrpnxz

    ok on computer now. Onion addr is based on pub key crypto iirc, so if you connected to it, I think you are fine, but not sure tbh will have to look into it.

  262. qrpnxz

    rly need to go to bed rn tho

  263. moparisthebest

    qrpnxz, right, but then how do you validate the connection coming *from* something claiming to be a .onion ?

  264. moparisthebest

    MattJ, wait for incoming SASL auth too? or how do you validate incoming .onion streams ?

  265. Zash

    It accepts any certificate, in that it doesn't reject them. But it doesn't use certs for authentication either. Still need to do Dialback.

  266. moparisthebest

    ah ok, good

  267. moparisthebest

    I suppose the dreaded "raw IP" requires dialback too

  268. Zash

    You can get certs for IP addresses actually...

  269. Zash

    Prosody can't federate with bare IPs tho, so glhf

  270. Zash

    (depending on version and whether it's the future yet)

  271. Kev

    It wasn’t then, but it is now.

  272. Zash

    IP address SAN is newer than XMPP?

  273. dwd

    The SAN existed, it's part of X.509v3, IIRC. But whether any CA would sign such a cert is another matter.

  274. Zash

    Will any now?

  275. Zash has one

  276. dwd

    I have this vision of you deciding to work through all the IP addresses and being lucky the first one hit.

  277. eta

    please federate with 2a0d:1a40:7553:beef:5054:ff:fe62:dd16, kthxbai

  278. Zash

    Next up, can haz raw public keys?

  279. Zash

    Raw all the things

  280. Zash

    And like ... in-addr.arpa DANE something something

  281. dwd

    I'd never suggest "raw public keys", because the logistics are a pain, but Metre does allow preconfigured self-signed certs.

  282. eta

    also see https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/JFwqZx7RLL0

  283. Zash

    DANE + raw public keys would be nice tho

  284. Chan Shen

    is it possible to add voice chat to xmpp ??

  285. Zash

    Yes, commonly called Jingle

  286. Zash

    https://xmpp.org/uses/webrtc.html might be enlightening

  287. Zash

    or https://xmpp.org/about/technology-overview.html#jingle

  288. Zash

    or both

  289. Chan Shen

    >Yes, commonly called Jingle is it something like group chat of telegram ??

  290. Chan Shen

    >Yes, commonly called Jingle is it something like group voice chat of telegram ??

  291. Zash

    Never used Telegram, can't answer that.

  292. Chan Shen

    >Never used Telegram, can't answer that. i mean is it possible to have a voice chat (up to 100 person) with group members in xmpp ?

  293. Zash

    Daniel, distinct lack of mention of calls on https://conversations.im/ 🙂

  294. Zash

    Mostly 1-to-1 calls at this time, altho things like Jitsi Meet does video conferencing with some XMPP behind the scenes.

  295. Chan Shen

    i think it is called multiparty jingle (muji). https://xmpp.org/extensions/xep-0272.html

  296. jonas’

    https://github.com/xsf/xeps/pull/1059 flow, don’t you think this has privacy implications?

  297. flow

    jonas’, well yes, I still would recommend that. that said, if someoe would write a disclaimer, then this would be fine by me

  298. dwd

    Chan Shen, Unfortunately the Jitsi Meet people haven't put their solution through standardisation, which is a shame. I should have a chat with Emil and co about that. But there are a number of solutions for video conferencing based on XMPP as the signalling layer, including Jitsi Meet, and also Zoom and possibly still Google Meet.

  299. Chan Shen

    > dwd wrote: > Chan Shen, Unfortunately the Jitsi Meet people haven't put their solution through standardisation, which is a shame. I should have a chat with Emil and co about that. But there are a number of solutions for video conferencing based on XMPP as the signalling layer, including Jitsi Meet, and also Zoom and possibly still Google Meet. Jitsi is the best choice for me right now , i dont like Telegram nor Google Meet.

  300. dwd

    Chan Shen, There is also Openfire Meetings and Padmé as well, on the open source front, but I don't know how well those scale.

  301. dwd

    Chan Shen, You did stipulate voice only - most recent work has been around video, which may or may not mean some interesting large-scale voice stuff has gone unnoticed by me.

  302. Zash

    Does anyone know any details about how Mumble works?

  303. moparisthebest

    also https://bigbluebutton.org/ which I don't think is XMPP but at least open source and supposedly works pretty well

  304. dwd

    Zash, Oh, yeah, Mumble.

  305. jonas’

    Zash, barely

  306. dwd

    Zash, Voice go in one end. Voice come out the other.

  307. jonas’

    with mixing on the server

  308. jonas’

    I think anyway

  309. Chan Shen

    I just dont like facebook , whatsapp , telegram. I tried to invite my friends to xmpp & matrix , but they say telegram is 100% secure and its features are not implemented in other IM apps.

  310. emus

    Hello everyone, as I just wrote an email to members@ - I would also point you from here to the work I am doing here: https://github.com/xsf/xmpp.org/issues/920 It is an overview of the XSF, its organization and resources, as a organizational chart or organigram. I am convinced this can be a really helpful tool for overview purposes, especially to newcomers or people who are interested in the XSF and XMPP. Let me know you feedback and if you think something is missing! @board, @council (just imaging I ping you guys 😛)

  311. wgreenhouse

    what is the software behind logs.xmpp.org?

  312. menel

    I think this: https://modules.prosody.im/mod_http_muc_log.html

  313. wgreenhouse

    menel: looks like it, thank you