jdev - 2022-01-07

  1. qy Mother of christ, legitimately the first time i'm seeing https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe
  2. qy So yeah i guess thats it, my hacky pubsub shims are coming back to bite me
  3. al has left
  4. wurstsalat has left
  5. dezant has left
  6. dezant has joined
  7. debacle has left
  8. kikuchiyo has joined
  9. xnamed has left
  10. jgart has left
  11. kikuchiyo has left
  12. jgart has joined
  13. Pete has left
  14. Pete has joined
  15. doge has left
  16. pasdesushi has left
  17. doge has joined
  18. 9lakes has joined
  19. raghavgururajan has joined
  20. Kev has left
  21. Kev has joined
  22. Kev has left
  23. Kev has joined
  24. Kev has left
  25. mac has left
  26. mac has joined
  27. thomaslewis has left
  28. thomaslewis has joined
  29. thomaslewis has left
  30. thomaslewis has joined
  31. thomaslewis has left
  32. thomaslewis has joined
  33. thomaslewis has left
  34. Yagizа has joined
  35. raghavgururajan has left
  36. atomicwatch has joined
  37. thomaslewis has joined
  38. Yagizа has left
  39. Yagizа has joined
  40. thomaslewis has left
  41. SouL has joined
  42. raghavgururajan has joined
  43. jubalh has joined
  44. pasdesushi has joined
  45. emus has joined
  46. pasdesushi has left
  47. atomicwatch has left
  48. thomaslewis has joined
  49. thomaslewis has left
  50. msavoritias has joined
  51. COM8 has joined
  52. COM8 has left
  53. COM8 has joined
  54. COM8 has left
  55. wurstsalat has joined
  56. MattJ qy: for PEP you do *not* need to subscribe to the node manually (some servers may not even support it)
  57. mac has left
  58. MattJ PEP has automatic subscriptions when someone authorizes you as a contact
  59. marmistrz has joined
  60. sonny has left
  61. sonny has joined
  62. dezant has left
  63. dezant has joined
  64. raghavgururajan has left
  65. Alex has joined
  66. debacle has joined
  67. FireFly has joined
  68. rafasaurus has left
  69. rafasaurus has joined
  70. nephele has joined
  71. pasdesushi has joined
  72. Yagizа has left
  73. doge has left
  74. Martin has left
  75. Martin has joined
  76. doge has joined
  77. rafasaurus has left
  78. sonny has left
  79. sonny has joined
  80. rafasaurus has joined
  81. sonny has left
  82. sonny has joined
  83. Kev has joined
  84. Yagizа has joined
  85. 9lakes has left
  86. Vaulor has left
  87. Vaulor has joined
  88. 9lakes has joined
  89. goffi has joined
  90. nephele has left
  91. Dele Olajide has joined
  92. 9lakes has left
  93. Dele Olajide has left
  94. 9lakes has joined
  95. bung has joined
  96. nephele has joined
  97. 9lakes has left
  98. 9lakes has joined
  99. bung has left
  100. bung has joined
  101. jgart has left
  102. 9lakes has left
  103. 9lakes has joined
  104. 9lakes has left
  105. nephele has left
  106. nephele has joined
  107. 9lakes has joined
  108. larma has joined
  109. Yagizа has left
  110. 9lakes has left
  111. Yagizа has joined
  112. 9lakes has joined
  113. 9lakes has left
  114. 9lakes has joined
  115. xnamed has joined
  116. rafasaurus has left
  117. rafasaurus has joined
  118. Wojtek has joined
  119. COM8 has joined
  120. COM8 has left
  121. rafasaurus has left
  122. rafasaurus has joined
  123. goffi has left
  124. goffi has joined
  125. goffi has left
  126. goffi has joined
  127. qy MattJ: oh, okay
  128. qy Thankful, it wasn't working very well anyway
  129. atomicwatch has joined
  130. doge has left
  131. doge has joined
  132. mac has joined
  133. xnamed has left
  134. Wojtek has left
  135. Wojtek has joined
  136. junaid has left
  137. xnamed has joined
  138. emus has left
  139. goffi has left
  140. emus has joined
  141. junaid has joined
  142. Wojtek has left
  143. Wojtek has joined
  144. xnamed has left
  145. Sam Is there any spec (or individual client or server) that uses in-band bytestreams somehow without eg. wrapping it in a larger protocol that would need to be implemented? I don't know why anything would accept an arbitrary bytestream without some other form of negotiation, but I just realized I have absolutely no way to integration test this unless I also implement Jingle or something.
  146. MattJ Sam, did you say https://modules.prosody.im/mod_tcpproxy ? :)
  147. Sam Oh thanks, that looks almost perfect
  148. MattJ It hasn't been touched for a long while, but I'd be surprised if it doesn't still work. If it doesn't, give me a shout, any issues are probably simple fixes.
  149. MattJ I did use it for stuff, back when I wrote it
  150. mac has left
  151. Sam Will do; thanks. I'm mostly concerned with the use of namespace prefixes (this XML library doesn't support prefixes in general, and their use here means that even if it did I'd also have to add specific support to the IBB library, which doesn't feel right, but I'm sure I'll figure something out)
  152. jonas’ it doesn't implement Namespaces for XML 1.0?
  153. Sam It implements namespaces using xmlns and has read-only support for prefixes.
  154. jonas’ that's ok
  155. jonas’ the code supports you using a non-`tcp` prefix
  156. jonas’ if your library doesn't even support that… I'd say you used the wrong XML library to write an XMPP library ;)
  157. Sam Oh cool, I *think* if I set an attribute with a namespace it's happy to make up a prefix (ie. it will just do xmlns:_ns1 or something on the current attribute), so that may be fine
  158. Sam We'll see. I think it's fine given that XMPP doesn't use prefixes in general.
  159. Sam Either way though, figuring out how to add extra attributes to IBB without building in support for this specific non-standard protocol to the IBB library will be weird. Adding arbitrary attributes isn't an extension point I normally support
  160. jonas’ I'd also have expected a child element to be honest.
  161. Sam I don't generally support stuff like that either for things like IBB that are well defined and don't say "and also this can take an arbitrary payload too" if I'm honest, but yah, if I'm just thinking about data modeling with XML I guess I'd expect a child
  162. jonas’ hm, but that's how XMPP works, kind of
  163. jonas’ putting things in a different namespace into other things
  164. jonas’ to extend them
  165. Sam Sure, but I've never really had a problem with it. I just support specific specs. ibb.Open(to, blocksize) or whatever is way easier than returning some custom thing that you can also modify and call add child on and do a builder and then eventually send.
  166. jonas’ myeah, kind of a pain when you'd want to do some rapid prototyping
  167. Sam I guess; hasn't been a problem in practice. Specs mostly indicate whether they expect to be extended or not.
  168. jonas’ nobody expects the ~spanish inquisition~ extension elements!
  169. pep. “I'd also have expected a child element to be honest.” < I guess that's because of the fact that we don't do much ns'd attributes, unfortunately, so we're going in circles :(
  170. Sam Just glancing at aioxmpp it seems to work in a similar way, though maybe I'm misunderstanding something. I can't imagine most libraries let you fully customize every single possible spec and stanza
  171. jonas’ pep., ah, no, here primarily because a child element would allow extension itself.
  172. pep. I'm not sure I understand the difference really. Why wouldn't the attribute allow it
  173. jonas’ Sam, due to the separation of business logic and stanza construction as well as inheritance it's rather easy to patch things though
  174. pep. As long as there's wire protocol to say you use an extension (be it an ns'd attribute or tag)
  175. jonas’ pep., example: extend the protocol up there to do direct TLS over TCP and include a list of root CAs .
  176. jonas’ pep., example: extend the protocol up there to do direct TLS over TCP and include a list of root CAs.
  177. Sam jonas’: I think what he's saying is that you could always do customtcp2:tls="whatever" as well in the same element. It doesn't matter if it's a child of the original data somehow.
  178. pep. I think it's just an arbitrary choice whether we use attributes or tags. A lib could make it as easy to do one or the other it's just that we're used to tags
  179. jonas’ Sam, but representing *lists* (e.g. of root CAs) in attributes is a PITA :)
  180. Sam Sure, but that wasn't the original point of contention. The original question was "should host/port be an attribute or an extension" and neither of those are lists that are difficult to represent.
  181. jonas’ Sam, having them as an element makes the "do TCP" extension more extensible though
  182. jonas’ that was my point for favouring an element
  183. qy TCP over XMPP? Does that mean you could REST over XMPP? Cause that means Homeserver over XMPP is possible
  184. Sam Why? You could leave the protocol exactly as is (eg. "tcp:host" attributes) and also add a <tcp2:rootca> element. Or you could add a <tcp><rootca> element, it doesn't matter if it's nested or not.
  185. Sam qy: see also https://xmpp.org/extensions/xep-0332.html
  186. jonas’ right
  187. Link Mauve “20:06:30 qy> Tldr it means the server always disco requests me, aiui”, you might receive a request, but the server might verify the hash of your response and throw it away if it doesn’t match.
  188. qy That's a thing? Bugger me sideways
  189. mac has joined
  190. pep. Sam, yeah exactly, I also think it doesn't matter, it's just an arbitrary choice
  191. qy Sam: Beautiful
  192. pep. Might look prettier or easier to understand. And these aren't at all subjective obviously /s :)
  193. Wojtek has left
  194. Wojtek has joined
  195. Link Mauve MattJ, “and a block-size, if given, is (currently) ignored.”, that’s illegal as per XEP-0047, this attribute is a MUST.
  196. jonas’ patches welcome?!
  197. pep. It could be specified that 'http://prosody.im/protocol/tcpproxy' ignores the MUST :)
  198. jonas’ I think you have +w on that repository ;)
  199. pep. And be done with it
  200. Link Mauve I do.
  201. xnamed has joined
  202. Wojtek has left
  203. Wojtek has joined
  204. goffi has joined
  205. homebeach has left
  206. Matrix Traveler (bot) has left
  207. Matrix Traveler (bot) has joined
  208. homebeach has joined
  209. spectrum has left
  210. spectrum has joined
  211. Link Mauve Hmm, XEP-0332 doesn’t mention anything about encodings, we know XMPP is UTF-8 but what if a HTTP server advertises text/plain;charset=utf-8 but returns non-UTF-8 as the content?
  212. rafasaurus has left
  213. 9lakes has left
  214. xnamed has left
  215. rafasaurus has joined
  216. xnamed has joined
  217. marmistrz has left
  218. marmistrz has joined
  219. jonas’ you'd have to inject Transfer-Encoding: base64 I guess
  220. xnamed has left
  221. doge has left
  222. marc0s has left
  223. marc0s has joined
  224. marc0s has left
  225. marc0s has joined
  226. xnamed has joined
  227. doge has joined
  228. rafasaurus has left
  229. raghavgururajan has joined
  230. emus has left
  231. rafasaurus has joined
  232. mac has left
  233. mac has joined
  234. Zash Oh it has https://xmpp.org/extensions/xep-0332.html#sect-idm45815412462064
  235. doge has left
  236. jubalh has left
  237. jubalh has joined
  238. Kev has left
  239. jgart has joined
  240. thomaslewis has joined
  241. thomaslewis has left
  242. emus has joined
  243. thomaslewis has joined
  244. goffi has left
  245. thomaslewis has left
  246. marc0s has left
  247. marc0s has joined
  248. kikuchiyo has joined
  249. marc0s has left
  250. marc0s has joined
  251. marc0s has left
  252. marc0s has joined
  253. marmistrz has left
  254. 9lakes has joined
  255. edhelas has left
  256. edhelas has joined
  257. Wojtek has left
  258. Wojtek has joined
  259. sonny has left
  260. jubalh has left
  261. mac has left
  262. Yagizа has left
  263. mac has joined
  264. marc0s has left
  265. marc0s has joined
  266. marc0s has left
  267. marc0s has joined
  268. Kev has joined
  269. Kev has left
  270. Wojtek has left
  271. Wojtek has joined
  272. xnamed I have a question about https://xmpp.org/extensions/xep-0045.html#disco-occupant What if a non-occupant - who has owner affiliation - queries room configuration or its affiliation lists? If this should be allowed, why not include something like <feature var='http://jabber.org/protocol/muc#owner'/> in the room disco info result when it's available for use?
  273. SouL has left
  274. SouL has joined
  275. Wojtek has left
  276. jubalh has joined
  277. thomaslewis has joined
  278. thomaslewis has left
  279. emus has left
  280. Wojtek has joined
  281. emus has joined
  282. sonny has joined
  283. Wojtek has left
  284. Wojtek has joined
  285. rafasaurus has left
  286. rafasaurus has joined
  287. rafasaurus has left
  288. Wojtek has left
  289. rafasaurus has joined
  290. rafasaurus has left
  291. rafasaurus has joined
  292. rafasaurus has left
  293. rafasaurus has joined
  294. rafasaurus has left
  295. sonny has left
  296. sonny has joined
  297. marc0s has left
  298. marc0s has joined
  299. dezant has left
  300. Pete has left
  301. Pete has joined
  302. rafasaurus has joined
  303. Pete has left
  304. Pete has joined
  305. dezant has joined
  306. kikuchiyo has left
  307. kikuchiyo has joined
  308. rafasaurus has left
  309. pulkomandy has left
  310. rafasaurus has joined
  311. kikuchiyo has left
  312. kikuchiyo has joined
  313. jgart has left
  314. jgart has joined
  315. Pete has left
  316. Pete has joined
  317. bung has left
  318. marc0s has left
  319. marc0s has joined
  320. al has joined
  321. pulkomandy has joined
  322. qy > Link Mauve wrote: > ...but the server might verify the hash of your response and throw it away if it doesn’t match alright, sorted now. I have to say, kind of a shitty behaviour to just discard the response with no indication if that is whats happening though
  323. qy Luckily didnt have to modify much overall
  324. qy Manual sorting :D
  325. mac has left
  326. mac has joined
  327. mac has left
  328. mac has joined
  329. jubalh has left
  330. mac has left
  331. mac has joined
  332. thomaslewis has joined
  333. thomaslewis has left
  334. rafasaurus has left
  335. mac has left
  336. mac has joined
  337. nephele has left
  338. rafasaurus has joined
  339. atomicwatch has left
  340. doge has joined
  341. dezant has left
  342. al has left
  343. thomaslewis has joined
  344. thomaslewis has left
  345. atomicwatch has joined
  346. kikuchiyo has left
  347. larma has left
  348. kikuchiyo has joined
  349. dezant has joined
  350. rafasaurus has left