jdev - 2021-01-21

  1. o2 has left
  2. SouL has left
  3. debacle has left
  4. sonny has left
  5. sonny has joined
  6. sonny has left
  7. sonny has joined
  8. o2 has joined
  9. sonny has left
  10. sonny has joined
  11. sonny has left
  12. sonny has joined
  13. sonny has left
  14. sonny has joined
  15. sonny has left
  16. sonny has joined
  17. sonny has left
  18. sonny has joined
  19. mikeye has joined
  20. sonny has left
  21. sonny has joined
  22. sonny has left
  23. sonny has joined
  24. librem5 has joined
  25. librem5 has left
  26. librem5 has joined
  27. librem5 has left
  28. mikeye has left
  29. sonny has left
  30. sonny has joined
  31. sonny has left
  32. sonny has joined
  33. sonny has left
  34. sonny has joined
  35. sonny has left
  36. sonny has joined
  37. sonny has left
  38. sonny has joined
  39. sonny has left
  40. sonny has joined
  41. kikuchiyo has joined
  42. SouL has joined
  43. paul has joined
  44. asterix has left
  45. asterix has joined
  46. asterix has left
  47. asterix has joined
  48. floretta has left
  49. Vaulor has left
  50. SouL has left
  51. floretta has joined
  52. Vaulor has joined
  53. SouL has joined
  54. sonny has left
  55. sonny has joined
  56. asterix has left
  57. asterix has joined
  58. stefan has joined
  59. marmistrz has joined
  60. pulkomandy has left
  61. pulkomandy has joined
  62. oibalos has joined
  63. o2 has left
  64. asterix has left
  65. asterix has joined
  66. jubalh Could someone tell me about a library that implements XEPs? I would like to see how such libraries/their API is designed
  67. flow jubalh: https://github.com/igniterealtime/Smack/tree/master/smack-extensions/src/main/java/org/jivesoftware/smackx
  68. stefan has left
  69. stefan has joined
  70. goffi has joined
  71. jonas’ jubalh, https://docs.zombofant.net/aioxmpp/devel/api/index.html maybe?
  72. jubalh thanks flow & jonas’
  73. jubalh jonas’: who uses aioxmpp again?
  74. DebXWoody has left
  75. DebXWoody has joined
  76. jonas’ jubalh, some people do, I don’t know who they are
  77. jonas’ which is nice, in a way
  78. jonas’ I sometimes get bug reports ;)
  79. Martin Don't you use it for s.j.n?
  80. jubalh I see, I thought maybe there was something popular. I'm not up to date on which client uses what
  81. jonas’ Martin, yeah well, I thought it was obvious that I use it :)
  82. jonas’ jubalh, no client has been ported to aioxmpp
  83. jubalh ok
  84. jonas’ it seems to be not unpopular in IoT applications, judging by the questions/bug reports I get
  85. DebXWoody has left
  86. DebXWoody has joined
  87. jubalh thats interesting
  88. DebXWoody has left
  89. Neustradamus has left
  90. Ge0rG Internet of Python Things?
  91. jonas’ Internet of Schlangs
  92. DebXWoody has joined
  93. DebXWoody jubalh: gloox
  94. Martin Doesn't IoT have mosquitos?
  95. debacle has joined
  96. asterix has left
  97. asterix has joined
  98. marmistrz has left
  99. Yagizа has left
  100. Yagizа has joined
  101. asterix has left
  102. asterix has joined
  103. asterix has left
  104. asterix has joined
  105. asterix has left
  106. asterix has joined
  107. asterix has left
  108. asterix has joined
  109. asterix has left
  110. asterix has joined
  111. asterix has left
  112. asterix has joined
  113. Neustradamus has joined
  114. asterix has left
  115. asterix has joined
  116. oibalos has left
  117. oibalos has joined
  118. DebXWoody has left
  119. asterix has left
  120. asterix has joined
  121. asterix has left
  122. asterix has joined
  123. debacle has left
  124. Neustradamus has left
  125. Neustradamus has joined
  126. adityaborikar has left
  127. Yagizа has left
  128. Yagizа has joined
  129. adityaborikar has joined
  130. debacle has joined
  131. DebXWoody has joined
  132. belong has left
  133. belong has joined
  134. Sam Whited jubalh: https://pkg.go.dev/mellium.im/xmpp as well
  135. jubalh thanks
  136. asterix has left
  137. asterix has joined
  138. Yagizа has left
  139. Yagizа has joined
  140. jonnj has left
  141. marmistrz has joined
  142. jonnj has joined
  143. أبو غيث الشامي has joined
  144. أبو غيث الشامي has left
  145. Sam Whited After discussing it yesterday I went and implemented the WebSocket subprotocol. It was suprisingly easy and required very minimal changes despite the lack of a root element. Now if I can get it working with HTTP2 I can avoid BOSH altogether, so thanks to whomever suggeseted the HTTP2/Websocket RFC.
  146. moparisthebest but will it work with HTTP3 :)
  147. Sam Whited No idea, I'm sure it will eventually if it doesn't work to start.
  148. Sam Whited I keep expecting new versions of HTTP to just have bidirectional streams built in (I thought server push in HTTP2 was going to be this, but for various reasons it's not and can't really be used that way)
  149. moparisthebest my impression is at the HTTP level, 2 and 3 are pretty close to the same, it's just underneath and above that has completely changed
  150. Zash Didn't people conclude recently that HTTP/2 push was a failure?
  151. Sam Whited Zash: probably. It's not reliable to say the least. Although I'd say it was an issue with how it was advertised, not the actual feature. If you just use it for what it was designed for (preloading images and things on the page) it's pretty great and when it's unreliable because a proxy drops it or whatever you just go back to the same thing you had before, no worse. It was a nice optimization when it could be used.
  152. moparisthebest like http2 is (http2 over TLS over TCP) and http3 is (http3 over QUIC (combined TLS and TCP guarantees but over UDP))
  153. Zash Can I be upset that they seem to have invented invented TCP + IPSec?
  154. Sam Whited No, because it's not the same thing at all. My limited understanding of QUIC is that it does a better job than TCP of congestion control (which is what all the tons of complicated HTTP stuff multiplexing various streams was trying to work around)
  155. Sam Whited I'd be curious what differences are in the HTTP layer if it's mostly the same just HTTP over QUIC. Probably getting rid of all the multiplexing stuff since there's less tail time now, but otherwise?
  156. Zash There are multiple TCP congention control strategies.
  157. Zash But maybe it was more SCTP, with multiple independent streams over the same connection.
  158. Sam Whited Zash: and they're all terrible. No matter what you still have the TCP warmup period, as far as I know. QUIC is supposed to be a lot more efficient (though I admit, I've just seen the numbers from Google, I don't really know how it works)
  159. Sam Whited I dunno, it's about time we replaced TCP IMO, so I'm hopeful that this is really better.
  160. Sam Whited It also combines the TLS/TCP handshakes, which is nice. Less stuff to do before you can actually start sending bytes, which has been a significant problem at some companies I've worked at
  161. Sam Whited is looking at the differences now, there's a lot more here than I realized
  162. moparisthebest in addition to combining TLS+TCP handshakes, it also supports network roaming (bye-bye stream management, we don't need you anymore), and (I guess not useful for XMPP) fixes head-of-line blocking
  163. Sam Whited The head-of-line blocking thing will be a big one, I've run into that a lot with HTTP/2 streams
  164. moparisthebest not having to redo connections on network changes alone is a big enough reason for XMPP to use it imho
  165. Sam Whited Indeed
  166. mac has joined
  167. Sam Whited I see a lot of discussion about websockets, but no actual upgrade mechanism being proposed
  168. Sam Whited Although apparently there's something called WebTransport that I don't fully understand that offers bidirectional streams with arbitrary protocols on top? Maybe this will just replace websockets
  169. Sam Whited (and it supports QUIC)
  170. mac has left
  171. mac has joined
  172. mac has left
  173. stpeter has joined
  174. Sam Whited Now as usual I fall back to the question of what packages this should all be in. I could have the current negotiator just have a websocket option and the dial package (which does SRV lookups and creates TCP connections) support websockets, or I could have a new websocket package that has a custom dialer, a custom negotiator, and a bunch of helper methods to eg. dial and negotiate an XMPP session all in one Go that mirrors the functions in the main XMPP package that do that except for TCP.
  175. Sam Whited Organizing code is hard.
  176. Sam Whited Actually, I wonder if I can make this completely transparent from the client side: the dialer would do all the lookups and dial TCP if it can or websocket if that's all that's available (or if a PreferWebsocket option is set or something) and then the session negotiation would just check what type of connection it is and use that protocol. That seems bad somehow, but I'm not sure why.
  177. Sam Whited Probably best to just always let the user be explicit about how they're connecting.
  178. moparisthebest Sam Whited, in a theoretical near-future where a XEP that supports lookup with SRV2 exists, fully transparent makes sense
  179. moparisthebest as that lets the server admin set preferences across websocket, TLS, quic etc
  180. moparisthebest right now SRV and websocket have no relationship so having your library decide priority seems bad?
  181. Sam Whited That's a fair point, the question is really "shoudl the client dev or the server admin decide how we connect"
  182. Kev Sam: FWIW, in Swiften we have a Connector that you tell what you want to connect to, and when it completes it gives you back a connection. At the moment that's just doing 'normal' SRV lookups and picking a service to which you connect. But there's no reason that shouldn't give you an appropriate type of connection based on available transports.
  183. moparisthebest right now the client/library *must* decide, in the future that becomes a question I guess
  184. Kev (Connection here being an abstract interface that it gives you a concrete instance of)
  185. lovetox has left
  186. Sam Whited Kev: thats more or less what I do too. The difference here is that right now the library doesn't care if the connection you hand it is a TCP socket, a Unix domain socket, an in-memory pipe, or even just a string buffer with some pre-configured responses as long as it can read/write to it. If I add websocket it has to know what type the connection is and do a different handshake
  187. Kev The 'Connection' for us abstracts away the details like that.
  188. Kev So (if we did wss, which we don't yet), the wss handshake would be done inside the Connection.
  189. Sam Whited Ah, I see, my "connection" is just something with Read/Write methods
  190. Sam Whited There is a separate concept, the Negotiator, that does the handshake and hands you a session (so right now I have a default negotiator that does XMPP feature stuff, a websocket one that's the same but it uses <open/> instead of <stream> and a component one)
  191. Zash Prosody has a thing where you combine a network resolver strategy with a thing that executes it and returns a connection.
  192. Sam Whited This all makes me think I need to at least provide a way to be explicit and provide the low-level building blocks (so a websocket.Dial function or something), but at a later date I can add websocket support directly to the higher level thing that resolves SRV records and the like. Best of both worlds.
  193. Kev Sam: Ah, right, you mean the application level wss exchange, not the wss transport exchange. Yes, you're right, my bad.
  194. Sam Whited Kev: oh yah, sorry, I wasn't very clear there looking back
  195. moparisthebest yea a "how to connect" flag from the application/client seems appropriate, so today you'd have "SRV" or "wss" or "any" and next year you might add "srv2", maybe?
  196. Kev Describing how M-Link handles this would probably take too long, but it has two layers of this abstraction. One for the connection type, and one for the session type. So you'd have a WSS connection, and a Websocket Client Session or such.
  197. lovetox has joined
  198. asterix has left
  199. asterix has joined
  200. asterix has left
  201. asterix has joined
  202. Sam Whited Oh hey, I already implemented XEP-0156 then forgot about it and never used it. That's convenient.
  203. pulkomandy has left
  204. pulkomandy has joined
  205. pulkomandy has left
  206. pulkomandy has joined
  207. pulkomandy has left
  208. pulkomandy has joined
  209. kikuchiyo has left
  210. flow "bye-bye stream management, we don't need you anymore" stream management could still be used for e.g. TCP to websocket handovers
  211. moparisthebest or between QUIC and those yea
  212. kikuchiyo has joined
  213. asterix has left
  214. asterix has joined
  215. Yagizа has left
  216. o2 has joined
  217. Sam Whited I don't think I've ever noticed this before, but the Web Host Metadata format in XEP-0156 doesn't actually say if the URLs are for c2s or s2s connections. The TXT format does though. I'm not sure what to do about that.
  218. Sam Whited Just try them all if it's from the host metadata file, I guess.
  219. jonas’ I’ll see what my stuff does, sec
  220. jonas’ treats them all as c2s
  221. jonas’ note that s2s is not specified by '156
  222. jonas’ note that s2s TXT records are not specified by '156
  223. jonas’ -> https://xmpp.org/extensions/xep-0156.html#registrar-altconn-values
  224. Sam Whited Thanks:msay begin
  225. Sam Whited oops, sorry
  226. jonas’ it also talks about clients all the time
  227. Sam Whited > The attribute name SHOULD begin with the string "_xmpp-client-" or "_xmpp-server-" It doesn't register it, but the document is the normative text, not the registry I assume
  228. jonas’ in the same sentence it says though that they should be registered
  229. jonas’ my takeaway is that currently there’s no spec which uses the `_xmpp-server-` prefix
  230. Sam Whited Sure, and then it doesn't do that. That just says that they should be registered, not that the registry is normative
  231. jonas’ it also doesn’t define it elsewhere
  232. jonas’ (what `_xmpp-server-$thing` is supposed to mean)
  233. Sam Whited I mean, it specifically says that prefix exists, that sounds like defining it
  234. Sam Whited And I can't imagine what else "server" would mean other than "s2s" if we assume "client" means "c2s"
  235. jonas’ not covered by the spec though
  236. Sam Whited I don't understand why not? Nothing else says "this is only for c2s" as far as I see
  237. jonas’ the linked RFCs do, though
  238. jonas’ for the registered protocols that is, anyway
  239. Sam Whited What RFCs?
  240. kikuchiyo has left
  241. jonas’ XEP-0205 says it’s c2s, RFC 7395 also talks about client-to-server
  242. jonas’ (I’ll just ignore '25 for it being obsolete)
  243. jonas’ (I’ll just ignore XEP-0025 (!= XEP-0205) for it being obsolete)
  244. jonas’ so even if you made up the _xmpp-server-xbosh thing, it’s unclear how that’d even work given that '206 talks about c2s only
  245. Sam Whited Oh, you mean there's no s2s for websocket at all? I mean, I don't see how that would be all that useful, but I also don't see why not. Just grepping around in 7395 I don't see anything that forbids it either
  246. jonas’ (similarly for websockets)
  247. jonas’ afk
  248. Sam Whited oh, nevermind, I see where it says that in the introduction
  249. Sam Whited Fair enough, if I can ignore s2s that sounds good to me. Maybe the -server thing was just leftover from when normal TCP stuff could also be in here.
  250. kikuchiyo has joined
  251. jonas’ or just as a provision for future things
  252. Zash So. How many alternative connection methods are there now?
  253. kikuchiyo has left
  254. oibalos has left
  255. Sam Whited Zash: Last time I counted it was "too many"
  256. moparisthebest but we can just add 1 more using SRV2 to replace them all! https://xkcd.com/927/
  257. Sam Whited Is SRV2 actually a thing anyone is working on?
  258. moparisthebest more than that, it's a requirement for HTTP3
  259. moparisthebest so all browsers etc have already adopted it
  260. moparisthebest I can't say what they actually decided on for a name in here or risk being burned at the stake
  261. moparisthebest drops this and runs https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-03
  262. Zash cries at the mention of SRV2
  263. moparisthebest > The specific name for this RR type is an open topic for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as they are easy to replace. Other names might include "B", "SRV2", "SVCHTTPS", "HTTPS", and "ALTSVC".
  264. Zash I thought "HTTPS" was already decided.
  265. oibalos has joined
  266. Sam Whited moparisthebest: what's already adopted by HTTP3 browsers?
  267. Sam Whited This I-D?
  268. moparisthebest I believe so, maybe an older version, or the one it replaced
  269. o2 has left
  270. o2 has joined
  271. Zash Maybe I misunderstood but I got the impression that it requires DNS software to adopt additional processing rules.
  272. o2 has left
  273. o2 has joined
  274. o2 has left
  275. o2 has joined
  276. moparisthebest oh that would be bad, I didn't get that impression, but it's been awhile...
  277. Zash There are words in that direction here: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-4
  278. moparisthebest I was just reading that
  279. Zash I wrote a parser for this and was hit by how overly complex the RR type is compared to just about everything else in DNS.
  280. moparisthebest unless I missed something those are all SHOULD include related records in Additional section, which, doesn't impose any requirements if a DNS server doesn't understand the format, just makes full resolution harder on the client
  281. moparisthebest and, most but not all DNS servers already do this with SRV etc right?
  282. paul has left
  283. paul has joined
  284. moparisthebest check this for example: `dig srv _xmpps-client._tcp.moparisthebest.com @ns1.moparisthebest.com`
  285. Zash SRV queries including A+AAAA? Yeah
  286. moparisthebest it returns all associated A and AAAA and even my TLSA in there
  287. Zash Oh!
  288. moparisthebest so that's just like "that nice thing you do for SRV now? it'd also be nice if you did it for SRV2!"
  289. Zash Bugs me a bit after 20 years of refusing to implement SRV
  290. kikuchiyo has joined
  291. moparisthebest yea, suddenly YOU KNOW WHAT WOULD BE A GOOD IDEA :P
  292. moparisthebest I'd call NIH if not for the additional stuff included, tags and such
  293. Zash Extensibility ...
  294. moparisthebest shoulda put XML in those dns records...
  295. Zash You can, SVCB is extensible!
  296. Zash Many SRV records have parameters with registries that can be added to, but this lets you add entire new formats inside SVCB/HTTPS, which seems a bit too much
  297. moparisthebest but that's needed for "encrypt your SNI with this key" and "use http3 here" or "use http2 here" or later "encrypt your alpn with this key" etc
  298. moparisthebest it's what'll let us replace all the existing bosh/wss/tls/starttls stuff with 1 lookup in the future
  299. Zash DANE
  300. Zash As you said, returning related records to a SRV query is entirely possible
  301. Sam Whited Yah I don't really understand the difference between this, SRV records, and URL records (or whatever they were which I already thought were just more flexible SRV records)
  302. floretta has left
  303. moparisthebest how would you share a key to encrypt the tls handshake with those other ones? different per host mind you
  304. Sam Whited Make it part of the URI with URL records I guess (although I barely remember how they work)
  305. Sam Whited but okay, sounds like this is merging more stuff than I was thinking
  306. moparisthebest then URL, https:// could mean HTTP 1.1, 2, or 3
  307. moparisthebest it's a big ball of wax I'll give you that
  308. kikuchiyo has left
  309. floretta has joined
  310. kikuchiyo has joined
  311. belong has left
  312. belong has joined
  313. kikuchiyo has left
  314. kikuchiyo has joined
  315. stefan has left
  316. kikuchiyo has left
  317. oibalos has left
  318. oibalos has joined
  319. kikuchiyo has joined
  320. asterix has left
  321. asterix has joined
  322. asterix has left
  323. asterix has joined
  324. asterix has left
  325. asterix has joined
  326. Zash Sam Whited, mostly off-topic, but have you ever looked at ActivityPub?
  327. Sam Whited Zash: vaguely, once, a long time ago. I don't remember anything about it really
  328. Sam Whited Why?
  329. Zash Because it's made out of JSON-LD, which is the JSON encoding of RDF 😛
  330. Sam Whited Do they actually define what you have to send in one place with actual docs?
  331. Sam Whited I don't really care what the encoding is all that much as long as it's not spread over 5 sites and/or only gives you a blob of XML in lieu of docs.
  332. Zash I didn't even know that was a thing.
  333. Sam Whited That's why I'm so pissed at our usage of DOAP. Any time I ask for docs on what I can actually write someone gives me a blob of XML schema that I have no idea what it's telling me to do.
  334. Zash A whole pile of xmlns-prefixes isn't any prettier in JSON, IMO.
  335. Sam Whited I don't care if it's JSON or XML especially.
  336. kikuchiyo has left
  337. Zash HAHA it seems to vary
  338. Zash https://www.w3.org/ns/activitystreams# works as docs at least
  339. Zash But from what I gather, everyone just copies what Mastodon does anyways.
  340. kikuchiyo has joined
  341. goffi has left
  342. Sam Whited I don't know about this particular thing, and I'm sure people will always just copy the original implementation up to a certain point, but if that's the recommended way to do it (as it was with DOAP) that means your spec is too complicated and broken and you should do something else IMO.
  343. Sam Whited I firmly believe it's always better to define behavior in a spec than having a reference implementation, and I fail to see why we're defining a spec if you can't actually implement it from that and people just say "just copy/paste, change values, and hope it's all correct".
  344. asterix has left
  345. asterix has joined
  346. kikuchiyo has left
  347. kikuchiyo has joined
  348. kikuchiyo has left
  349. oibalos has left
  350. kikuchiyo has joined
  351. marmistrz has left
  352. kikuchiyo has left
  353. kikuchiyo has joined
  354. kikuchiyo has left
  355. kikuchiyo has joined
  356. stpeter has left
  357. stpeter has joined
  358. stpeter Oh wow, it seems that my blog is still syndicated at planet.jabber.org despite the fact that I rarely publish anything tech-related anymore. Sorry about that. ;-) At least my latest post is about RFC 8838...
  359. asterix has left
  360. asterix has joined
  361. Zash Nothing wrong with having your blog there, or having non-techical content on planet.
  362. Alex has left
  363. mikeye has joined
  364. stpeter Well, perhaps this will inspire me to post more often about technical topics.
  365. mikeye has left
  366. SouL has left