jdev - 2020-03-07

  1. Жокир has left
  2. Жокир has joined
  3. strar has left
  4. strar has joined
  5. debacle has left
  6. paul has left
  7. Жокир has left
  8. Жокир has joined
  9. Жокир has left
  10. Жокир has joined
  11. larma has left
  12. larma has joined
  13. Жокир has left
  14. Жокир has joined
  15. gav has left
  16. Жокир has left
  17. Жокир has joined
  18. lovetox has joined
  19. Жокир has left
  20. Жокир has joined
  21. lovetox has left
  22. DebXWoody has joined
  23. Жокир has left
  24. Жокир has joined
  25. Sam Whited has joined
  26. lovetox has joined
  27. DebXWoody has left
  28. DebXWoody has joined
  29. DebXWoody has left
  30. paul has joined
  31. Syndace has left
  32. Syndace has joined
  33. DebXWoody has joined
  34. Жокир has left
  35. Жокир has joined
  36. Jeybe has joined
  37. Жокир has left
  38. Жокир has joined
  39. Bartek has joined
  40. Bartek has left
  41. asterix has joined
  42. Жокир has left
  43. Жокир has joined
  44. asterix has left
  45. asterix has joined
  46. Alex has left
  47. Alex has joined
  48. asterix has left
  49. asterix has joined
  50. pulkomandy has left
  51. Жокир has left
  52. Жокир has joined
  53. pulkomandy has joined
  54. Жокир has left
  55. Жокир has joined
  56. pulkomandy has left
  57. paul has left
  58. paul has joined
  59. pulkomandy has joined
  60. Martin has left
  61. Martin has joined
  62. paul has left
  63. paul has joined
  64. Жокир has left
  65. Жокир has joined
  66. asterix has left
  67. asterix has joined
  68. Martin has left
  69. Martin has joined
  70. Жокир has left
  71. Жокир has joined
  72. pulkomandy has left
  73. pulkomandy has joined
  74. asterix has left
  75. asterix has joined
  76. paul has left
  77. paul has joined
  78. Jeybe has left
  79. Jeybe has joined
  80. asterix has left
  81. asterix has joined
  82. asterix has left
  83. Жокир has left
  84. Жокир has joined
  85. debacle has joined
  86. Жокир has left
  87. Жокир has joined
  88. asterix has joined
  89. Jeybe has left
  90. pulkomandy has left
  91. pulkomandy has joined
  92. pulkomandy has left
  93. Жокир has left
  94. Жокир has joined
  95. pulkomandy has joined
  96. Jeybe has joined
  97. pulkomandy has left
  98. lovetox has left
  99. Marc has left
  100. Marc has joined
  101. Martin has left
  102. Martin has joined
  103. pulkomandy has joined
  104. asterix has left
  105. asterix has joined
  106. pulkomandy has left
  107. Jeybe has left
  108. pulkomandy has joined
  109. asterix has left
  110. asterix has joined
  111. asterix has left
  112. asterix has joined
  113. asterix has left
  114. asterix has joined
  115. pulkomandy has left
  116. pulkomandy has joined
  117. lovetox has joined
  118. asterix has left
  119. asterix has joined
  120. pulkomandy has left
  121. pulkomandy has joined
  122. jeybe has joined
  123. asterix has left
  124. asterix has joined
  125. asterix has left
  126. asterix has joined
  127. asterix has left
  128. asterix has joined
  129. jeybe has left
  130. Jeybe has joined
  131. Жокир has left
  132. Жокир has joined
  133. pulkomandy has left
  134. Жокир has left
  135. Жокир has joined
  136. lovetox has left
  137. Жокир has left
  138. Жокир has joined
  139. Жокир has left
  140. Жокир has joined
  141. pulkomandy has joined
  142. Жокир has left
  143. Жокир has joined
  144. lovetox has joined
  145. pulkomandy has left
  146. asterix has left
  147. pulkomandy has joined
  148. asterix has joined
  149. lovetox has left
  150. asterix has left
  151. asterix has joined
  152. sonny has left
  153. Marc has left
  154. Marc has joined
  155. Jeybe has left
  156. lovetox has joined
  157. lovetox if i end a stream correctly, does the server send unavailable presences out?
  158. lovetox or do i have to do this myself befor i end the stream
  159. Zash Server sends unavailable when the session ends, if it's still available at that point.
  160. Жокир has left
  161. Жокир has joined
  162. lovetox hm not sure this answers my question
  163. pep. "yes, if the server is not down"?
  164. lovetox i send </stream> and end my stream
  165. Zash lovetox: the answer is yes
  166. lovetox ok thanks :)
  167. Zash the server will send unavailable if you don't
  168. lovetox ok and its not considered bad by the client to not send it themself
  169. Kev I'd consider it daft to do so.
  170. Jeybe has joined
  171. lovetox Kev, its daft to send presence themself as client?
  172. lovetox or not?
  173. Kev Yeah. The server's going to do it for you, so I think it's daft for a client to maintain code to duplicate that.
  174. lovetox great, i thought so too :)
  175. pulkomandy has left
  176. Zash In theory you can set a status message while you're offline, but I don't think the server is required to keep that.
  177. Zash Probably made more sense before always-on mobile clients
  178. pep. "always-on"
  179. asterix Except if you want to set a good bye status message.
  180. lovetox hm yeah true we actually have a good bye message feautre
  181. lovetox and im pretty sure servers keep that
  182. Zash I'm reminded of the disussions around having status messages in PEP instead of presence
  183. lovetox i see that all the time if people leave a muc
  184. lovetox and going offline
  185. pep. Zash: a "bye message" in PEP?
  186. lovetox and of course they have to keep it
  187. lovetox its a presence i send, the server does not know that im going to go offline in a sec
  188. Zash lovetox: no, they just have to broadcast it
  189. lovetox i thought thats what keeping it means
  190. lovetox or do you send a second unavailable presence after i send mine and end the stream
  191. lovetox i think not
  192. Zash Prosody does not keep unavailable presence around after broadcasting them
  193. lovetox why would i need the server to store the message?
  194. Zash and after that there's no point of generating unavailable on disconect
  195. lovetox i told everyone that is online that im going offline
  196. Zash I'm not sure I follow what you're saying
  197. Sam Whited What if I'm offline when you send that message, you go offline, then I come online? I might also want your status message (which is why it should be in PEP in my opinion).
  198. lovetox yeah thats not possible
  199. Kev Sam Whited: I have a TODO from the Summit to write presence-over-PEP, BTW.
  200. lovetox but thats not a reason to not tell the people who are online and are able to receive it, to not tell them
  201. Zash I believe there's a hint in one of the RFCs that the server could keep the last unavailable presence of the last resource and send in response to probes later, but I'm pretty sure it's optional and at least Prosody doesn't do this.
  202. Sam Whited Kev: oh that's interesting, I was just thinking about specifics like a status messages being a new thing in PEP, not presence in general and all the other information it conveys. I'll be curious to see that
  203. Kev Sam Whited: I mean status/show, really.
  204. Kev So <presence/> becomes device information, and PEP becomes user information.
  205. Zash https://xmpp.org/rfcs/rfc6121.html#presence-probe-inbound
  206. Zash point 3 there has the text I was thinking of
  207. Zash PEP is better tho
  208. lovetox its just much much more traffic for nearly no gain
  209. lovetox previously it was 100 presences on coming online, then its doubled because everybody puts status and show in pep
  210. lovetox also its probably fine to have a account wide status
  211. lovetox but show?
  212. lovetox if i come online i get the last pep info, show = online
  213. lovetox but no presence means offline
  214. lovetox also there is an information loss, if i see a work pc as away, but the smartphone as online
  215. lovetox i can assume a person is not at his workplace right now
  216. Sam Whited I'd be okay with that; personally I prefer to treat status as an account thing. You can either reply to messages or not and I shouldn't have to think about what clients are busy and online and away.
  217. Sam Whited With carbons and MAM it becomes way less important to have each individual device have more granular status than online and offline.
  218. Kev lovetox: I don't think you can assume that at all.
  219. Kev I frequently have my phone with me when I'm in the office, but have stepped away from my desk.
  220. lovetox thats what i meant with not at your workplace
  221. lovetox the desk
  222. Sam Whited lovetox: but why would it be marked as away? I suspect most people don't change their status every time they step away from their desk for a few minutes, and they still have their phone on them so it's not like they're going to miss your message if you send them one?
  223. lovetox Point is, right now we have the possibility to maintain a show value per client, this is a feature, for some people this is useless, others find it veryuseful, it depends on the circumstances
  224. lovetox you want to take this away, and i simply ask, what for, what is the gain we have from that?
  225. lovetox Sam Whited, auto away is a thing
  226. Sam Whited A much simpler system for users.
  227. lovetox If you want to make it simple for YOUR users, nobody forces you to display the show value from each device
  228. Sam Whited Who finds it very useful? Are people still sending messages to individual clients?
  229. lovetox Sam Whited, its about the information, not about sending messages
  230. lovetox A device is autoaway for 20 minutes
  231. lovetox thats a device status, and a device show
  232. Sam Whited lovetox: I don't understand what people are doing with this information then.
  233. lovetox this information is useufl
  234. Sam Whited It seems like an anti-feature to me.
  235. jonas’ it becomes useful once you have to deal with device-to-device communication
  236. lovetox you dont have to, point is xmpp offers that information
  237. jonas’ like jingle file transfers and calls
  238. lovetox if you dont want to show it to your users, dont
  239. lovetox you dont need a show in pep, to reduce to presence shows to one
  240. lovetox you dont need a show in pep, to reduce two presence shows to one
  241. jonas’ having an account-wide show is also a useful thing though
  242. Sam Whited lovetox: it's not just about showing it, it's about setting it. I already do only show one to my users
  243. jonas’ having a user-controlled account-wide show is also a useful thing though
  244. lovetox like all other clients
  245. lovetox so i dont see any gain for the user here
  246. Sam Whited IMO anything that involves individual clients we should be fixing or getting rid of; eg. Jingle too. If someone sends me a file I should pick what device to receive it on, not them.
  247. lovetox now its one, afterwards its one
  248. pulkomandy has joined
  249. serge90 has left
  250. lovetox i see XMPP can deal with multiple devices as a feature
  251. lovetox yes its tricky sometimes
  252. lovetox yes its not easy for devs to make this easy for users
  253. lovetox but its nevertheless a big feautre, that other messengers like whatsapp never had for years
  254. lovetox and still to this day its not even near XMPP
  255. lovetox i think todays users can be trusted to get the gist of a system with multiple devices
  256. lovetox we dont have to treat them as super dumb
  257. jonas’ I’m not sure that’s true
  258. Sam Whited I still really don't see the use case, "having more features than WhatsApp" isn't a usecase, and may not even be a good thing.
  259. Kev I'm not sure providing features that make sense is about user being stupid.
  260. lovetox im now a few years in very near contact with users of Gajim, and never had even one asked what it means that there are 2 devices listed with different show
  261. lovetox and status
  262. lovetox Kev what is the feature you are talking about
  263. lovetox as we already said, all clients show ONE show value already
  264. lovetox moving this into pep, and afterwards showing ONE show value
  265. lovetox makes 0 difference for any user
  266. Kev Allowing a user to set a status message applicable for themselves, rather than a device.
  267. lovetox we talk since 10 minutes about show
  268. lovetox not status
  269. lovetox but yes i agree, account wide status can be useful
  270. Kev And to be able to say that they're "Do Not Disturb" and not have that change because a client that had disconnected suddenly gets a connection again.
  271. Sam Whited I probably confused that, I always call that status but I meant online/away/busy not the status message
  272. Sam Whited And if you're just asking your users who already use XMPP that's a very self-selecting sample set. We're trying to make the network make sense and be easier for everyone, not just existing XMPP users.
  273. pulkomandy has left
  274. lovetox you make it easier in one department, and loss stuff in the other
  275. Sam Whited What are we losing? I still don't see any use case for per-device show values. The Jingle one makes sense, but we need to fix jingle not keep this weird state where show is per-device.
  276. lovetox obviously the show from each device, if you only have one
  277. jonas’ > If someone sends me a file I should pick what device to receive it on, not them. how are you going to do that if you’re AFK?
  278. Sam Whited Again: what is the use case? I understand *technically* what information is being lost, I don't understand why we care about that information.
  279. lovetox but lets leave this for now, i see you dont find it useful so it has to go
  280. jonas’ will the transfer be stuck until you "accept the call" on one device?
  281. lovetox what about the PEP spam?
  282. jonas’ will you configure a default preference?
  283. lovetox how much more info you want to put in different PEP nodes?
  284. Sam Whited jonas’: I dunno, we can figure that out later. Completely different discussion
  285. jonas’ Sam Whited, I find this not completely different, but ok
  286. lovetox when i come online, how many MB data do i have to download from the server, just so im up to date with everyone
  287. lovetox ?
  288. jonas’ lovetox, good question!
  289. lovetox Put it into PEP, is not a scaleable solution
  290. lovetox and we/you should think rather sooner about how to solve this
  291. jonas’ it’d be more scalable if PEP updates from a single contact were aggregated in a single stanza
  292. Sam Whited Oh, is the argument changing to scalability now? The goalposts appear to be moving.
  293. lovetox Sam Whited, why is a goalpost moving, if i have multiple points why this is bad?
  294. asterix has left
  295. pulkomandy has joined
  296. lovetox i respect that you dont share my opinion about show per device is useful
  297. Sam Whited The points are changing without actual answers to the previous questions. I agree, we should talk about scalability too though, but I'm less concerned about the technical side of things, we can solve that when we write the XEP.
  298. Kev lovetox: The proposal isn't that per-device presence payloads become illegal. Just that they're not used if what you're trying to convey is the status of the user rather than a device.
  299. lovetox you cant solve pep scalability by writing another UserStatus xep
  300. Sam Whited lovetox: do we know that it's not scalable before we write the XEP? How do we know it doesn't save us a lot of stanzas?
  301. Sam Whited For example, let's say we have a system like the original we were describing where status messages work even if the user is offline. If we did that in the current presence based system, every time the user is online they have to do a presence probe for all of their offline contacts. In PEP they just get that pushed down only for contacts that have actually pushed a presence. That probably saves a lot of round trips.
  302. Jeybe has left
  303. lovetox You compare something, nobody actually does, and nobody will ever do (probing offline users) against your PEP proposal
  304. lovetox but yeah that would save roundtrips
  305. Kev Offline users do get probed when you come online, all your contacts do.
  306. Kev That's how you find out that they're offline (or not)
  307. Sam Whited Sure, the point is that there are ways it could save us stanzas and we won't know until we figure out how it's used and write the XEPs.
  308. Sam Whited Let's take the show example (I'm not suggesting this is how we should do it, I'm just saying that your assumption that it's more traffic isn't necessarily true): if we move show into PEP we could imagine a system where after we come online we get a single presence for only online devices like we get today. That contains the accout status value then *after* that we start getting updates from PEP. Now we have the niceties of device/account information being separated, but still get the same number of stanzas on login
  309. Sam Whited Or we could get show from PEP on login and not get presences at all, then probe accounts for devices only if/when we need them lazily. This would likely drastically reduce the amount of traffic on login (I think? Maybe we always need caps right away so this wouldn't work). Again, not suggesting we should do these things, just that "it will increase traffic" isn't something we know yet.
  310. pulkomandy has left
  311. lovetox Sam Whited, really you are talking about changing stuff in the whole eco system
  312. lovetox we just talked about putting show into PEP
  313. lovetox and yes this would double traffic, given all ccontact use this
  314. Sam Whited Yes, these are the things putting show in PEP eventually could allow us to do. I'm not suggesting we do them right away or that they're even possible necessarily, just that they're good examples of why "it will increase traffic" isn't a good argument.
  315. Sam Whited It might double traffic, or it might make it lesser overall once we start moving more things into PEP.
  316. lovetox are we talking about the same thing? you know how PEP works or?
  317. Sam Whited We won't know until we think about it a lot more, write the XEP, maybe start getting implementation experience.
  318. lovetox PEP says, on +notify, it pushes the last node of every contact, for every node you subscribe to
  319. lovetox so yes this is not scaleable
  320. lovetox unless you fundementally change PEP / Pubsub, putting more stuff in PEP will increase traffic
  321. Sam Whited Maybe "account info" is a node that contains lots of things in one big payload that previously would have been sent by many different presence/message/IQs.
  322. Sam Whited Maybe offline nodes are removed and the deletion signals offline (unless we have a feature where we keep a status message around or something). Now we stop getting updates from those and it's basically the same as presence was. There are all kinds of ways this could reduce the amount of traffic sent.
  323. lovetox yeah thats thinking about scaleability
  324. pulkomandy has joined
  325. debacle has left
  326. lovetox and that what we should do before adding more things into PEP
  327. Sam Whited Right, which is why I think we can't just say "it will double traffic" without an XEP and possibly implementation experience.
  328. Sam Whited I dunno, maybe it's not enough traffic to matter what happens before moving more things to PEP. Or maybe it is. The point is we don't know right now.
  329. lovetox i know, Gajim implements every UserPEP Xep there is
  330. lovetox and believe me even on accounts with 20 users, this means endless stanzas
  331. Sam Whited You're wanting me to argue that it absolutely will reduce traffic, and I'm not arguing that. I'm just arguing that your assertion that it will double traffic may or may not be true and it's not a good argument for why we shouldn't bother to move show/status into PEP.
  332. lovetox my assertion was it will double traffic, if you copy UserPEP XEP XY and do the same with status and show
  333. lovetox and that was definitly on the mind of everybody when this discussion started
  334. Sam Whited Why are you thinking that's what would happen when you haven't read Kevs theoretical XEP?
  335. lovetox now we moved the goalpost to, oh yeah that XEP would have to keep scalability in mind
  336. lovetox and im fine with that :)
  337. lovetox Kev can share it and prove me wrong, im happy if we have good solutions for problems
  338. Sam Whited Anyways, I shouldn't have let myself be drawn into pivoting this into a technical discussion. We're not there yet. My argument is that we need to think about use cases and users, and I don't see one for how the existing system works.
  339. lovetox also MUC incompatibility with PEP is a problem since a longer time, dont know if we have the same problem with MIX
  340. Sam Whited I sometimes think that we need to treat the public network as a service when we're writing XEPs. Maybe we need a Jabber product manager (or product mangaer committee) who puts together a cohesive vision for what the Jabber Service should look like in the future, and then decides if XEPs guide us towards or away from that.
  341. Sam Whited Yah, MUC would definitely have to be thought about, that's always tricky. Still though, that's all a ways out and isn't an argument for why we shouldn't write the XEP. It's definitely worth thinking about while writing it.
  342. Sam Whited Anyways, I need to step out now and get ready to leave. Please think about use cases. I'd really like to know if there actually is one for the current system.
  343. sonny has joined
  344. pulkomandy has left
  345. DebXWoody has left
  346. DebXWoody has joined
  347. Jeybe has joined
  348. pulkomandy has joined
  349. pulkomandy has left
  350. pulkomandy has joined
  351. Jeybe has left
  352. debacle has joined
  353. serge90 has joined
  354. Martin has left
  355. asterix has joined
  356. Martin has joined
  357. Marc has left
  358. pulkomandy has left
  359. pulkomandy has joined
  360. Marc has joined
  361. raucao has left
  362. pulkomandy has left
  363. pulkomandy has joined
  364. pulkomandy has left
  365. pulkomandy has joined
  366. asterix has left
  367. asterix has joined
  368. Жокир has left
  369. Жокир has joined
  370. moparisthebest has left
  371. lovetox is it possible from the outside to see that a websocket connection is a xmpp connection?
  372. Zash Based on looking at the TLS connection? Probably not easily.
  373. lovetox as i understand websocket, first a normal HTTPS connection is made
  374. Zash Timeing information might leak that it's not following the common request-response pattern of HTTP
  375. lovetox then within that the protocol is upgraded to websocket
  376. Zash Yeah
  377. lovetox ok so if i want to conceil the fact that its an xmpp connection, this is probably a safer bet than xep0368
  378. lovetox we announce a protocol xmpp-client with 0368
  379. lovetox is this transfered in plaintext, within the tls negotiation
  380. lovetox or afterwards is the question
  381. Zash ALPN is sent in plain text in the beginning of the TLS handshake
  382. lovetox yep so trivial to see that its an xmpp connection
  383. goffi has joined
  384. DebXWoody has left
  385. DebXWoody has joined
  386. moparisthebest has joined
  387. asterix has left
  388. asterix has joined
  389. moparisthebest Unless you don't send it, it's not mandatory, if you need to conceal this you should not send it
  390. moparisthebest Same with SNI
  391. Zash Can't get around the certificate being returned in the clear tho.
  392. moparisthebest Though encrypted SNI is almost here, I expect encrypted alpn to follow shortly
  393. moparisthebest Zash: iirc that's fixed already in TLS 1.3 ?
  394. Zash Dunno
  395. lovetox hm if i dont send the protocol than a webserver also running on 443 will not know that i want to talk to the xmpp server or?
  396. lovetox i think i ran into that problem early in my implementation
  397. moparisthebest > The difference is that in TLS 1.3, a lot less is in the clear. For example, in TLS version 1.2 you were able to witness the disclosure of the Subject Alternative Name (SAN) in the Certificate but in 1.3, this is encrypted and not made available for inspection by any intermediate system.
  398. moparisthebest From our favorite company https://blogs.cisco.com/security/tls-version-1-3-change-is-here-and-encrypted-traffic-analytics-has-got-your-back
  399. moparisthebest lovetox: depends on how the server is set up, maybe, maybe not, that's why it's important you keep trying all the SRV records
  400. moparisthebest Unless you must not be detected of course, in which case you abort
  401. lovetox hm problem is when connection succeeds i will not try others
  402. lovetox maybe i should wait for the first <stream> to make that decision
  403. moparisthebest Yep absolutely
  404. moparisthebest Also if TLS verification fails you should keep trying
  405. lovetox eh actually im in the camp to not shadow a badley setup server with various workarounds
  406. moparisthebest I haven't had problems with gajim, but dino won't connect to my server unless I patch out their xep 368 module because of that error
  407. moparisthebest You aren't, you are allowing easy DOS
  408. lovetox if a cert verify fails, why would it not fail on a other connection method?
  409. lovetox can you give me the address of your xmpp server so i can try if it works in my new code?
  410. moparisthebest Any mitm can accept a TCP connection
  411. moparisthebest lovetox: mitm ?
  412. lovetox a mitm that only mitm on one connection method?
  413. moparisthebest burtrum.org , feel free to poke, so if you don't send alpn over ipv4 you'll end up taking to nginx
  414. moparisthebest lovetox: absolutely? Plenty of ways, v4 vs v6, servers in different datacenters
  415. moparisthebest Maybe captive wifi is only set to mitm 443 not 5223
  416. moparisthebest Basically your code should never stop trying based on anything an attacker could cause
  417. lovetox but this is too complex
  418. lovetox cert on my server is expired
  419. lovetox i dont care, gajim shows me the error, i tell it to connect anyway
  420. lovetox trying everything first and remembering the first cert fail, then if everything fails coming back to that and offer the user to connect anyway
  421. lovetox really dont want to implement that
  422. lovetox also if you assume every cert fail is an attacker
  423. lovetox then you simply cant connect to a server anymore that has no valid cert
  424. lovetox which is also a choice i want to give to the user
  425. lovetox i can connect fine to your server btw
  426. lovetox also i dont see it as my responsibility to make Gajim into a tool that can withstand a DOS
  427. lovetox attack
  428. pep. lovetox: if you remember the cert you might allow the user for some more time.. I always find this weird tbh, this expiry thing. Tge cert expired but you're still connected so you don't care, even if it's been a week already, and when you reconnect you (the client) is like "omg the world is burning"
  429. asterix has left
  430. asterix has joined
  431. lovetox yeah i also fail to see how a expired cert is suddenly insecure
  432. lovetox if its expired for 2 years
  433. lovetox ok an attacker had plenty of time to attack that cert
  434. lovetox but a week? ..
  435. pep. I guess it mostly shows how much the admin is active :p
  436. pep. or how skilled in cron they are!
  437. pulkomandy has left
  438. pulkomandy has joined
  439. asterix has left
  440. asterix has joined
  441. moparisthebest Right but I want gajim to connect from sleazy free WiFi if possible, not give up on first mitm or blocked port
  442. moparisthebest That entirely defeats the purpose of srv
  443. pulkomandy has left
  444. pulkomandy has joined
  445. Zash I don't think SRV was invented as a way to avoid MITM or blocks
  446. kikuchiyo has left
  447. kikuchiyo has joined
  448. DebXWoody has left
  449. kikuchiyo has left
  450. lovetox wait, blocked port is different story
  451. lovetox Gajim will try until it has a successful connection with the host and port gathered via SRV
  452. moparisthebest A mitm can accept a TCP connection though
  453. moparisthebest You shouldn't give up until you have cryptographic proof you can't successfully connect to the server
  454. pulkomandy has left
  455. Zash prove a negative?
  456. pulkomandy has joined
  457. moparisthebest Like, they provide a proper cert and then reject you with bad password, for instance
  458. moparisthebest And srv explicitly was invented to prevent dos, one service is down or unreachable or misconfigured, try the others
  459. Zash Where does it say that?
  460. lovetox has left
  461. moparisthebest What other purpose could it possibly have? Otherwise just use a well known port like http
  462. lovetox has joined
  463. Zash RFC says it's for moving services and designate backup servers. There's one mention of "denial of service", in the context of SRV being used *for* it.
  464. moparisthebest Don't need backup servers if nothing can go wrong at your primary
  465. moparisthebest If something can go wrong though, why not try the backup
  466. Жокир has left
  467. Жокир has joined
  468. Жокир has left
  469. Жокир has joined
  470. Жокир has left
  471. Жокир has joined
  472. Marc has left
  473. Жокир has left
  474. Жокир has joined
  475. Жокир has left
  476. Жокир has joined
  477. Жокир has left
  478. Жокир has joined
  479. Syndace has left
  480. Syndace has joined
  481. pulkomandy has left
  482. pulkomandy has joined
  483. lovetox has left
  484. pulkomandy has left
  485. pulkomandy has joined
  486. asterix has left
  487. goffi has left
  488. defanor FWIW, that's the thing that bothered me about both "happy eyeballs" and looping through SRV records too: there can be scenarios in which a connection is possible, yet a client would fail to connect while following those. But fighting potential DOS via an unknown MITM (or poor connectivity) seems like a rabbit hole: even if you succeed in establishing a TLS connection, a MITM or a poor network could simply start dropping packets after
  489. defanor passing a few.
  490. Жокир has left
  491. Жокир has joined
  492. moparisthebest That's fine, xmpp works fine over those kind of networks