XSF logo XMPP Council - 2019-03-13


  1. Neustradamus has left
  2. Neustradamus has joined
  3. Tobias has joined
  4. lnj has joined
  5. moparisthebest has left
  6. moparisthebest has joined
  7. lnj has left
  8. Kev has left
  9. lnj has joined
  10. Kev has joined
  11. oli has joined
  12. oli has left
  13. debacle has joined
  14. pep. has left
  15. pep. has joined
  16. Holger has joined
  17. lnj has left
  18. Holger has left
  19. Holger has joined
  20. Holger has left
  21. Holger has joined
  22. Holger has left
  23. Holger has joined
  24. Holger has left
  25. oli has joined
  26. Holger has joined
  27. Holger has left
  28. pep. has left
  29. pep. has joined
  30. Holger has joined
  31. lnj has joined
  32. oli has left
  33. oli has joined
  34. oli has left
  35. Holger has left
  36. Holger has joined
  37. Kev Do we have an agenda for today?
  38. Link Mauve Nafaik.
  39. moparisthebest There are pending protoxeps but maybe too late
  40. Kev If those didn't make it onto an agenda, I guess next week for them.
  41. Link Mauve Yes, we do have https://github.com/xsf/xeps/pull/765
  42. zinid just in case you also have: https://xmpp.org/extensions/inbox/eax-cir.html
  43. dwd Yeah, no agenda, sorry - things are a bit mad for me at work currently.
  44. Kev I've been completely swamped for the last few weeks.
  45. Kev I have at least got out votes for the meeting two weeks ago just before they expire.
  46. jonas’ it is reassuring that we’re all being swamped at the same time at least
  47. jonas’ hasn’t been much better for me either, as you can probably guess by the editor latencies
  48. zinid the council is swamped, okay
  49. Link Mauve I’ve also been both swamped, and got my main laptop stolen. :x
  50. Kev Oh, that's sucky.
  51. Link Mauve I do have backups, but I need to get a new one asap.
  52. Link Mauve And also a new passport.
  53. jonas’ Link Mauve, ouchie
  54. dwd Oh, that does suck, indeed.
  55. dwd So, anyway:
  56. dwd 1) Roll Call
  57. Kev Here.
  58. dwd Link Mauve and jonas’ I assume are here - Ge0rG?
  59. jonas’ I am
  60. dwd Well, we'll move on.
  61. dwd 2) Agenda Bashing
  62. dwd I see two ProtoXEPs, and nothing else.
  63. jonas’ I haven’t checked the editor inbox in the last 7 days, unfortunately.
  64. jonas’ (mostly)
  65. 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.
  66. jonas’ I agree with that
  67. 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.
  68. dwd Oh, and Jingle Message Initiation has been requested to move to Draft.
  69. Link Mauve So a last call?
  70. dwd Kev, yes, but all these things have been posted to the standards@ list, so it's entirely our fault.
  71. jonas’ Kev, we could discuss this particular point in AOB, I have opinions on that.
  72. jonas’ dwd, they have been posted last night though, I can see his point ;-)
  73. 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.
  74. dwd 3) Items for a vote
  75. dwd Kev, I find your faith in me worrying.
  76. dwd a) E2E Authentication in XMPP: Certificate Issuance and Revocation
  77. dwd https://xmpp.org/extensions/inbox/eax-cir.html
  78. Kev Well, if we rely on everyone working out what the agenda will be, there's little point sending out agendas :)
  79. Kev On-list.
  80. jonas’ on-list, obviously
  81. Link Mauve On-list too.
  82. dwd I think I'm tentatively +1. Seems in-scope.
  83. jonas’ oooh
  84. jonas’ ooooh
  85. jonas’ (that’s for the anticipated (b))
  86. dwd What?
  87. dwd Oh.
  88. jonas’ I was just reading XEP-0001 regarding the next one
  89. dwd b) DNS Queries over XMPP (DoX)
  90. dwd https://xmpp.org/extensions/inbox/dox.html
  91. Kev This was an 1stApril wasn't it?
  92. jonas’ this should’ve been on the humorous track
  93. jonas’ and not ever reached council
  94. jonas’ according to '0001
  95. jonas’ I’m getting a call
  96. Kev They're not meant to reach us, indeed.
  97. dwd I genuinely do not know if this one is April 1 or not. But yes, I agree it's out of our scope.
  98. dwd jonas’, People call you about these things now? :-)
  99. Link Mauve There have been people voicing concern that this isn’t any more humorous than the HTTP version.
  100. Link Mauve And could even be more useful.
  101. dwd jonas’, If it *is* intended to be a joke - and I thought DoH was originally - then it's of the wrong Type.
  102. jonas’ dwd, yes
  103. jonas’ it is
  104. 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
  105. jonas’ I messed that one up
  106. dwd Ah-ha.
  107. dwd No worries. We'll skip that then.
  108. jonas’ spoiling the fun though
  109. jonas’ to the minute-taker, please omit the discussion about (b) :)
  110. Kev Let's ...
  111. Kev right, that.
  112. moparisthebest personally, I'd prefer it not be humorous track, but also released april 1st :)
  113. moparisthebest don't know who ends up making that decision, just that it's not me
  114. jonas’ moparisthebest, in the end, it’s you
  115. dwd c) XEP-0353: Jingle Message Initiation
  116. Link Mauve You as the author makes the decision on which track to go through.
  117. jonas’ if you say you actually want this on Standards Track and not Humorous...
  118. moparisthebest it's no more or less serious than DoH, which is a real RFC :)
  119. dwd Oh, wait, are we going to consider this one properly then?
  120. jonas’ I’m afraid so
  121. lnj has left
  122. debacle has left
  123. 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.
  124. 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.
  125. moparisthebest I *mostly* copied them directly from Security Considerations on the DoH RFC, but yes I agree privacy stuff should be added
  126. dwd Kev, You can engineer that, of course...
  127. dwd OK, jonas’, Link Mauve - since we're actually voting, are you two also going on-list?
  128. Link Mauve Yes, I will be.
  129. Link Mauve Leaning towards +1 because it’s a valid usecase and seems properly written.
  130. dwd jonas’?
  131. dwd I'll assume he's trapped on the phone and will on-list.
  132. dwd So back to:
  133. dwd c) XEP-0353: Jingle Message Initiation
  134. dwd Andrew asked for this to be advanced to Draft, so we'd need to vote for Last Call.
  135. Link Mauve Is there any author available to issue the last call?
  136. Link Mauve Or is Andrew becoming the shepard?
  137. dwd Link Mauve, Good point.
  138. Kev Previously, we could have just done this if we wanted.
  139. Link Mauve Or is Andrew becoming the shepherd?
  140. Kev Now we're only allowed to if we determine it's abandoned.
  141. jonas’ dwd, sorry, I’m on call and got a page, that’s what I meant to say earlier
  142. jonas’ I’m on-list, defaulting to -1 otherwise.
  143. jonas’ regarding (b)
  144. jonas’ regarding (c), nothing wrong with LC I think
  145. 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)
  146. dwd I'll follow-up with Andrew to see if he's willing to gether and process feedback, then.
  147. Kev So I think we're obliged to contact Peter and Philip and ask if they've abandoned it.
  148. Kev So I think we're obliged to contact Peter and Philipp and ask if they've abandoned it.
  149. dwd I'll do so.
  150. Kev Ta.
  151. dwd 4) AOB
  152. dwd I know jonas’ had some aboutt agendums, but I assume that can wait and/or be discussed on the Council list.
  153. dwd Anyone else?
  154. Kev Newp.
  155. dwd 5) Next Meeting
  156. Link Mauve +1W?
  157. dwd Same time next week?
  158. dwd That's Wednesday 20th March, 1600 UTC.
  159. dwd 6) Ite, Meeting Est
  160. dwd Thanks all.
  161. Kev I don't currently have anything stopping me, but the way things have been recently... yeah.
  162. dwd Kev, I know that feeling and truly sympathize.
  163. 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?"
  164. moparisthebest but I can have an odd sense of humor, I'm not married to the idea :P
  165. jonas’ people wondering about a spec being a joke or not is generally not good for UX
  166. 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
  167. jonas’ moparisthebest, I don’t think either of DoH or DoX is a good idea
  168. jonas’ but I’m going to read the rationale and be convinced otherwise
  169. 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
  170. Holger has left
  171. zinid what purpose? browsers need this hack because they need to resolve, and an XMPP client doesn't need to resolve anything
  172. zinid not sure if trolling...
  173. moparisthebest if anything an XMPP client needs to resolve much more? don't some resolvers still break on SRV etc
  174. zinid it needs to resolve that to open the stream
  175. Zash HTTP upload eg
  176. moparisthebest not if it's hard-coded, like any DNS resolver will have to be
  177. jonas’ moparisthebest, you don’t need to hard code DNS resolvers
  178. jonas’ you learn them via DHCP or system configuration
  179. zinid Zash, isn't what an HTTP library should do?
  180. 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
  181. moparisthebest that's just not true anymore jonas’ , android 9 hardcodes a DNS-over-TLS by default now, browsers hard-code DoH addresses etc
  182. zinid and we need that insanity in XMPP too?
  183. jonas’ moparisthebest, yes, because they suck
  184. moparisthebest of course, we are forever trying to catch up to HTTP browser levels of insanity
  185. zinid so far that's not we but you 🙂
  186. moparisthebest so, you are a XMPP client, you ask your resolver for SRV records, it returns an error, then what?
  187. moparisthebest it could fall back to connecting to a known/public "resolver xmpp account" and resolving that way
  188. zinid you try A record?
  189. moparisthebest ok so if that fails then
  190. moparisthebest that's one perfectly valid usecase, another is your router staying connected via XMPP and resolving DNS for your network
  191. zinid valid use case in what situation?
  192. 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
  193. zinid when resolver doesn't work, but internet does?
  194. moparisthebest that's 2 usecases I can think up right now
  195. Kev 1.3 to the rescue?
  196. moparisthebest zinid, yep, that happens often
  197. zinid moparisthebest, I don't think often enough to address the problem using stupid hacks
  198. moparisthebest wasn't Ge0rG just complaining the other day that a large % of clients couldn't resolve SRV records?
  199. zinid I don't like this attitude to degrade the tech because of amateur developers
  200. zinid it's not how the industry is progressing
  201. moparisthebest where do amateur developers come in?
  202. zinid you cannot degrade medicine or particle physics
  203. zinid to fit idiots in there
  204. moparisthebest the SRV record thing is bad dns resolvers that haven't been upgraded in 20 years
  205. moparisthebest and/or bad ISPs or countries that block them
  206. Zash and the web doesn't use SRV, so who cares
  207. zinid use A records?
  208. moparisthebest exactly
  209. zinid still better than DoXYZ
  210. moparisthebest zinid, port 5222 is blocked too
  211. zinid and how DoX will help with blocked ports?
  212. moparisthebest maybe we should just make XMPP connect to port 443 on the A record via TLS as a fallback :)
  213. zinid use 443, we already have this insanity
  214. moparisthebest because DoX gets you the SRV records that can point to alternate ports?
  215. zinid and then they will block your ALPN?
  216. zinid what will do next?
  217. zinid looks like an arm race
  218. moparisthebest well, we have encrypted SNI now, so encrypt ALPN using the same setup? :P
  219. moparisthebest it's absolutely an arms race
  220. zinid but why would we need to accept the race? what's the point?
  221. moparisthebest end goal being have everything encrypted and unblockable
  222. moparisthebest then $they find new ways to block, and $we find new ways around those, forever
  223. zinid which means everything is resolved via a single 1.2.3.4 using TLS on 443?
  224. zinid that's what we're going to do
  225. moparisthebest yea, that's already the case basically
  226. 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.
  227. zinid I disagree of course, it's not the case
  228. moparisthebest at least things brings in the possibility for more diversity in resolvers
  229. zinid moparisthebest, there will no be diversity, there will be 1.2.3.4 TLS on 443
  230. moparisthebest zinid, it is the case, android 9 ships by default with all DNS going to google over TLS
  231. zinid and?
  232. moparisthebest browsers already ship with DoH capability
  233. zinid so why we need DoX?
  234. moparisthebest only a short matter of time before they turn on by default
  235. moparisthebest dwd, I agree with you, DoX is equal in it's insanity to DoH, no more, no less :)
  236. moparisthebest both have use cases, both a bit crazy, but use cases nonetheless
  237. dwd moparisthebest, The main use case being having someone like Google get all your DNS lookup data.
  238. zinid yeah, I personally don't care whether it will be Google or moparisthebest.com, both are crap
  239. moparisthebest run your own?
  240. zinid we should not move that road
  241. jonas’ moparisthebest, I already run my own. On port 53.
  242. zinid moparisthebest, why? I have everything working
  243. moparisthebest and every *other* network you go on intercepts that and sends you whatever it feels like jonas’
  244. jonas’ moparisthebest, so? I have dnssec for that.
  245. zinid and I don't want to run my own, that's also insane
  246. jonas’ it can’t, too, because my resolver runs on 127.0.0.1
  247. moparisthebest oh so then they just DOS you?
  248. jonas’ I wanna see them intercept /that/
  249. moparisthebest DNSSEC solves a different set of problems
  250. jonas’ they can DOS me already if they block TCP or UDP or whatever
  251. moparisthebest privacy etc for instance is not addressed by DNSSEC
  252. jonas’ yeah
  253. 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.
  254. moparisthebest take it up with the IETF, they decided it was a great idea
  255. Kev Surely DoX should be using DoH at the other end anyway, because the resolver the DoX box is using might have SRV blocked?
  256. jonas’ moparisthebest, some people under the umbrella of the IETF thought htat
  257. jonas’ that’s a difference.
  258. moparisthebest it's probably too late though, since most devices will be using it soon enough
  259. jonas’ maybe I should switch trades and learn something which isn’t being botched awfully
  260. zinid jonas’, for example what? 🙂
  261. moparisthebest ha I've often thought about that :P
  262. jonas’ zinid, I don’t know
  263. zinid I think every other industry is polluted by this shit
  264. jonas’ anything which has settled more than IT has
  265. zinid maybe academics, but it's totally biased, full of ad hominem and groupthinking
  266. Zash Every other industry isn't 50 years old
  267. jonas’ isn’t *just*
  268. moparisthebest sustenance farming
  269. Zash Potato farming, in the woods?
  270. moparisthebest sure
  271. 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 >:)
  272. 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 🙁
  273. lnj has joined
  274. jonas’ yeah, layer 1 through 3 are nice
  275. moparisthebest jonas’, let me tell you about QUIC
  276. zinid oh yes, QUIC...
  277. jonas’ moparisthebest, that’s above layer 3
  278. Zash A dream of SCTP :(
  279. zinid suddenly they found out that it takes time to adopt SCTP, so let's do everything at layer3 !!!
  280. zinid faster!!!
  281. jonas’ layer 3 isn’t going to change anymore, look at how long it takes to deploy v6 ;-)
  282. jonas’ what?
  283. jonas’ I’ll just leave now, this isn’t good for my mental health
  284. zinid application layer
  285. jonas’ application is 7 or something
  286. jonas’ don’t scare me like that, zinid
  287. zinid in OSI?
  288. jonas’ yeah
  289. zinid okay
  290. jonas’ 3 is IP
  291. zinid yeah, probably
  292. jonas’ don’t scare me like that
  293. jonas’ I treasure layer 3 as my refuge where I go when I feel sad.
  294. moparisthebest but uh, many (most?) middle boxes block any IP that isn't UDP or TCP so....
  295. jonas’ moparisthebest, that’s layer 4
  296. jonas’ UDP and TCP aren’t IPs
  297. moparisthebest which is why QUIC is over UDP, not IP
  298. jonas’ QUIC is over UDP is over IP
  299. Zash A dream of IPSec, but we got TLS instead :(
  300. moparisthebest tl;dr layers don't matter anymore, forget everything you knew about them
  301. jonas’ Zash, IPsec is a horrible mess though
  302. jonas’ moparisthebest, they do matter, up to and including 3
  303. jonas’ which is why I say 1-3 are sane, everything above is madness
  304. Zash jonas’: And TLS ain't?
  305. jonas’ Zash, point taken
  306. moparisthebest you can't do anything with IP though, other than UDP or TCP is what I mean jonas’
  307. Zash TLS seems to have taken on the role of IPSec
  308. jonas’ moparisthebest, working on the infrasturcture which allows UDP and TCP to flow is fun enough and enough "doing something with it"
  309. 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
  310. zinid where we don't have layers anymore
  311. zinid total leak of abstractions from layers to layers back and forth
  312. moparisthebest anyone complain about that with that XMPP SASL thing that needs TLS info? :P
  313. zinid sure, I complained
  314. zinid I can find the complaint in the ML if you like
  315. moparisthebest basically, layer violations are bad unless they give you something good and then they are good
  316. zinid ah, those good intentions
  317. zinid I bet DoH people had good intentions
  318. zinid or maybe it was just Google assasins?
  319. 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
  320. zinid probably even ICMP will be blocked, lmao
  321. moparisthebest ICMP is already mostly blocked
  322. moparisthebest but what's blocking peer-to-peer connections?
  323. zinid well I mean there will be no route to host
  324. moparisthebest other than, lack of ipv6 deployment
  325. 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
  326. jonas’ moparisthebest, IPv6 deployment requires ICMP6, for path MTU discovery.
  327. moparisthebest lots of networks block it though, and it seems to work... but I know what you mean
  328. zinid so *I* think the future of the internet is your "last mile" ISP connected to a CDN
  329. zinid so yeah, the industry is fucked up
  330. moparisthebest I really don't know what you mean by CDNs replacing routers though
  331. Zash Like Google Global Cacehe?
  332. moparisthebest there is a lot of effort towards meshnets too, bypassing all this "internet" crap :P
  333. zinid moparisthebest, how will you bypass the crap when your ISP is connected to google cdn directly and routes nothing?
  334. moparisthebest https://github.com/cjdelisle/cjdns / https://hyperboria.net/ seems interesting/promising
  335. zinid there will be no routers, ISP is a last mile for your phone
  336. zinid then goes Google with CDN
  337. moparisthebest are you saying it blocks everything but google? seems pretty far fetched, hopefully
  338. zinid no
  339. zinid it doesn't block anything, there ARE NOT anything except Google CDN server
  340. zinid there is a nice research paper showing the situation
  341. jonas’ I really should’ve left
  342. moparisthebest I can't quite imagine a dystopia where that happens yet
  343. zinid I thought the same, but now we have DoH 😀
  344. moparisthebest if anything that's anti-centralization, gives you a choice
  345. moparisthebest with dns-over-tcp/udp you only have 1 choice, because your router/isp hi-jacks it and returns whatever they want
  346. moparisthebest over TLS, you can connect wherever you choose
  347. moparisthebest that goes for DoT, DoH, and DoX
  348. zinid yeah, good luck trying to beat it with the technology 🙂
  349. moparisthebest it's all I have
  350. ralphm The problem with SCTP is mostly middleboxes.
  351. zinid given that ISP have no zero incentives to build new routes, because 80% is routed to FAANG, why care?
  352. moparisthebest few have the resources of google/amazon/apple/etc so all we have is tech to battle with
  353. zinid *have now
  354. zinid moparisthebest, especially when they now define tech
  355. ralphm I.e. you not only have to support at the edges, but on each possible route between endpoints
  356. zinid yeah, same problem as IPv6 basically
  357. moparisthebest that's why QUIC is over UDP instead of IP
  358. moparisthebest they've essentially said "fuck it, impossible" to making new IP-based protocols
  359. ralphm Even though I too have the same thing about crossing OSI layers, I appreciate the practical thinking here.
  360. zinid I'm not convinced it's practical, at least no urgency, so better to define a strategy on moving to SCTP
  361. zinid really, what urgency?
  362. zinid I don't buy efficiency, because the application layer protocols are already horribly inefficient
  363. moparisthebest there is the "ideal" way which most people generally agree on, but might be impossible to achieve practically
  364. moparisthebest then there is the "a bit crappy but works" way which can be used *now*
  365. moparisthebest balancing them is rough
  366. zinid *now* is a good argument in the case of IPv4, because the address space is over
  367. zinid but with TCP?
  368. zinid btw, just in case, you can incapsulate SCTP into UDP, there is even an RFC for this
  369. moparisthebest QUIC doesn't replace TCP, it replaces TCP+TLS
  370. moparisthebest I think the main benefits are reduced RTTs, and eliminating head-of-line blocking
  371. moparisthebest I'm sure there are more
  372. zinid yeah, reduce RTT in order to download bloated JS pages
  373. moparisthebest soon bloated WASM pages :D
  374. zinid soon?
  375. moparisthebest gotta keep up
  376. SouL has joined
  377. ralphm moparisthebest: indeed, you can get to 0 round-trips for known endpoints.
  378. 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)
  379. moparisthebest ah right that's handy too
  380. ralphm There are also some benefits regarding how QUIC packets are encrypted and authenticated
  381. ralphm This is an interesting piece: https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00
  382. 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.
  383. moparisthebest so, XMPP-over-QUIC would mean you could do away with Stream Management I think?
  384. moparisthebest and XEP-0397: Instant Stream Resumption
  385. 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
  386. ralphm moparisthebest: yes
  387. ralphm and starttls
  388. ralphm (as TLS 1.3 is baked into QUIC)
  389. moparisthebest incoming XEP-0368v2: SRV records for XMPP over QUIC
  390. moparisthebest hehehe
  391. ralphm I suppose you can just use _xmpp-client._udp for this
  392. zinid I'll probably off this boat
  393. ralphm zinid: at least read that comparison draft I linked. You might find it interesting to know why people have bothered with QUIC.
  394. zinid ralphm, I read it before obviously
  395. zinid and it mostly describes how cool QUIC is
  396. moparisthebest but, old google QUIC or new IETF QUIC because quite different
  397. 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
  398. zinid I think this is related to Google grade clusters
  399. zinid and others just swallow it
  400. moparisthebest sure if you ignore all the *other* benefits I guess
  401. zinid RTT is not a problem for me at all
  402. moparisthebest it's certainly not about "handling more connections"
  403. zinid moparisthebest, I still think it's not a worth to ruin everything and rebuilding from scratch
  404. dwd has left
  405. zinid and putting packets framing into user land
  406. ralphm zinid: I don't think it is ruining everything.
  407. zinid okay, but I do
  408. zinid so I said I'll implement this the latest
  409. zinid when customers and users will jump on my head
  410. moparisthebest things change, when TCP was invented, people switching IPs regularly mid-stream was not-a-thing, now *most* computers do this
  411. 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.
  412. zinid moparisthebest, but this is solved by SCTP
  413. zinid so far the only somewhat valid arguments I hear is all SCTP can do as well
  414. 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?
  415. moparisthebest SCTP is impossible to get on the internet, it's over
  416. zinid moparisthebest, internet is over
  417. 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.
  418. zinid ralphm, I switch the networks everytime, I don't feel discomfort, stream management works for me
  419. moparisthebest ok, now implement that for all other network connections
  420. moparisthebest or, just once, in QUIC
  421. ralphm It does, but there's latency involved due to roundtrips. With QUIC you might achieve 0 RTT to resume.
  422. zinid ralphm, what latency? 1 sec vs 0.1 sec?
  423. zinid I'm fine with that
  424. moparisthebest might be 30 seconds
  425. zinid and might be an hour, sure
  426. ralphm If someone writes a QUIC library, putting XMPP on top should not be hard
  427. moparisthebest but if you don't want change why are you using this new fancy XMPP stuff, SMTP works fine for messaging
  428. moparisthebest also manage your servers via telnet
  429. ralphm zinid: well, I looked at networks in developing nations, and things aren't that bright.
  430. zinid okay, so why we cannot incapsulate SCTP into UDP once again?
  431. zinid there is an RFC
  432. moparisthebest look at you trying to re-invent QUIC here
  433. moparisthebest >:)
  434. ralphm Why would that be better than QUIC, which actually has a lot traction?
  435. zinid moparisthebest, but that RFC was before QUIC, so who is reinventing?
  436. ralphm But is it better?
  437. zinid depends on what is better and for whom?
  438. ralphm For getting to a place where people can benefit from its properties. Not just theoretically, but in practice.
  439. zinid I see 😀
  440. moparisthebest plus it doesn't bundle TLS which is a huge benefit, for RTTs and other things
  441. zinid moparisthebest, regarding telnet and smtp: why aren't you going to matrix?
  442. ralphm I'm happy for Matrix to exist. They have different ideas. We'll see how that works out.
  443. moparisthebest I like XMPP better so far
  444. moparisthebest seems good enough at adapting to new tech too
  445. ralphm moparisthebest: I hear that often around these parts 🤣
  446. zinid moparisthebest, yeah good answer 🙂
  447. zinid so I said like 100 posts above I like TCP so far 🙂
  448. ralphm zinid: good, but that doesn't mean QUIC is useless, does it?
  449. zinid ralphm, obviously anything is useful for something
  450. 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
  451. zinid for someone
  452. moparisthebest <3 XMPP
  453. ralphm passes a ♥️
  454. moparisthebest get your dirty unicode out of here ascii will always be enough for me <3
  455. moparisthebest /s :D
  456. ralphm )-:
  457. Guus ❤ looks like a farting rocket in the font that I'm using.
  458. Guus bah, client auto-replaced that. 😕
  459. ralphm What's wrong with you?
  460. Guus many people have wondered.
  461. moparisthebest Guus, screenshot? I want to see the farting rocket
  462. Guus https://xmpp.igniterealtime.org:7483/httpfileupload/b01dd842-a71f-40bf-be54-9867eb1bb640/pkfpUGLnRJCG_R6lQOmxRg.jpg
  463. zinid but that looks like a dick
  464. Guus and people ask what's wrong with _me_ 🙂
  465. zinid a short dick
  466. moparisthebest zinid, you are thinking of 3===D-----
  467. ralphm Ok, this escalated quickly
  468. Guus I see that the quality of discussion here has been improved. My work here is done.
  469. moparisthebest I'm dying of laughter over here
  470. ralphm Please don't die!
  471. Guus (if you must, laughter is a good way to go though)
  472. Guus is that a XEP? Kill people over XMPP?
  473. Guus <mechanism>laughter</mechanism>
  474. ralphm Maybe as an extension to https://xmpp.org/extensions/xep-0132.html
  475. zinid LAUGHTER
  476. zinid sasl mechanisms are in all CAPS
  477. moparisthebest I've often wanted a mechanism to slap users in the face over the internet
  478. Guus I prefer not to authenticate when killing people online.
  479. zinid I see total RFC violation here, we need a police
  480. Guus moparisthebest You'll be rich and famous.
  481. ralphm moparisthebest: so XEP-0132 is just the thing for you.
  482. zinid moparisthebest, since you appeal to practice, how do you find federation practical? Sounds like contradicting statements to me
  483. zinid over 15 years of federating it has failed everywhere
  484. zinid *after
  485. ralphm You chatting here seems to contradict your point.
  486. zinid ralphm, no, we're in a bubble here
  487. zinid also, prove me wrong, append federation success stories to xmpp.org pages close to the list of walled gardens of the XMPP
  488. zinid I look at mastodon and matrix and scratch my head: what are they doing?
  489. zinid they didn't learn our lesson? they think they will be lucky this time?
  490. Guus bitcoin!
  491. Guus ducks, runs.
  492. zinid also marginal, hyped though
  493. 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.
  494. zinid ralphm, does it matter?
  495. zinid I mean what issue exactly lead to a failure
  496. 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.
  497. moparisthebest zinid, SMTP and HTTP seem to be pretty good examples of successful federation, even if you ignore XMPP
  498. zinid moparisthebest, yeah, happened before FAANG, still alive, also, very uneven distribution as noted many times
  499. zinid and SMTP is PITA to self host
  500. zinid and failed in the sense I pointed above: you either have a marginal network, or power-law
  501. zinid xmpp/mastodon/matrix is marginal, smtp/http - power-law
  502. moparisthebest I don't think "many users on a few servers" is a flaw of federation, nothing wrong with that in my opinion
  503. 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.
  504. moparisthebest the point is you can run your own and it works
  505. zinid moparisthebest, so, basically a bubble
  506. zinid and running your own SMTP is a hard task
  507. Guus zinid, I wonder
  508. Guus you've been kicking and screaming for a couple of months now
  509. Guus basically expressing discontent with anything
  510. zinid kicking and screaming
  511. zinid okay
  512. zinid I leave this chat
  513. zinid has left
  514. Guus what is your intend...ed end goal here?
  515. Guus ... I should have worded that differently.
  516. Guus Then again, it's not as if he's a master of subtlety. 🙂
  517. Guus (is that a word?)
  518. ralphm Subtlety is definitely a word.
  519. 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.
  520. moparisthebest oh, he left
  521. moparisthebest was going to say running your own SMTP is a nightmare unlike XMPP but meh
  522. moparisthebest if anything, that proves it's not "ease of use" or whatever that makes federation a success or not, XMPP is way easier
  523. Guus my guess is that SMTP pre-dates businessmodels for silos.
  524. Zash Network effect, everything else is subjective
  525. moparisthebest if I had to guess I'd say that was it
  526. 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
  527. Zash There was silos in email but they failed somehow
  528. Guus XMPP is nice things, even if it's not pushed to the masses in a truly federated way.
  529. Guus Zash, I don't think there were. You could always federate with other mail accounts?
  530. Guus unless you're not talking about things like Exchange, GMail, etc?
  531. Zash Something something fidonet era stuff
  532. ralphm Silos, like AOL mail, failed because users demanded connectivity
  533. Guus before my time.
  534. Zash I wasn't around either
  535. moparisthebest Guus, yea I meant "nice things" as in ability to connect despite port blocking, new protocols like QUIC etc
  536. ralphm At this point, I only see this happening through some antitrust measure.
  537. dwd has joined
  538. Zash has left
  539. Zash has joined
  540. lnj has left
  541. debacle has joined
  542. debacle has left
  543. moparisthebest has left
  544. moparisthebest has joined