XMPP Council - 2019-03-13

  1. Kev

    Do we have an agenda for today?

  2. Link Mauve


  3. moparisthebest

    There are pending protoxeps but maybe too late

  4. Kev

    If those didn't make it onto an agenda, I guess next week for them.

  5. Link Mauve

    Yes, we do have https://github.com/xsf/xeps/pull/765

  6. zinid

    just in case you also have: https://xmpp.org/extensions/inbox/eax-cir.html

  7. dwd

    Yeah, no agenda, sorry - things are a bit mad for me at work currently.

  8. Kev

    I've been completely swamped for the last few weeks.

  9. Kev

    I have at least got out votes for the meeting two weeks ago just before they expire.

  10. jonas’

    it is reassuring that we’re all being swamped at the same time at least

  11. jonas’

    hasn’t been much better for me either, as you can probably guess by the editor latencies

  12. zinid

    the council is swamped, okay

  13. Link Mauve

    I’ve also been both swamped, and got my main laptop stolen. :x

  14. Kev

    Oh, that's sucky.

  15. Link Mauve

    I do have backups, but I need to get a new one asap.

  16. Link Mauve

    And also a new passport.

  17. jonas’

    Link Mauve, ouchie

  18. dwd

    Oh, that does suck, indeed.

  19. dwd

    So, anyway:

  20. dwd

    1) Roll Call

  21. Kev


  22. dwd

    Link Mauve and jonas’ I assume are here - Ge0rG?

  23. jonas’

    I am

  24. dwd

    Well, we'll move on.

  25. dwd

    2) Agenda Bashing

  26. dwd

    I see two ProtoXEPs, and nothing else.

  27. jonas’

    I haven’t checked the editor inbox in the last 7 days, unfortunately.

  28. jonas’


  29. dwd

    I'm perfectly happy to get the two ProtoXEPs onto this meeting's agenda so we can at least hope to get them through quickly, even if many of us are on-list.

  30. jonas’

    I agree with that

  31. Kev

    I think everyone onlisting is something to be avoided, and we should be aiming not to add things to the agenda during the meeting. But, majority rule.

  32. dwd

    Oh, and Jingle Message Initiation has been requested to move to Draft.

  33. Link Mauve

    So a last call?

  34. dwd

    Kev, yes, but all these things have been posted to the standards@ list, so it's entirely our fault.

  35. jonas’

    Kev, we could discuss this particular point in AOB, I have opinions on that.

  36. jonas’

    dwd, they have been posted last night though, I can see his point ;-)

  37. Kev

    dwd: I used to monitor the calls, but since we get agendas in advance, these days I just wait for the agendas to come in.

  38. dwd

    3) Items for a vote

  39. dwd

    Kev, I find your faith in me worrying.

  40. dwd

    a) E2E Authentication in XMPP: Certificate Issuance and Revocation

  41. dwd


  42. Kev

    Well, if we rely on everyone working out what the agenda will be, there's little point sending out agendas :)

  43. Kev


  44. jonas’

    on-list, obviously

  45. Link Mauve

    On-list too.

  46. dwd

    I think I'm tentatively +1. Seems in-scope.

  47. jonas’


  48. jonas’


  49. jonas’

    (that’s for the anticipated (b))

  50. dwd


  51. dwd


  52. jonas’

    I was just reading XEP-0001 regarding the next one

  53. dwd

    b) DNS Queries over XMPP (DoX)

  54. dwd


  55. Kev

    This was an 1stApril wasn't it?

  56. jonas’

    this should’ve been on the humorous track

  57. jonas’

    and not ever reached council

  58. jonas’

    according to '0001

  59. jonas’

    I’m getting a call

  60. Kev

    They're not meant to reach us, indeed.

  61. dwd

    I genuinely do not know if this one is April 1 or not. But yes, I agree it's out of our scope.

  62. dwd

    jonas’, People call you about these things now? :-)

  63. Link Mauve

    There have been people voicing concern that this isn’t any more humorous than the HTTP version.

  64. Link Mauve

    And could even be more useful.

  65. dwd

    jonas’, If it *is* intended to be a joke - and I thought DoH was originally - then it's of the wrong Type.

  66. jonas’

    dwd, yes

  67. jonas’

    it is

  68. jonas’

    > I would humbly suggest this might be accepted as a XEP on the first of next month, if council approves. ;) from https://github.com/xsf/xeps/pull/765

  69. jonas’

    I messed that one up

  70. dwd


  71. dwd

    No worries. We'll skip that then.

  72. jonas’

    spoiling the fun though

  73. jonas’

    to the minute-taker, please omit the discussion about (b) :)

  74. Kev

    Let's ...

  75. Kev

    right, that.

  76. moparisthebest

    personally, I'd prefer it not be humorous track, but also released april 1st :)

  77. moparisthebest

    don't know who ends up making that decision, just that it's not me

  78. jonas’

    moparisthebest, in the end, it’s you

  79. dwd

    c) XEP-0353: Jingle Message Initiation

  80. Link Mauve

    You as the author makes the decision on which track to go through.

  81. jonas’

    if you say you actually want this on Standards Track and not Humorous...

  82. moparisthebest

    it's no more or less serious than DoH, which is a real RFC :)

  83. dwd

    Oh, wait, are we going to consider this one properly then?

  84. jonas’

    I’m afraid so

  85. dwd

    Oh. So I'll +1 DoX if you want it on Standards Track, but I'm going to be leaning on you very heavily to get some Security Considerations in place about privacy.

  86. Kev

    I'll on-list it, but I'm very much opposed to publishing on April 1st if it's not meant to be humorous.

  87. moparisthebest

    I *mostly* copied them directly from Security Considerations on the DoH RFC, but yes I agree privacy stuff should be added

  88. dwd

    Kev, You can engineer that, of course...

  89. dwd

    OK, jonas’, Link Mauve - since we're actually voting, are you two also going on-list?

  90. Link Mauve

    Yes, I will be.

  91. Link Mauve

    Leaning towards +1 because it’s a valid usecase and seems properly written.

  92. dwd


  93. dwd

    I'll assume he's trapped on the phone and will on-list.

  94. dwd

    So back to:

  95. dwd

    c) XEP-0353: Jingle Message Initiation

  96. dwd

    Andrew asked for this to be advanced to Draft, so we'd need to vote for Last Call.

  97. Link Mauve

    Is there any author available to issue the last call?

  98. Link Mauve

    Or is Andrew becoming the shepard?

  99. dwd

    Link Mauve, Good point.

  100. Kev

    Previously, we could have just done this if we wanted.

  101. Link Mauve

    Or is Andrew becoming the shepherd?

  102. Kev

    Now we're only allowed to if we determine it's abandoned.

  103. jonas’

    dwd, sorry, I’m on call and got a page, that’s what I meant to say earlier

  104. jonas’

    I’m on-list, defaulting to -1 otherwise.

  105. jonas’

    regarding (b)

  106. jonas’

    regarding (c), nothing wrong with LC I think

  107. Kev

    (For those not following, a recent change was made by Board to XEP1 to change it from Council being allowed to issue an LC whenever it wanted, irrespective of who asked, to only being able to issue one if an author asks, unless the authors have abandoned the XEP)

  108. dwd

    I'll follow-up with Andrew to see if he's willing to gether and process feedback, then.

  109. Kev

    So I think we're obliged to contact Peter and Philip and ask if they've abandoned it.

  110. Kev

    So I think we're obliged to contact Peter and Philipp and ask if they've abandoned it.

  111. dwd

    I'll do so.

  112. Kev


  113. dwd

    4) AOB

  114. dwd

    I know jonas’ had some aboutt agendums, but I assume that can wait and/or be discussed on the Council list.

  115. dwd

    Anyone else?

  116. Kev


  117. dwd

    5) Next Meeting

  118. Link Mauve


  119. dwd

    Same time next week?

  120. dwd

    That's Wednesday 20th March, 1600 UTC.

  121. dwd

    6) Ite, Meeting Est

  122. dwd

    Thanks all.

  123. Kev

    I don't currently have anything stopping me, but the way things have been recently... yeah.

  124. dwd

    Kev, I know that feeling and truly sympathize.

  125. moparisthebest

    Kev, so it's as-useful as DoH but with better performance (less RTTs), and has implementations that work, which is why I want Standards Track, but also like DoH it's a flagrant layer violation so I just thought it'd be funny to release on April 1st and have people forever more wondering "wait, is this a joke or not?"

  126. moparisthebest

    but I can have an odd sense of humor, I'm not married to the idea :P

  127. jonas’

    people wondering about a spec being a joke or not is generally not good for UX

  128. moparisthebest

    jonas’, curious as to the default to -1, but if you are going to bring it up on list I can wait to discuss there too

  129. jonas’

    moparisthebest, I don’t think either of DoH or DoX is a good idea

  130. jonas’

    but I’m going to read the rationale and be convinced otherwise

  131. moparisthebest

    well I can tell you right now if you don't like DoH you won't like DoX, they are for all intents and purposes identical

  132. zinid

    what purpose? browsers need this hack because they need to resolve, and an XMPP client doesn't need to resolve anything

  133. zinid

    not sure if trolling...

  134. moparisthebest

    if anything an XMPP client needs to resolve much more? don't some resolvers still break on SRV etc

  135. zinid

    it needs to resolve that to open the stream

  136. Zash

    HTTP upload eg

  137. moparisthebest

    not if it's hard-coded, like any DNS resolver will have to be

  138. jonas’

    moparisthebest, you don’t need to hard code DNS resolvers

  139. jonas’

    you learn them via DHCP or system configuration

  140. zinid

    Zash, isn't what an HTTP library should do?

  141. moparisthebest

    and those are the ones that don't do SRV properly, or mangle responses etc, read DNS-over-TLS and DoH spec for all those reasons

  142. moparisthebest

    that's just not true anymore jonas’ , android 9 hardcodes a DNS-over-TLS by default now, browsers hard-code DoH addresses etc

  143. zinid

    and we need that insanity in XMPP too?

  144. jonas’

    moparisthebest, yes, because they suck

  145. moparisthebest

    of course, we are forever trying to catch up to HTTP browser levels of insanity

  146. zinid

    so far that's not we but you 🙂

  147. moparisthebest

    so, you are a XMPP client, you ask your resolver for SRV records, it returns an error, then what?

  148. moparisthebest

    it could fall back to connecting to a known/public "resolver xmpp account" and resolving that way

  149. zinid

    you try A record?

  150. moparisthebest

    ok so if that fails then

  151. moparisthebest

    that's one perfectly valid usecase, another is your router staying connected via XMPP and resolving DNS for your network

  152. zinid

    valid use case in what situation?

  153. moparisthebest

    my router currently resolves DNS over DNS-over-TLS and DNS-over-HTTPS, both over tor, and the constant TLS setup/teardown adds quite a bit of overhead that wouldn't exist with DoX

  154. zinid

    when resolver doesn't work, but internet does?

  155. moparisthebest

    that's 2 usecases I can think up right now

  156. Kev

    1.3 to the rescue?

  157. moparisthebest

    zinid, yep, that happens often

  158. zinid

    moparisthebest, I don't think often enough to address the problem using stupid hacks

  159. moparisthebest

    wasn't Ge0rG just complaining the other day that a large % of clients couldn't resolve SRV records?

  160. zinid

    I don't like this attitude to degrade the tech because of amateur developers

  161. zinid

    it's not how the industry is progressing

  162. moparisthebest

    where do amateur developers come in?

  163. zinid

    you cannot degrade medicine or particle physics

  164. zinid

    to fit idiots in there

  165. moparisthebest

    the SRV record thing is bad dns resolvers that haven't been upgraded in 20 years

  166. moparisthebest

    and/or bad ISPs or countries that block them

  167. Zash

    and the web doesn't use SRV, so who cares

  168. zinid

    use A records?

  169. moparisthebest


  170. zinid

    still better than DoXYZ

  171. moparisthebest

    zinid, port 5222 is blocked too

  172. zinid

    and how DoX will help with blocked ports?

  173. moparisthebest

    maybe we should just make XMPP connect to port 443 on the A record via TLS as a fallback :)

  174. zinid

    use 443, we already have this insanity

  175. moparisthebest

    because DoX gets you the SRV records that can point to alternate ports?

  176. zinid

    and then they will block your ALPN?

  177. zinid

    what will do next?

  178. zinid

    looks like an arm race

  179. moparisthebest

    well, we have encrypted SNI now, so encrypt ALPN using the same setup? :P

  180. moparisthebest

    it's absolutely an arms race

  181. zinid

    but why would we need to accept the race? what's the point?

  182. moparisthebest

    end goal being have everything encrypted and unblockable

  183. moparisthebest

    then $they find new ways to block, and $we find new ways around those, forever

  184. zinid

    which means everything is resolved via a single using TLS on 443?

  185. zinid

    that's what we're going to do

  186. moparisthebest

    yea, that's already the case basically

  187. dwd

    FWIW, I do think DoX is insane, but so is DoH. Question for me is whether DoX is better being redirected to IETF, thinking about it, if i's a serious proposal.

  188. zinid

    I disagree of course, it's not the case

  189. moparisthebest

    at least things brings in the possibility for more diversity in resolvers

  190. zinid

    moparisthebest, there will no be diversity, there will be TLS on 443

  191. moparisthebest

    zinid, it is the case, android 9 ships by default with all DNS going to google over TLS

  192. zinid


  193. moparisthebest

    browsers already ship with DoH capability

  194. zinid

    so why we need DoX?

  195. moparisthebest

    only a short matter of time before they turn on by default

  196. moparisthebest

    dwd, I agree with you, DoX is equal in it's insanity to DoH, no more, no less :)

  197. moparisthebest

    both have use cases, both a bit crazy, but use cases nonetheless

  198. dwd

    moparisthebest, The main use case being having someone like Google get all your DNS lookup data.

  199. zinid

    yeah, I personally don't care whether it will be Google or moparisthebest.com, both are crap

  200. moparisthebest

    run your own?

  201. zinid

    we should not move that road

  202. jonas’

    moparisthebest, I already run my own. On port 53.

  203. zinid

    moparisthebest, why? I have everything working

  204. moparisthebest

    and every *other* network you go on intercepts that and sends you whatever it feels like jonas’

  205. jonas’

    moparisthebest, so? I have dnssec for that.

  206. zinid

    and I don't want to run my own, that's also insane

  207. jonas’

    it can’t, too, because my resolver runs on

  208. moparisthebest

    oh so then they just DOS you?

  209. jonas’

    I wanna see them intercept /that/

  210. moparisthebest

    DNSSEC solves a different set of problems

  211. jonas’

    they can DOS me already if they block TCP or UDP or whatever

  212. moparisthebest

    privacy etc for instance is not addressed by DNSSEC

  213. jonas’


  214. jonas’

    I can personally live with that. and if others can’t, we should solve this in DNS, not by stacking layers over layers for no good reason.

  215. moparisthebest

    take it up with the IETF, they decided it was a great idea

  216. Kev

    Surely DoX should be using DoH at the other end anyway, because the resolver the DoX box is using might have SRV blocked?

  217. jonas’

    moparisthebest, some people under the umbrella of the IETF thought htat

  218. jonas’

    that’s a difference.

  219. moparisthebest

    it's probably too late though, since most devices will be using it soon enough

  220. jonas’

    maybe I should switch trades and learn something which isn’t being botched awfully

  221. zinid

    jonas’, for example what? 🙂

  222. moparisthebest

    ha I've often thought about that :P

  223. jonas’

    zinid, I don’t know

  224. zinid

    I think every other industry is polluted by this shit

  225. jonas’

    anything which has settled more than IT has

  226. zinid

    maybe academics, but it's totally biased, full of ad hominem and groupthinking

  227. Zash

    Every other industry isn't 50 years old

  228. jonas’

    isn’t *just*

  229. moparisthebest

    sustenance farming

  230. Zash

    Potato farming, in the woods?

  231. moparisthebest


  232. moparisthebest

    Kev, the resolver I'm running currently upstreams to random DNS-over-TLS servers, but someone is writing a prosody module now to go dox -> doh >:)

  233. zinid

    jonas’, probably to switch the IT niche, but it will be very marginal, if you try to up your head a bit you get it into Google shit 🙁

  234. jonas’

    yeah, layer 1 through 3 are nice

  235. moparisthebest

    jonas’, let me tell you about QUIC

  236. zinid

    oh yes, QUIC...

  237. jonas’

    moparisthebest, that’s above layer 3

  238. Zash

    A dream of SCTP :(

  239. zinid

    suddenly they found out that it takes time to adopt SCTP, so let's do everything at layer3 !!!

  240. zinid


  241. jonas’

    layer 3 isn’t going to change anymore, look at how long it takes to deploy v6 ;-)

  242. jonas’


  243. jonas’

    I’ll just leave now, this isn’t good for my mental health

  244. zinid

    application layer

  245. jonas’

    application is 7 or something

  246. jonas’

    don’t scare me like that, zinid

  247. zinid

    in OSI?

  248. jonas’


  249. zinid


  250. jonas’

    3 is IP

  251. zinid

    yeah, probably

  252. jonas’

    don’t scare me like that

  253. jonas’

    I treasure layer 3 as my refuge where I go when I feel sad.

  254. moparisthebest

    but uh, many (most?) middle boxes block any IP that isn't UDP or TCP so....

  255. jonas’

    moparisthebest, that’s layer 4

  256. jonas’

    UDP and TCP aren’t IPs

  257. moparisthebest

    which is why QUIC is over UDP, not IP

  258. jonas’

    QUIC is over UDP is over IP

  259. Zash

    A dream of IPSec, but we got TLS instead :(

  260. moparisthebest

    tl;dr layers don't matter anymore, forget everything you knew about them

  261. jonas’

    Zash, IPsec is a horrible mess though

  262. jonas’

    moparisthebest, they do matter, up to and including 3

  263. jonas’

    which is why I say 1-3 are sane, everything above is madness

  264. Zash

    jonas’: And TLS ain't?

  265. jonas’

    Zash, point taken

  266. moparisthebest

    you can't do anything with IP though, other than UDP or TCP is what I mean jonas’

  267. Zash

    TLS seems to have taken on the role of IPSec

  268. jonas’

    moparisthebest, working on the infrasturcture which allows UDP and TCP to flow is fun enough and enough "doing something with it"

  269. zinid

    jonas’, I'm told OSI is a horrible mess, but I don't think it was that bad, in comparison with what we ended up

  270. zinid

    where we don't have layers anymore

  271. zinid

    total leak of abstractions from layers to layers back and forth

  272. moparisthebest

    anyone complain about that with that XMPP SASL thing that needs TLS info? :P

  273. zinid

    sure, I complained

  274. zinid

    I can find the complaint in the ML if you like

  275. moparisthebest

    basically, layer violations are bad unless they give you something good and then they are good

  276. zinid

    ah, those good intentions

  277. zinid

    I bet DoH people had good intentions

  278. zinid

    or maybe it was just Google assasins?

  279. zinid

    anyway, the major threat will be of course CDNs, not DoH or DoX will help you because you won't be able to do peer-to-peer connections anymore

  280. zinid

    probably even ICMP will be blocked, lmao

  281. moparisthebest

    ICMP is already mostly blocked

  282. moparisthebest

    but what's blocking peer-to-peer connections?

  283. zinid

    well I mean there will be no route to host

  284. moparisthebest

    other than, lack of ipv6 deployment

  285. zinid

    moparisthebest, routers are being replaced by CDNs, google builds farms of CDNs connected via private channels, and ISPs almost don't invest into cables anymore

  286. jonas’

    moparisthebest, IPv6 deployment requires ICMP6, for path MTU discovery.

  287. moparisthebest

    lots of networks block it though, and it seems to work... but I know what you mean

  288. zinid

    so *I* think the future of the internet is your "last mile" ISP connected to a CDN

  289. zinid

    so yeah, the industry is fucked up

  290. moparisthebest

    I really don't know what you mean by CDNs replacing routers though

  291. Zash

    Like Google Global Cacehe?

  292. moparisthebest

    there is a lot of effort towards meshnets too, bypassing all this "internet" crap :P

  293. zinid

    moparisthebest, how will you bypass the crap when your ISP is connected to google cdn directly and routes nothing?

  294. moparisthebest

    https://github.com/cjdelisle/cjdns / https://hyperboria.net/ seems interesting/promising

  295. zinid

    there will be no routers, ISP is a last mile for your phone

  296. zinid

    then goes Google with CDN

  297. moparisthebest

    are you saying it blocks everything but google? seems pretty far fetched, hopefully

  298. zinid


  299. zinid

    it doesn't block anything, there ARE NOT anything except Google CDN server

  300. zinid

    there is a nice research paper showing the situation

  301. jonas’

    I really should’ve left

  302. moparisthebest

    I can't quite imagine a dystopia where that happens yet

  303. zinid

    I thought the same, but now we have DoH 😀

  304. moparisthebest

    if anything that's anti-centralization, gives you a choice

  305. moparisthebest

    with dns-over-tcp/udp you only have 1 choice, because your router/isp hi-jacks it and returns whatever they want

  306. moparisthebest

    over TLS, you can connect wherever you choose

  307. moparisthebest

    that goes for DoT, DoH, and DoX

  308. zinid

    yeah, good luck trying to beat it with the technology 🙂

  309. moparisthebest

    it's all I have

  310. ralphm

    The problem with SCTP is mostly middleboxes.

  311. zinid

    given that ISP have no zero incentives to build new routes, because 80% is routed to FAANG, why care?

  312. moparisthebest

    few have the resources of google/amazon/apple/etc so all we have is tech to battle with

  313. zinid

    *have now

  314. zinid

    moparisthebest, especially when they now define tech

  315. ralphm

    I.e. you not only have to support at the edges, but on each possible route between endpoints

  316. zinid

    yeah, same problem as IPv6 basically

  317. moparisthebest

    that's why QUIC is over UDP instead of IP

  318. moparisthebest

    they've essentially said "fuck it, impossible" to making new IP-based protocols

  319. ralphm

    Even though I too have the same thing about crossing OSI layers, I appreciate the practical thinking here.

  320. zinid

    I'm not convinced it's practical, at least no urgency, so better to define a strategy on moving to SCTP

  321. zinid

    really, what urgency?

  322. zinid

    I don't buy efficiency, because the application layer protocols are already horribly inefficient

  323. moparisthebest

    there is the "ideal" way which most people generally agree on, but might be impossible to achieve practically

  324. moparisthebest

    then there is the "a bit crappy but works" way which can be used *now*

  325. moparisthebest

    balancing them is rough

  326. zinid

    *now* is a good argument in the case of IPv4, because the address space is over

  327. zinid

    but with TCP?

  328. zinid

    btw, just in case, you can incapsulate SCTP into UDP, there is even an RFC for this

  329. moparisthebest

    QUIC doesn't replace TCP, it replaces TCP+TLS

  330. moparisthebest

    I think the main benefits are reduced RTTs, and eliminating head-of-line blocking

  331. moparisthebest

    I'm sure there are more

  332. zinid

    yeah, reduce RTT in order to download bloated JS pages

  333. moparisthebest

    soon bloated WASM pages :D

  334. zinid


  335. moparisthebest

    gotta keep up

  336. ralphm

    moparisthebest: indeed, you can get to 0 round-trips for known endpoints.

  337. ralphm

    moparisthebest: another interesting one is that you can keep a connection even if your IP changes (e.g. when switching between cellular and wifi)

  338. moparisthebest

    ah right that's handy too

  339. ralphm

    There are also some benefits regarding how QUIC packets are encrypted and authenticated

  340. ralphm

    This is an interesting piece: https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00

  341. ralphm

    Although I'm sure it is not up-to-date with the latest, this gives some more details of why it trumps SCTP and/or TCP in various areas.

  342. moparisthebest

    so, XMPP-over-QUIC would mean you could do away with Stream Management I think?

  343. moparisthebest

    and XEP-0397: Instant Stream Resumption

  344. ralphm

    One other thing I found interesting is that, compared to Google QUIC, they tweaked IETF QUIC headers to allow for multiplexing with STUN/TURN/etc on the same port. https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-03

  345. ralphm

    moparisthebest: yes

  346. ralphm

    and starttls

  347. ralphm

    (as TLS 1.3 is baked into QUIC)

  348. moparisthebest

    incoming XEP-0368v2: SRV records for XMPP over QUIC

  349. moparisthebest


  350. ralphm

    I suppose you can just use _xmpp-client._udp for this

  351. zinid

    I'll probably off this boat

  352. ralphm

    zinid: at least read that comparison draft I linked. You might find it interesting to know why people have bothered with QUIC.

  353. zinid

    ralphm, I read it before obviously

  354. zinid

    and it mostly describes how cool QUIC is

  355. moparisthebest

    but, old google QUIC or new IETF QUIC because quite different

  356. zinid

    I have no incentive to implement QUIC, I have no practical problems with TCP, and note that I manage highload with millions of connections

  357. zinid

    I think this is related to Google grade clusters

  358. zinid

    and others just swallow it

  359. moparisthebest

    sure if you ignore all the *other* benefits I guess

  360. zinid

    RTT is not a problem for me at all

  361. moparisthebest

    it's certainly not about "handling more connections"

  362. zinid

    moparisthebest, I still think it's not a worth to ruin everything and rebuilding from scratch

  363. zinid

    and putting packets framing into user land

  364. ralphm

    zinid: I don't think it is ruining everything.

  365. zinid

    okay, but I do

  366. zinid

    so I said I'll implement this the latest

  367. zinid

    when customers and users will jump on my head

  368. moparisthebest

    things change, when TCP was invented, people switching IPs regularly mid-stream was not-a-thing, now *most* computers do this

  369. ralphm

    RTT is definitely an issue when you establish many connections and/or in non-reliable networks. The latter is especially true in mobile context.

  370. zinid

    moparisthebest, but this is solved by SCTP

  371. zinid

    so far the only somewhat valid arguments I hear is all SCTP can do as well

  372. ralphm

    If you work in an office, then take the elevator to the ground floor, stopping on a few floors, exit the building, how often do you think you switch networks?

  373. moparisthebest

    SCTP is impossible to get on the internet, it's over

  374. zinid

    moparisthebest, internet is over

  375. ralphm

    There's so much ossification in existing networks that deploying SCTP in a meaningful way is a non-starter. This is not fatalistic, just realistic.

  376. zinid

    ralphm, I switch the networks everytime, I don't feel discomfort, stream management works for me

  377. moparisthebest

    ok, now implement that for all other network connections

  378. moparisthebest

    or, just once, in QUIC

  379. ralphm

    It does, but there's latency involved due to roundtrips. With QUIC you might achieve 0 RTT to resume.

  380. zinid

    ralphm, what latency? 1 sec vs 0.1 sec?

  381. zinid

    I'm fine with that

  382. moparisthebest

    might be 30 seconds

  383. zinid

    and might be an hour, sure

  384. ralphm

    If someone writes a QUIC library, putting XMPP on top should not be hard

  385. moparisthebest

    but if you don't want change why are you using this new fancy XMPP stuff, SMTP works fine for messaging

  386. moparisthebest

    also manage your servers via telnet

  387. ralphm

    zinid: well, I looked at networks in developing nations, and things aren't that bright.

  388. zinid

    okay, so why we cannot incapsulate SCTP into UDP once again?

  389. zinid

    there is an RFC

  390. moparisthebest

    look at you trying to re-invent QUIC here

  391. moparisthebest


  392. ralphm

    Why would that be better than QUIC, which actually has a lot traction?

  393. zinid

    moparisthebest, but that RFC was before QUIC, so who is reinventing?

  394. ralphm

    But is it better?

  395. zinid

    depends on what is better and for whom?

  396. ralphm

    For getting to a place where people can benefit from its properties. Not just theoretically, but in practice.

  397. zinid

    I see 😀

  398. moparisthebest

    plus it doesn't bundle TLS which is a huge benefit, for RTTs and other things

  399. zinid

    moparisthebest, regarding telnet and smtp: why aren't you going to matrix?

  400. ralphm

    I'm happy for Matrix to exist. They have different ideas. We'll see how that works out.

  401. moparisthebest

    I like XMPP better so far

  402. moparisthebest

    seems good enough at adapting to new tech too

  403. ralphm

    moparisthebest: I hear that often around these parts 🤣

  404. zinid

    moparisthebest, yeah good answer 🙂

  405. zinid

    so I said like 100 posts above I like TCP so far 🙂

  406. ralphm

    zinid: good, but that doesn't mean QUIC is useless, does it?

  407. zinid

    ralphm, obviously anything is useful for something

  408. moparisthebest

    I guess that's even one of the great advantages zinid , when my clients are all connected to my server over QUIC and you are connected via TCP, we'll still be able to talk :D

  409. zinid

    for someone

  410. moparisthebest

    <3 XMPP

  411. ralphm passes a ♥️

  412. moparisthebest

    get your dirty unicode out of here ascii will always be enough for me <3

  413. moparisthebest

    /s :D

  414. ralphm


  415. Guus

    ❤ looks like a farting rocket in the font that I'm using.

  416. Guus

    bah, client auto-replaced that. 😕

  417. ralphm

    What's wrong with you?

  418. Guus

    many people have wondered.

  419. moparisthebest

    Guus, screenshot? I want to see the farting rocket

  420. Guus


  421. zinid

    but that looks like a dick

  422. Guus

    and people ask what's wrong with _me_ 🙂

  423. zinid

    a short dick

  424. moparisthebest

    zinid, you are thinking of 3===D-----

  425. ralphm

    Ok, this escalated quickly

  426. Guus

    I see that the quality of discussion here has been improved. My work here is done.

  427. moparisthebest

    I'm dying of laughter over here

  428. ralphm

    Please don't die!

  429. Guus

    (if you must, laughter is a good way to go though)

  430. Guus

    is that a XEP? Kill people over XMPP?

  431. Guus


  432. ralphm

    Maybe as an extension to https://xmpp.org/extensions/xep-0132.html

  433. zinid


  434. zinid

    sasl mechanisms are in all CAPS

  435. moparisthebest

    I've often wanted a mechanism to slap users in the face over the internet

  436. Guus

    I prefer not to authenticate when killing people online.

  437. zinid

    I see total RFC violation here, we need a police

  438. Guus

    moparisthebest You'll be rich and famous.

  439. ralphm

    moparisthebest: so XEP-0132 is just the thing for you.

  440. zinid

    moparisthebest, since you appeal to practice, how do you find federation practical? Sounds like contradicting statements to me

  441. zinid

    over 15 years of federating it has failed everywhere

  442. zinid


  443. ralphm

    You chatting here seems to contradict your point.

  444. zinid

    ralphm, no, we're in a bubble here

  445. zinid

    also, prove me wrong, append federation success stories to xmpp.org pages close to the list of walled gardens of the XMPP

  446. zinid

    I look at mastodon and matrix and scratch my head: what are they doing?

  447. zinid

    they didn't learn our lesson? they think they will be lucky this time?

  448. Guus


  449. Guus ducks, runs.

  450. zinid

    also marginal, hyped though

  451. ralphm

    I've tried to explain this before, but the supposed failure/demise of having large swaths of users on the federated Jabber network is mostly not a technical issue.

  452. zinid

    ralphm, does it matter?

  453. zinid

    I mean what issue exactly lead to a failure

  454. ralphm

    It does, I can personally address technical issues. Product/business choices of companies, or social issues, or funding issues, or UX ones, not so much.

  455. moparisthebest

    zinid, SMTP and HTTP seem to be pretty good examples of successful federation, even if you ignore XMPP

  456. zinid

    moparisthebest, yeah, happened before FAANG, still alive, also, very uneven distribution as noted many times

  457. zinid

    and SMTP is PITA to self host

  458. zinid

    and failed in the sense I pointed above: you either have a marginal network, or power-law

  459. zinid

    xmpp/mastodon/matrix is marginal, smtp/http - power-law

  460. moparisthebest

    I don't think "many users on a few servers" is a flaw of federation, nothing wrong with that in my opinion

  461. ralphm

    It took many, many years for SMTP to get to where it is in terms a federation. Email had so many different vendors and protocols.

  462. moparisthebest

    the point is you can run your own and it works

  463. zinid

    moparisthebest, so, basically a bubble

  464. zinid

    and running your own SMTP is a hard task

  465. Guus

    zinid, I wonder

  466. Guus

    you've been kicking and screaming for a couple of months now

  467. Guus

    basically expressing discontent with anything

  468. zinid

    kicking and screaming

  469. zinid


  470. zinid

    I leave this chat

  471. Guus

    what is your intend...ed end goal here?

  472. Guus

    ... I should have worded that differently.

  473. Guus

    Then again, it's not as if he's a master of subtlety. 🙂

  474. Guus

    (is that a word?)

  475. ralphm

    Subtlety is definitely a word.

  476. Guus

    I was genuinely interested in why he acts so negative all the time. It's not very productive, nor do I think it's something that's motivating him personally. Live must be tough if you only get to work with stuff that's all of the characteristics that he gives to XMPP.

  477. moparisthebest

    oh, he left

  478. moparisthebest

    was going to say running your own SMTP is a nightmare unlike XMPP but meh

  479. moparisthebest

    if anything, that proves it's not "ease of use" or whatever that makes federation a success or not, XMPP is way easier

  480. Guus

    my guess is that SMTP pre-dates businessmodels for silos.

  481. Zash

    Network effect, everything else is subjective

  482. moparisthebest

    if I had to guess I'd say that was it

  483. moparisthebest

    which is kind of why, today, if we want nice things HTTP/browsers have to push them, no one else has the pressure to get nice things :D

  484. Zash

    There was silos in email but they failed somehow

  485. Guus

    XMPP is nice things, even if it's not pushed to the masses in a truly federated way.

  486. Guus

    Zash, I don't think there were. You could always federate with other mail accounts?

  487. Guus

    unless you're not talking about things like Exchange, GMail, etc?

  488. Zash

    Something something fidonet era stuff

  489. ralphm

    Silos, like AOL mail, failed because users demanded connectivity

  490. Guus

    before my time.

  491. Zash

    I wasn't around either

  492. moparisthebest

    Guus, yea I meant "nice things" as in ability to connect despite port blocking, new protocols like QUIC etc

  493. ralphm

    At this point, I only see this happening through some antitrust measure.