XSF Discussion - 2018-02-19

  1. lskdjf has joined
  2. SamWhited has left
  3. jere has joined
  4. Dave Cridland has left
  5. lskdjf has joined
  6. Dave Cridland has left
  7. Dave Cridland has joined
  8. Dave Cridland has left
  9. Dave Cridland has joined
  10. ralphm has joined
  11. Dave Cridland has left
  12. Dave Cridland has left
  13. Zash has left
  14. lskdjf has joined
  15. tux has left
  16. tux has joined
  17. Dave Cridland has left
  18. lumi has left
  19. uc has joined
  20. efrit has left
  21. lskdjf has left
  22. moparisthebest has left
  23. Dave Cridland has left
  24. Dave Cridland has left
  25. jere has joined
  26. Guus has left
  27. SamWhited has joined
  28. SamWhited has joined
  29. SamWhited has left
  30. Guus has left
  31. Guus has left
  32. moparisthebest has joined
  33. rion has joined
  34. moparisthebest has joined
  35. Dave Cridland has left
  36. Maranda has left
  37. la|r|ma has joined
  38. suzyo has joined
  39. Maranda has joined
  40. uc has left
  41. uc has joined
  42. Yagiza has joined
  43. lskdjf has joined
  44. andy has left
  45. andy has joined
  46. la|r|ma has joined
  47. Dave Cridland has left
  48. Guus has left
  49. Dave Cridland has left
  50. moparisthebest has left
  51. moparisthebest has joined
  52. Dave Cridland has left
  53. Dave Cridland has left
  54. Guus has left
  55. andy has left
  56. suzyo has joined
  57. Guus has left
  58. Guus has left
  59. andy has joined
  60. suzyo has joined
  61. moparisthebest has joined
  62. Guus has left
  63. moparisthebest has joined
  64. Guus has left
  65. Neustradamus has left
  66. Neustradamus has joined
  67. tim@boese-ban.de has joined
  68. mimi89999 has left
  69. mimi89999 has joined
  70. uc has joined
  71. rion has left
  72. mimi89999 has joined
  73. uc has joined
  74. @Alacer has left
  75. @Alacer has joined
  76. Dave Cridland has left
  77. Dave Cridland has left
  78. Yagiza has left
  79. moparisthebest has joined
  80. Guus has left
  81. Dave Cridland has left
  82. moparisthebest has joined
  83. Guus has left
  84. Guus has left
  85. andy has left
  86. Dave Cridland has left
  87. moparisthebest has joined
  88. moparisthebest has joined
  89. Guus has left
  90. Guus has left
  91. daniel has left
  92. daniel has joined
  93. Yagiza has joined
  94. andy has joined
  95. Guus has left
  96. Dave Cridland has left
  97. Guus has left
  98. Guus has left
  99. goffi has joined
  100. SamWhited has joined
  101. Guus has left
  102. ralphm has joined
  103. andy has left
  104. Dave Cridland has left
  105. Dave Cridland has left
  106. andy has joined
  107. ralphm has left
  108. moparisthebest has joined
  109. moparisthebest has joined
  110. Dave Cridland has left
  111. ralphm has joined
  112. uc has joined
  113. SaltyBones has left
  114. SaltyBones has joined
  115. ralphm has left
  116. ralphm has joined
  117. uc has joined
  118. daniel has left
  119. daniel has joined
  120. Dave Cridland has left
  121. andy has left
  122. daniel has left
  123. daniel has joined
  124. andy has joined
  125. Guus has left
  126. Guus has left
  127. daniel has left
  128. daniel has joined
  129. valo has joined
  130. Dave Cridland has left
  131. Guus has left
  132. daniel has left
  133. daniel has joined
  134. Dave Cridland has left
  135. daniel has left
  136. daniel has joined
  137. Dave Cridland has left
  138. daniel has left
  139. daniel has joined
  140. jonasw anyone here at whom I can bounce an idea I had for ecaps2?
  141. jonasw (otherwise I’ll take that to the list, but from experience, I won’t get a lot of feedback there :/)
  142. Dave Cridland has left
  143. andy has left
  144. Zash How much context is needed?
  145. jonasw if you know how caps (XEP-0115) works, it’s probably fine
  146. Zash How much coffee is needed? :)
  147. jonasw uh, maybe a bit, but I’m not sure. I don’t drink coffee :-)
  148. Zash Shoot. What's the worst that can happen? :)
  149. jonasw ühah
  150. jonasw hah
  151. jonasw so I was wondering what if we don’t have clients inject the caps into the presence, but instead use a nonza/stream-level element to let the server know about the caps.
  152. Dave Cridland has left
  153. jonasw the server would then re-send presence and take care of injecting caps updates in presences.
  154. jonasw receiving entities would see the caps in presence as usual.
  155. jonasw this saves the client from re-sending (non-directed) presence when the caps change (server would re-broadcast)
  156. jonasw I literally just had the idea. I’m not 100% sure how the interaction with stream management would be.
  157. Dave Cridland has left
  158. jonasw (but probably it would be "re-send your caps to the server after resumption, unless you’re 100% sure your previous caps update came through")
  159. jonasw the rationale why this might be nicer for the client is that presence is already a rather complex beast, in the context of MUC, in the context of vcard avatars and possibly other things (if we want to integrate chat states into that for example)
  160. remko has joined
  161. Zash You could transmit your entire disco#info blob, then the server could do the caps/ecaps/magic for you
  162. Dave Cridland has left
  163. jonasw very interesting point
  164. jonasw and do all other sorts of interesting things with it even
  165. jonasw (e.g. what people proposed with publishing a subset/superset of all client features in a PEP node)
  166. Zash Would probably tie in nicely with some future client registration
  167. jonasw client registration?
  168. jonasw like, device keys?
  169. Zash The server having some idea of which clients you have.
  170. jonasw yes
  171. Zash Sounded like people wanted something in that direction.
  172. Guus has left
  173. Dave Cridland has left
  174. Zash jonasw: I think we should be careful with just throwing non-stanzas at everything
  175. jonasw an IQ would work just as well here
  176. Dave Cridland has left
  177. jonasw (I actually put some thought into nonza vs. message for server-originated pushes and there nonza was fine and semantically made more sense, so I just transferred that to client-originated pushes too; I might be wrong here)
  178. jonasw (I’m not sold on using nonzas)
  179. Dave Cridland has left
  180. Zash Caps are a property of what, exactly?
  181. jonasw the client.
  182. Dave Cridland has left
  183. jonasw (or server respectively)
  184. jonasw (entity.)
  185. Zash Not the stream itself.
  186. jonasw yeah
  187. jonasw probably makes sense to put them as IQs or something
  188. Zash I was thinking basically just disco#info in an iq-set would be nice and simple
  189. jonasw yeah
  190. Dave Cridland has left
  191. jonasw so clients wouldn’t have to calculate *their own* hashes anymore, but they might still want to calculate other peoples hashes and keep a cache.
  192. jonasw for directed presence, sending an "empty" directed presence would make the server inject caps as needed. is that a privacy issue?
  193. jonasw probably not, because who knows your resource can disco#info you anyways.
  194. Zash yup
  195. jonasw cool
  196. jonasw I hear a namespace bump rolling along.
  197. jonasw or maybe not.
  198. jonasw gotta think about that
  199. Zash New namespace, disco#push or something?
  200. moparisthebest has joined
  201. jonasw nah, I need to think whether caps2 itself needs a bump for this. But it might actually not.
  202. Zash Does ecaps2 replace disco?
  203. jonasw no
  204. jonasw not entirely I think
  205. Zash caps is a separate thing right
  206. jonasw it might save you a lot of disco#info-ing, but you still need to support xep-0030
  207. jonasw and then I’ll need to make an implementation in prosody to show that it works :D
  208. Zash PoC all the things!
  209. jonasw maybe I’ll sink my afternoon in that.
  210. Ge0rG jonasw: awesome idea, I'm all for making the client dumber again
  211. Ge0rG jonasw: beware directed MUC presences though, they are broken already.
  212. jonasw Ge0rG, what’dya mean?
  213. jonasw server wouldn’t resend directed automatically, client needs to do that (server just injects caps hashes)
  214. Ge0rG jonasw: I _think_ I sent that to standards recently, but can't find. When the MUC changes your nickname, your server will later send your "directed" unavailable presence to the old nickname.
  215. jonasw yeah, heard about that
  216. Ge0rG jonasw: shouldn't the server resend all directed presences on a caps change?
  217. Zash Yeah, the MUC changing your nickname causes all sorts of headaches
  218. jonasw Ge0rG, I looked at how {xep 0398} does it, and it doesn’t resend directed either
  219. Bunneh Ge0rG: User Avatar to vCard-Based Avatars Conversion (Standards Track, Experimental, 2018-01-25) See: https://xmpp.org/extensions/xep-0398.html
  220. Ge0rG jonasw: maybe it's just an oversight by the XEP authors?
  221. Ge0rG it would make sense to resend.
  222. Dave Cridland has left
  223. jonasw maybe; we should ask daniel about this
  224. jonasw maybe; we should ask daniel about this ^
  225. Zash jonasw: Nothing says you can't have the server query disco#info like normal and then generate caps and ecaps2 for it.
  226. Zash For legacy clients etc
  227. jonasw Zash, true; I’m not sure why you’re mentioning that though.
  228. Zash Thinking out loud
  229. jonasw (and it would require polling)
  230. jonasw ok
  231. Ge0rG it would add some nastyness into the protocol flow
  232. Zash Prosody already does it, but discards the response, save for the PEP +notify items
  233. Ge0rG 1. client sends online presence 2. server delays outbound presence, asks client for disco#info instead 3. the client sends directed presences all around 4. eventually, the client responds to disco#info 5. the server can now inject and forward
  234. Dave Cridland has left
  235. remko has left
  236. remko has joined
  237. Ge0rG is +notify part of disco#info?
  238. Zash Ge0rG: Yes
  239. Ge0rG Zash: which question was that a response to?
  240. jonasw I wonder if we should be stripping +notify from things sent to peers while we’re at it.
  241. Ge0rG has left
  242. Zash Ge0rG: +notify goes in disco#info
  243. jonasw but probably not.
  244. Zash Can we forklift PEP into being account based that way?
  245. Zash As in, subs are between accounts, not between remote account and specific resources
  246. Ge0rG wasn't there a discussion of making PEP account-based just some days ago, on this MUC?
  247. jonasw I must’ve missed it
  248. jonasw Zash, it could be a good first step with the superset thing
  249. jonasw would probably require an update to {xep 0163}
  250. Bunneh jonasw: Personal Eventing Protocol (Standards Track, Draft, 2010-07-12) See: https://xmpp.org/extensions/xep-0163.html
  251. uc has joined
  252. Dave Cridland has left
  253. Dave Cridland has left
  254. Ge0rG Zash: what's up with Bunneh? I'm missing it sorely.
  255. Zash Bunneh: ping
  256. Bunneh Zash: pong
  257. Zash Bunneh: version Ge0rG
  258. Bunneh Zash: Ge0rG is running yaxim version 0.9.2-95-gcab21a3 on Android
  259. Ge0rG That's a lie.
  260. jonasw Ge0rG, your statement is confusing to me: https://sotecware.net/images/dont-puush-me/v7RTW5gsnGjnTE5G6QahCIPsruzqV3-1IRISifpDBRI.png
  261. Zash Ge0rG: Stanza reply id duplication causing you problems?
  262. Ge0rG Zash: it won't join my MUC.
  263. Ge0rG jonasw: why are you quoting by image? :P
  264. jonasw Ge0rG, that is a very good question I can’t really answer
  265. Dave Cridland has left
  266. jonasw I guess that’s what happens when you have a scrot-scp-xclip pipeline bound to something which is close to a hotkey
  267. Ge0rG I don't even want to know what "scrot" is the abbreviation for.
  268. jonasw Ge0rG, it’s not an abbreviation, it’s the name of a tool.
  269. jonasw I find it confusing, too.
  270. Ge0rG that's what she said?
  271. jonasw cf. http://manpages.ubuntu.com/manpages/precise/man1/scrot.1.html
  272. jonasw argh
  273. jonasw I’ll just head out now :P
  274. Zash Ge0rG: I'm going to guess that it thinks that it is joined. Or doesn't support mediated invites. Or both.
  275. jonasw see you later
  276. Ge0rG Zash: can't you kick its lazy bottocks?
  277. Dave Cridland has left
  278. blabla has left
  279. Zash I can update its server
  280. Ge0rG If that will make it rejoin my MUC?
  281. Bunneh has left
  282. Bunneh has joined
  283. Zash Setting up prosody-trunk (1nightly844-1~trusty) ... prosody stop/waiting prosody start/running, process 1714
  284. efrit has joined
  285. Dave Cridland has left
  286. Dave Cridland has left
  287. Guus has left
  288. moparisthebest has joined
  289. Dave Cridland has left
  290. Dave Cridland has left
  291. @Alacer has left
  292. @Alacer has joined
  293. Dave Cridland has joined
  294. jubalh has joined
  295. Dave Cridland has left
  296. Dave Cridland has left
  297. Dave Cridland has left
  298. Dave Cridland has left
  299. Dave Cridland has left
  300. Dave Cridland has joined
  301. Dave Cridland has left
  302. Dave Cridland has left
  303. Guus has left
  304. andrey.g has left
  305. efrit has left
  306. jubalh has left
  307. valo has joined
  308. Ge0rG When doing disco#info on my own server, how am I supposed to differentiate a MUC service from an IRC transport?
  309. Zash Are you supposed to at all?
  310. Ge0rG I'm sure it won't end up well if I try to create a private MUC on biboumi.
  311. Zash Uh, fun
  312. Ge0rG Wasn't there a disco#info item telling a client that it may create new MUCs on that service?
  313. Zash I'm not aware of such a feature
  314. Zash Not that many features depend on who asks
  315. Zash Or?
  316. Ge0rG ...that it is possible to create new MUCs on this service.
  317. Ge0rG XMPP is full of fail.
  318. Dave Cridland has left
  319. Dave Cridland has left
  320. Guus has left
  321. Zash You could look for the feature "http://jabber.org/protocol/muc#unique"
  322. Dave Cridland has left
  323. Zash It's pretty useless tho
  324. Dave Cridland has left
  325. Zash It would imply that it's possible to create randomly named MUCs... for someone... maybe
  326. Ge0rG Zash: that's not part of 45?
  327. Zash -xep 307
  328. Bunneh Zash: Unique Room Names for Multi-User Chat (Standards Track, Deferred, 2011-11-10) See: https://xmpp.org/extensions/xep-0307.html
  329. Zash It was broken out IIRC
  330. Zash The Prosody implementation just returns an UUIDv4
  331. Ge0rG Ah, it's type=irc as opposed to type=text. Yay.
  332. Zash How is irc not text?
  333. Zash And how do you know that room creation is not restricted to admins?
  334. Ge0rG I can't.
  335. Ge0rG I can't fix all problems of XMPP. Not today.
  336. Maranda It's all an iconian plot I tell you. 🙄🖖
  337. mathieui Ge0rG, but you have to
  338. Ge0rG mathieui: maybe if somebody will pay me.
  339. Guus has left
  340. daniel has left
  341. daniel has left
  342. lumi has joined
  343. Seve/SouL has joined
  344. Seve/SouL has joined
  345. Dave Cridland has left
  346. Dave Cridland has left
  347. jubalh has joined
  348. jubalh has left
  349. Ge0rG has left
  350. jubalh has joined
  351. ralphm has joined
  352. Guus Ge0rG: do you accepty payment in the form of stickers?
  353. daniel has left
  354. Ge0rG Guus: I'll ask my landlord.
  355. Ge0rG TBH I never considered putting stickers onto my Laptop, my car or any other item. Not sure why.
  356. Guus Ge0rG: Cut out the middle man! Stickers make for nice decoration for inside a cartboard box under a bridge!
  357. Guus Ge0rG: same here.
  358. Ge0rG Guus: great idea! But living under the bridge isn't free either.
  359. Zash Extract tolls from passing goats?
  360. Ge0rG I could probably obtain sufficient amounts of food by dumpster diving. But how should I handle the -5°C temperatures
  361. daniel has left
  362. jonasw Ge0rG, mine bitcoin on your laptop
  363. jonasw oh wait.
  364. Ge0rG has left
  365. Guus I like how we as a community are coming together to tackle both Ge0rG's residential issues as well as all of XMPPs problems.
  366. ralphm has joined
  367. moparisthebest has joined
  368. Dave Cridland has left
  369. Dave Cridland has left
  370. Dave Cridland has left
  371. Dave Cridland has left
  372. Ge0rG Guus: I'm very grateful for that effort.
  373. Dave Cridland has left
  374. Ge0rG ,oO( does "being grateful" actually mean "being full of grates"? )
  375. jubalh has left
  376. Kev Full of gratitude, I think, but your understanding could be good too.
  377. Ge0rG In that case I prefer to be gratitudeful, thanks.
  378. Guus has left
  379. Zash Hmm, gratäng?
  380. Dave Cridland has left
  381. daniel has left
  382. blabla has joined
  383. flow jonasw, I'm not sure if client implementations would become easier. As far as I remember, implementing caps in Smack was not really challenging.
  384. Guus has left
  385. flow besides the i;octet collation, which is possilby underspecified in xep115 (but thankefully not in xep390)
  386. Zash I would be happy if, when I use `clix raw` and send presence, it doesn't instantly drown in so many disco#info queries and other stuff that the terminal crashes.
  387. Zash (rlwrap doesn't always handle syntax highlighting all that well)
  388. jubalh has joined
  389. flow Are there so many implementations that fetch disco#info unconditionally after a caps update? Are impls supposed to do that?
  390. flow Zash, what's clix?
  391. jonasw Zash: thats separate though, we can have query interception as-is
  392. Kev Command-line XMPP.
  393. Kev But yes, I'd expect clients to disco when they see a new caps.
  394. flow Why?
  395. Zash flow: http://code.matthewwild.co.uk/clix/
  396. Kev To know what features are supported by contacts.
  397. jonasw flow: decoupling caps from presence has the advantage of being able to use caps without presence
  398. flow jonasw, is it really caps that you decouple, not disco#info?
  399. Link Mauve “15:54:05 flow> jonasw, what do you think about the xep390 optimization to move the disco#info result from the client to the server?”, I have an experimental module doing that for 0115, caching the disco#info and the 0115 node in the session table, and answering iqs requesting it automatically.
  400. jonasw and if we push disco#info and let the server deal with it, thats nice I think
  401. Link Mauve A few things to fix and it should end up in prosody-modules.
  402. jonasw also I'm on mobile
  403. jonasw gotta go
  404. flow Kev, but why do you need to know the features right after the caps update? And not, let's say, when you show the contact list in the GUI?
  405. flow Link Mauve, so xep115 § 8.4?
  406. Link Mauve flow, hmm, no, I don’t change anything about what the client advertise, I just request the disco#info when its <c/> changes and answer iqs from external entities instead of routing them to the user.
  407. Link Mauve I’m not sure what stripping it would achieve.
  408. Link Mauve Other than increase the amount of requests from other entities.
  409. Link Mauve And prevent them from using their normal cache mechanism.
  410. flow Link Mauve, sorry, I thought that was the xep115 counterpart of xep390 § 6.4 without closing reading it
  411. flow So you do xep390 § 6.4 for xep115?
  412. Link Mauve flow, yes, except I forgot the third point, will fix.
  413. Link Mauve I’ll add a mention of that.
  414. Link Mauve And soon will add support for 0390 too.
  415. valo has joined
  416. jonasw Link Mauve: sweet! what do you think of the proposed model of pushing disco#info from clients?
  417. Steve Kille has joined
  418. jonasw so that the server handles hash calculation and presence broadcast?
  419. Link Mauve jonasw, would avoid one roundtrip, but it would also require every client to change, so I’m not sure it’s really useful.
  420. Link Mauve Well, both clients and servers.
  421. jonasw Link Mauve: we need to change clients for 390 anyways 😺
  422. jonasw (and servers)
  423. Link Mauve Uh, why?
  424. ralphm has joined
  425. Link Mauve I just had the idea to let the server compute 0390 and insert it in the presence if the client only had 0115.
  426. jonasw Link Mauve: because they need to emit/process 390 hashes instead of / in addition to 115 hashes.
  427. andy has joined
  428. Link Mauve That would immediately increase adoption and usefulness.
  429. jonasw yeah
  430. jonasw indeed
  431. jonasw I'm working on an update to 390 btw. I'll add that.
  432. Link Mauve So I’ll continue this Prosody module in that direction, and you fix all of the clients in the meantime. :)
  433. jonasw I won't fix pidgin 😼
  434. Ge0rG jonasw: but you could burn it with fire.
  435. jonasw Ge0rG: having the server re-send directed presence to MUCs also has interesting isszes with the proposed no-join (since errors need to be handled) and possibly passwords etc.
  436. valo has joined
  437. jonasw I think thats a can of worms I don't want to open.
  438. jonasw gotta go agaib
  439. jonasw *again
  440. Guus has left
  441. jubalh has left
  442. marc has joined
  443. Dave Cridland has left
  444. jere has joined
  445. daniel has left
  446. daniel has left
  447. Dave Cridland has left
  448. daniel has left
  449. ralphm has joined
  450. Guus has left
  451. Dave Cridland has left
  452. rion has left
  453. rion has joined
  454. Dave Cridland has left
  455. rion has left
  456. Dave Cridland has left
  457. Dave Cridland has left
  458. ralphm has joined
  459. la|r|ma has joined
  460. Seve/SouL has joined
  461. Seve/SouL has joined
  462. Guus has left
  463. stefandxm has left
  464. lumi has left
  465. andy has left
  466. andy has joined
  467. blabla has left
  468. Guus has left
  469. rion has joined
  470. Maranda has joined
  471. lskdjf has joined
  472. suzyo has joined
  473. Kev has left
  474. andy has left
  475. intosi has left
  476. lskdjf has joined
  477. lskdjf has joined
  478. Holger has left
  479. Dave Cridland has left
  480. suzyo has joined
  481. Seve/SouL has left
  482. Seve/SouL has joined
  483. blabla has joined
  484. moparisthebest has joined
  485. lskdjf has joined
  486. moparisthebest has joined
  487. intosi has joined
  488. andy has joined
  489. Fabian has joined
  490. ralphm has joined
  491. intosi has left
  492. intosi has joined
  493. SaltyBones has left
  494. SaltyBones has joined
  495. stefandxm has joined
  496. ralphm has left
  497. andy has left
  498. andy has joined
  499. jonasw re
  500. Ge0rG has left
  501. Alex has joined
  502. ralphm has joined
  503. jonasw Link Mauve, so, others (I think the MIX folks) have already indicated interest in pre-presence disco#info from the client. XEP-0390 actually already specifies that with an IQ (even though that IQ only carries caps instead of disco#info). the change would be to make clients always use the IQ instead of presence to send caps to their server (and the server takes care of injecting caps in presence and re-broadcasting non-directed presence when caps change)
  504. jonasw Zash proposed to change the IQ to actually contain the whole disco#info data instead of only the caps, which I think is neat. It allows the server to do all kinds of interesting things, like do the 115+390 optimization without having to ask the client for disco#info if it doesn’t have the hashes in the cache.
  505. la|r|ma has left
  506. andy has left
  507. stefandxm has left
  508. Zash Wasn't there a proposal for rolling auth, resource binding and some session initialization into one transaction? Maybe something Kev or Dave talked about
  509. stefandxm has joined
  510. Ge0rG has joined
  511. stefandxm has left
  512. stefandxm has joined
  513. Ge0rG has left
  514. Ge0rG has left
  515. jere has joined
  516. Ge0rG has left
  517. Ge0rG has left
  518. SaltyBones has left
  519. SaltyBones has joined
  520. stefandxm has left
  521. stefandxm has joined
  522. remko has joined
  523. Ge0rG has left
  524. Ge0rG has left
  525. remko has joined
  526. Guus has left
  527. remko has joined
  528. remko has joined
  529. stefandxm has left
  530. Guus has left
  531. stefandxm has joined
  532. Ge0rG has left
  533. Ge0rG has left
  534. lskdjf has joined
  535. moparisthebest has joined
  536. ralphm has joined
  537. Ge0rG has left
  538. daniel has left
  539. Ge0rG has left
  540. Ge0rG has left
  541. Ge0rG has left
  542. Dave Cridland has left
  543. stefandxm has left
  544. stefandxm has joined
  545. moparisthebest has joined
  546. la|r|ma has joined
  547. lskdjf has joined
  548. andy has joined
  549. stefandxm has left
  550. stefandxm has joined
  551. andrey.g has joined
  552. andrey.g has joined
  553. daniel has left
  554. moparisthebest has joined
  555. Guus has left
  556. moparisthebest has joined
  557. daniel has left
  558. jere has joined
  559. andy has left
  560. jere has left
  561. jere has joined
  562. ralphm has joined
  563. Dave Cridland has left
  564. Ge0rG has left
  565. andy has joined
  566. andy has left
  567. vanitasvitae has left
  568. mathieui https://opkode.com/blog/xmpp-chat-badge/ this is neat (from jcbrand)
  569. Zash Now taking bets on how long it would take to make that as a prosody module
  570. Guus has left
  571. Ge0rG has left
  572. stefandxm has left
  573. stefandxm has joined
  574. andrey.g has joined
  575. Maranda math.random(100)
  576. Maranda Bunneh¡! 🤣
  577. vanitasvitae has left
  578. Guus has left
  579. Guus ah, we have that for user presence, but not mucs. That's a nice idea
  580. Guus I shall shamelessly copy that.
  581. Alex has left
  582. stefandxm has left
  583. stefandxm has joined
  584. Fabian has left
  585. valo has left
  586. Kev has left
  587. valo has joined
  588. daniel has left
  589. stefandxm has left
  590. stefandxm has joined
  591. Guus has left
  592. Link Mauve has left
  593. daniel has left
  594. daniel has left
  595. daniel has joined
  596. andy has joined
  597. Fabian has joined
  598. SaltyBones has left
  599. SaltyBones has joined
  600. Guus has left
  601. andy has left
  602. jubalh has joined
  603. jubalh has left
  604. jubalh has left
  605. andy has joined
  606. efrit has joined
  607. stefandxm has left
  608. stefandxm has joined
  609. Fabian has left
  610. Alex has joined
  611. jjrh has left
  612. andy has left
  613. jubalh has joined
  614. Link Mauve has joined
  615. valo has joined
  616. andy has joined
  617. valo has joined
  618. Kev has left
  619. mimi89999 has joined
  620. la|r|ma has joined
  621. lskdjf has joined
  622. stefandxm has left
  623. stefandxm has joined
  624. tim@boese-ban.de has left
  625. stefandxm has left
  626. stefandxm has joined
  627. daniel has left
  628. stefandxm has left
  629. stefandxm has joined
  630. Dave Cridland has left
  631. efrit has left
  632. Fabian has joined
  633. jjrh has left
  634. Fabian has left
  635. Fabian has joined
  636. jjrh has left
  637. la|r|ma has left
  638. la|r|ma has joined
  639. jjrh has left
  640. jjrh has left
  641. stefandxm has left
  642. stefandxm has joined
  643. Kev References to pubsub items. Thoughts?
  644. Kev We're about to allow references to FDP forms in Swift, so we want a reference to a pubub item.
  645. jjrh has left
  646. goffi Kev: I would like to reference pubsub items for mentions in blog post too
  647. jjrh has left
  648. goffi Kev: I though a super simplified xpath compatible syntax would be useful
  649. goffi +t
  650. Kev We could just do this as any other URI reference, pointing at the pubsub item, but if we did a specialist 'pubsub' reference we could also include the namespace.
  651. Syndace has joined
  652. goffi Kev: URI is not enough, we need to know if we reference text or XHTML body
  653. Kev I don't follow.
  654. intosi goffi: for pubsub?
  655. goffi intosi: for microblog items
  656. intosi But that's pointing to stuffs inside a pubsub item payload, which is probably beyond what Kev;s intending here.
  657. Kev I'm talking about just pointing to a pubsub item.
  658. goffi intosi: yes it's pointing inside payload, that's why I'm mentioning simplified xpath
  659. goffi OK
  660. goffi so that's an other issue I'm talking about then.
  661. jjrh has left
  662. Kev I think so, yes.
  663. jjrh has left
  664. jubalh has left
  665. lumi has joined
  666. lumi has left
  667. Lance has joined
  668. daniel has left
  669. stefandxm has left
  670. stefandxm has joined
  671. intosi has left
  672. SamWhited has joined
  673. uc has joined
  674. uc has joined
  675. Guus has left
  676. daniel has left
  677. valo has joined
  678. Tobias has joined
  679. waqas has joined
  680. SamWhited Speaking of xpath, does anyone do some form of stanza matching that doesn't involve xpath? If so, what do you do? I've been struggling for ages to come up with a way to match handlers in an XMPP library that I don't end up despising and throwing out.
  681. waqas SamWhited: Seen Prosody's approach?
  682. SamWhited waqas: I must have used it when writing plugins, but I can't for the life of me think what it is?
  683. remko has left
  684. waqas For each stanza, we fire some events on our event bus. Event names like "iq", "iq/{xmlns:tagname}", etc.
  685. Guus has left
  686. waqas Because Prosody is a server, we actually do "iq/{bare|full|self|host}/…", etc, since the target JID's nature actually matters for server routing.
  687. SamWhited ah yes, I remember. What if, for example, multiple things listen for an IQ and both try to reply to it?
  688. Zash iq/{host,bare,full}, iq-{get,set}/{host,bare,full}/xmlns:name
  689. waqas Our event bus is a priority queue, and the first handler to indicate it has handled stops the event chain.
  690. SamWhited *nods* that makes good sense
  691. Dave Cridland has left
  692. waqas Handlers can be registered with priority, so e.g., a privacy list handler may want to have a higher priority than the actual routing. Default stuff is priority 0.
  693. valo has joined
  694. SamWhited I actually had something similar to that a while back (except it was chains of function calls similar to the HTTP middleware pattern, and any of them could short circuit the pattern). I can't remember why I didn't actually end up using it now though…
  695. SamWhited If multiple things register with the same priority what ends up happening?
  696. Zash Random order basically.
  697. Dave Cridland has left
  698. SamWhited I think the reason I didn't do something similar is that I needed to match initially on the IQ start element token to route to the IQ handler chain, but then in there I needed to match on the payload, but I didn't have a good way to pass both that token and the stanza start token on.
  699. SamWhited But maybe I should give up and just always decode the entire IQ as soon as I receive the start token and pass a representation of the entire thing down through the chain
  700. waqas We just have mod_iq hook the top-level IQ event, and it then fires the sub-event :)
  701. jonasw FWIW, aioxmpp lets you match IQs requests by payload (only namespace+localname essentially) and get vs. set
  702. lumi has joined
  703. Zash Prosody would parse the entire stanzas before fireing events for them
  704. jonasw that, too
  705. daniel has left
  706. waqas Full xpath is overkill for XMPP routing
  707. jonasw yes
  708. Zash At least in a server
  709. SamWhited I suppose I'll have to do that, right now my handlers look something like: HandleXMPP(xmlstream.TokenReadWriter, *xml.StartElement)
  710. waqas SamWhited: Are you trying to avoid parsing into a DOM immediately?
  711. jonasw for things like pubsub where you’d want to match on deeper things, the pubsub service actually eats all pubsub-related things from the stream and emits its own events
  712. SamWhited waqas: yah, it's a tad bit more expensive so I was hoping to do the match and decide if I need to do it or not first, but I'm starting to think there's no good way to do that
  713. edhelas https://instantdomainsearch.com/articles/streaming-json-jsons/
  714. waqas SamWhited: I'd advise against it. The very minor speedup isn't worth the increased code complexity and mental overhead, except for very selected pieces of software where you must have every fraction of perf.
  715. waqas And you are parsing the whole thing anyway, the DOM cost isn't actually much (though non-zero, hence my experiments with in-place alloc-free DOM construction).
  716. suzyo has joined
  717. Holger has left
  718. SamWhited Yah, I say "parsing" but that's not actually the expensive part since I have to do that anyways, it's allocating a place to store some generic representation of it that's expensive.
  719. SamWhited I actually don't have a decent way to represent a generic blob of XML either, but that's not the end of the world, I've written one for the (terrible) xml library I'm using, so I could probably copy/paste that until it gets merged upstream.
  720. waqas What I mean is that that allocation is a fairly small fraction of the allocation that's happening anyway in your XML parser. Every element name, attribute name, attribute value, etc is causing at least one allocation.
  721. SamWhited It's true; I like the idea of being able to swap my inefficient XML library out for something a bit better later though and not have my code be the bottleneck
  722. waqas Just give in and refactor later. Bets on it not happening anytime soon? :)
  723. SamWhited Yah, that's probably a good idea. Maybe I'll try the middleware-style approach again and then if I can't make that work in a reasonable way fall back to parsing the entire stanza up front.
  724. waqas The reason why I haven't focused too much on it is that it simply isn't the bottleneck. In Prosody, I can do 100k stanzas/sec on this old macbook. And profiling does not put memory allocation as being item #1.
  725. Zash The string interning Lua does probably helps a fair bit
  726. waqas (standard microbenchmark disclaimers apply)
  727. Lance has left
  728. waqas Zash: No, those don't save us. While it has a few tricks, expat is doing many allocations.
  729. Guus has left
  730. waqas In our case, the networking stack is bottleneck #1 (including the kernel, luasocket and net.server), the whole parsing stage (expat + DOM construction) is #2, serialization is #3. All this for a very simple full JID to full JID IQ. Doesn't change much for other stanza types, except stanzas that cause broadcasts and IO are complex.
  731. SamWhited Right now for me parsing JIDs is the most expensive part of the stack, but I've gotten that down to be fairly quick (especially if the JIDs mostly end up being ascii)
  732. waqas Turn on any IO activity (MAM, logging, etc), and boom, it suddenly overshadows everything else combined
  733. Zash Heh, like debug logging
  734. Ge0rG Debug logging is a fraction of my I/O, compared to gazillions of chatstates in MAM.
  735. SamWhited In a former life though parsing the token stream into some form of usable object was very expensive though, and I'd like to shoot for that sort of scale. I can't do it right now because of the XML library, but it would be nice to be able to do it if I were to swap that out in the future.
  736. Zash I'm pretty sure most of my overhead while dev'ing is the drawing of syntax-highlighted stanzas in X
  737. Kev Overhead for clients and servers is completely different.
  738. Kev The most expensive thing Swift does is rendering a roster.
  739. Kev Well, s/rendering/constructing and rendering/
  740. Ge0rG If I were start today, I'd go with some dynamic language that has primitives to convert between objects and their stream representation, and ignore performance.
  741. waqas Kev: That's very true. And many clients do synchronous UI updates. Gajim and others do very badly when a bunch of stanzas show up..
  742. Ge0rG ...and then end up with a situation where remote entities can override my objjects' metadata pointers.
  743. SamWhited Indeed; luckily I'm not doing any of that, but I do get frustrated when Gajim completely locks up for a minute or so during the initial presence flood on a big roster
  744. Kev Swift does synchronous UI updates, but each one is injected into the UI's event loop individually, so unless the UI framework (Qt) is being daft, you'd need one very heavy stanza to freeze the UI.
  745. valo has joined
  746. lovetox has joined
  747. stefandxm has left
  748. Lance has left
  749. SamWhited Pushed up my current experiment which didn't end up working out, in case anyone's interested: https://godoc.org/mellium.im/xmpp/mux
  750. SamWhited The idea being that you match on the start token and could nest the multiplexers, but in practice you always need the top level stanza's information in whatever handler ends up replying.
  751. Dave Cridland has left
  752. Dave Cridland has left
  753. moparisthebest hmm mux was the name I was rooting for as the mix replacement people actually implement to replace muc with
  754. SamWhited oh yah, I would probably be sad if I called this package that and then ended up wanting to implement that later. Maybe "router" would have been a better name for this one. Oh well, it will end up being deleted anyways.
  755. tux has joined
  756. Kev has left
  757. Lance has left
  758. suzyo has joined
  759. Kev has left
  760. valo has joined
  761. jubalh has joined
  762. Lance has joined
  763. stefandxm has joined
  764. Dave Cridland has left
  765. valo has left
  766. Lance has left
  767. SamWhited has left
  768. SamWhited has left
  769. valo has joined
  770. Dave Cridland has left
  771. Dave Cridland has left
  772. waqas has left
  773. jubalh has left
  774. jere has joined
  775. Guus has left
  776. Tobias has joined
  777. Guus has left
  778. waqas has joined
  779. waqas has left
  780. valo has joined
  781. waqas has joined
  782. suzyo has joined
  783. Dave Cridland has left
  784. valo has joined
  785. Guus has left
  786. Zash has left
  787. Ge0rG has left
  788. rion has left
  789. daniel has left
  790. rion has joined
  791. jubalh has joined
  792. Yagiza has left
  793. jonasw has left
  794. Ge0rG has left
  795. @Alacer has left
  796. Fabian has left
  797. marc has left
  798. Guus has left
  799. Lance has left
  800. la|r|ma has left
  801. la|r|ma has joined
  802. jubalh has left
  803. vanitasvitae has left
  804. daniel has left
  805. Dave Cridland has left
  806. moparisthebest has left
  807. Guus has left
  808. Dave Cridland has left
  809. Dave Cridland has left
  810. Dave Cridland has left
  811. valo has joined
  812. ralphm has joined
  813. valo has joined
  814. Dave Cridland has left
  815. Guus has left
  816. suzyo has left
  817. suzyo has joined
  818. Tobias has joined
  819. Dave Cridland has left
  820. SamWhited has left
  821. Dave Cridland has left
  822. Dave Cridland has left
  823. Ge0rG has left
  824. Dave Cridland has left
  825. Ge0rG has left
  826. Ge0rG has left
  827. Alex has left
  828. Yagiza has joined
  829. Alex has joined
  830. ralphm has joined
  831. Dave Cridland has left
  832. Dave Cridland has left
  833. Dave Cridland has left
  834. ralphm has joined
  835. Dave Cridland has left
  836. daniel has left
  837. Dave Cridland has left
  838. Ge0rG has left
  839. Dave Cridland has left
  840. suzyo has joined
  841. Dave Cridland has left
  842. Dave Cridland has joined
  843. Dave Cridland has left
  844. Dave Cridland has joined
  845. Dave Cridland has left
  846. Ge0rG has left
  847. Dave Cridland has joined
  848. lskdjf has joined
  849. Seve/SouL has left
  850. Guus has left
  851. Guus has left
  852. Seve/SouL has left
  853. Seve/SouL has joined
  854. Dave Cridland has left
  855. jonasw has left
  856. Fabian has joined
  857. valo has joined
  858. Tobias has joined
  859. moparisthebest has left
  860. Dave Cridland has left
  861. valo has joined
  862. ralphm has joined
  863. blabla has joined
  864. lumi has left
  865. lumi has joined
  866. zinid has joined
  867. rion has left
  868. lumi has joined
  869. zinid has left
  870. Dave Cridland has left
  871. blabla has joined
  872. la|r|ma has joined
  873. winfried has left
  874. waqas has left
  875. Dave Cridland has left
  876. lskdjf has joined
  877. Dave Cridland has left
  878. Yagiza has left
  879. ralphm has joined
  880. ralphm has joined
  881. suzyo has joined
  882. Ge0rG has joined
  883. suzyo has left
  884. suzyo has joined
  885. Dave Cridland has left
  886. daniel has left
  887. valo has joined
  888. Fabian has left
  889. daniel has left
  890. valo has joined
  891. daniel has joined
  892. jubalh has joined
  893. suzyo has joined
  894. daniel has left
  895. daniel has joined
  896. Tobias has joined
  897. daniel has left
  898. daniel has joined
  899. Ge0rG has left
  900. daniel has left
  901. daniel has joined
  902. Alex has left
  903. Ge0rG has left
  904. Dave Cridland has left
  905. Alex has joined
  906. blabla has left
  907. Dave Cridland has left
  908. blabla has joined
  909. Ge0rG has left
  910. winfried has joined
  911. la|r|ma has joined
  912. Dave Cridland has left
  913. Guus has left
  914. Dave Cridland has left
  915. Dave Cridland has left
  916. Ge0rG has left
  917. SaltyBones has left
  918. Guus has left
  919. Ge0rG has left
  920. Tobias has left
  921. Dave Cridland has left
  922. Dave Cridland has left
  923. ralphm has joined
  924. goffi has left
  925. Alex has left
  926. ralphm has left
  927. Dave Cridland has left
  928. moparisthebest has joined
  929. la|r|ma has joined
  930. ralphm has joined
  931. Guus has left
  932. Dave Cridland has left
  933. Guus has left
  934. efrit has joined
  935. Dave Cridland has left
  936. efrit has left
  937. Dave Cridland has left
  938. Tobias has left
  939. Ge0rG has left
  940. Dave Cridland has left
  941. jubalh has left
  942. Ge0rG has left
  943. jjrh has left
  944. valo has left
  945. Ge0rG has left
  946. jjrh has left
  947. jjrh has left
  948. Dave Cridland has left
  949. Ge0rG has left
  950. jubalh has left
  951. Dave Cridland has left
  952. Ge0rG has left
  953. Ge0rG has joined
  954. Dave Cridland has left
  955. jubalh has joined
  956. Dave Cridland has left
  957. Ge0rG has joined
  958. Ge0rG has left
  959. vanitasvitae has left
  960. daniel has left
  961. daniel has joined
  962. jjrh has left
  963. Dave Cridland has left
  964. Ge0rG has left
  965. Dave Cridland has left
  966. Dave Cridland has left
  967. Dave Cridland has left
  968. Guus has left
  969. Dave Cridland has left
  970. Dave Cridland has left
  971. Tobias has left