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