XSF Discussion - 2017-12-11


  1. lskdjf has joined
  2. efrit has joined
  3. Holger has left
  4. SamWhited has left
  5. jjrh has left
  6. jjrh has left
  7. jjrh has left
  8. la|r|ma has joined
  9. lumi has left
  10. lskdjf has joined
  11. Zash has left
  12. Tobias has joined
  13. Tobias has joined
  14. jjrh has left
  15. jjrh has left
  16. jjrh has left
  17. jjrh has left
  18. jjrh has left
  19. jere has joined
  20. jere has joined
  21. jjrh has left
  22. arc has left
  23. arc has joined
  24. tux has joined
  25. arc has left
  26. arc has joined
  27. sonny has left
  28. sonny has joined
  29. jere has joined
  30. la|r|ma has joined
  31. jere has joined
  32. efrit has left
  33. sezuan has left
  34. ralphm has joined
  35. la|r|ma has joined
  36. arc has left
  37. arc has joined
  38. arc has left
  39. arc has joined
  40. efrit has joined
  41. blabla has joined
  42. jere has joined
  43. uc 🤦‍♀️
  44. efrit has left
  45. efrit has joined
  46. efrit has left
  47. efrit has joined
  48. efrit has left
  49. mimi89999 has left
  50. uc has left
  51. uc has left
  52. mimi89999 has joined
  53. mimi89999 has joined
  54. uc has joined
  55. SamWhited has left
  56. efrit has joined
  57. efrit has left
  58. zinid has joined
  59. efrit has joined
  60. marc has joined
  61. arc has left
  62. arc has joined
  63. zinid has left
  64. zinid has joined
  65. arc has left
  66. arc has joined
  67. jmpman has left
  68. jmpman has joined
  69. jubalh has joined
  70. jonasw pep., which domain?
  71. jonasw pep., even though, all I can do is re-try really, because xmppoke doesn’t give useful logs in any way
  72. daniel has left
  73. jmpman has joined
  74. Guus jonasw: many failed tests on the webpage now.
  75. jonasw Guus, you could check if everything is in order inside the poker by invoking xmppoke manually: cd /opt/xmppoke; luajit /opt/xmppoke/xmppoke.lua --db-host=... --db-password=... -d=10 $domain
  76. jonasw (the "=" between option and value are important)
  77. jonasw I also wonder whether we get an interesting type of spam there
  78. ralphm has joined
  79. ralphm has left
  80. jubalh has left
  81. moparisthebest has joined
  82. tim@boese-ban.de has joined
  83. zinid has left
  84. Guus jonasw, sorry, can't check now. Travellig.
  85. jonasw no worries
  86. jonasw now we’re getting quite a few sensible ones again
  87. jonasw it’s also possible most of what we saw was simply in progress
  88. Guus perhaps
  89. Guus has left
  90. tim@boese-ban.de has left
  91. tim@boese-ban.de has joined
  92. ralphm has joined
  93. edhelas has left
  94. ralphm has joined
  95. jabberatdemo has joined
  96. daniel has left
  97. daniel has left
  98. jabberatdemo has left
  99. jcbrand has joined
  100. daniel has left
  101. daniel has left
  102. Steve Kille has left
  103. edhelas has left
  104. Steve Kille has left
  105. ralphm has left
  106. daniel has left
  107. mimi89999 has left
  108. daniel has left
  109. edhelas has joined
  110. efrit has left
  111. ralphm has left
  112. goffi has joined
  113. efrit has joined
  114. lskdjf has joined
  115. arc has left
  116. arc has joined
  117. daniel has left
  118. @Alacer has joined
  119. @Alacer has left
  120. Martin has joined
  121. @Alacer has joined
  122. Steve Kille has joined
  123. Martin has left
  124. blabla has joined
  125. blabla has joined
  126. blabla has joined
  127. zinid has left
  128. uc has joined
  129. stefandxm has left
  130. ralphm has left
  131. daniel has left
  132. @Alacer has left
  133. @Alacer has joined
  134. Zash has joined
  135. zinid has left
  136. vanitasvitae has left
  137. lumi has joined
  138. vanitasvitae has joined
  139. Holger has left
  140. jere has joined
  141. zinid has left
  142. stefandxm has joined
  143. Zash has left
  144. arc has left
  145. arc has joined
  146. arc has left
  147. efrit has left
  148. arc has joined
  149. stefandxm has left
  150. daniel has left
  151. daniel has joined
  152. Zash has joined
  153. @Alacer has left
  154. @Alacer has joined
  155. ralphm has left
  156. jere has joined
  157. zinid has left
  158. ralphm has left
  159. jere has joined
  160. Steve Kille has left
  161. jere has joined
  162. stefandxm has joined
  163. zinid has left
  164. waqas has joined
  165. valo has joined
  166. valo has joined
  167. @Alacer has left
  168. waqas has left
  169. waqas has joined
  170. la|r|ma has joined
  171. daniel has left
  172. @Alacer has joined
  173. daniel has left
  174. ralphm has left
  175. uc has joined
  176. jere has joined
  177. Syndace has left
  178. Syndace has joined
  179. jjrh has left
  180. jere has joined
  181. jjrh has left
  182. jere has joined
  183. jjrh has left
  184. jjrh has left
  185. Ge0rG marc: https://mail.jabber.org/pipermail/standards/2016-June/031152.html (more on-topic in here)
  186. Ge0rG marc: also another thing I wanted to tell you yesterday: the current PARS token generation doesn't need server interaction, so it's immediate on the client, even if you are on the worst imaginable mobile connection
  187. marc Ge0rG, just the two posts?
  188. Ge0rG marc: there's a loooong thread going into 2017.
  189. Ge0rG marc: https://mail.jabber.org/pipermail/standards/2017-April/032599.html and https://mail.jabber.org/pipermail/standards/2017-May/032616.html
  190. Ge0rG with their respective "next in thread"
  191. marc Ge0rG, okay, maybe I find some time to read it
  192. @Alacer has left
  193. waqas has left
  194. @Alacer has joined
  195. Ge0rG marc: you owe me half an hour of time anyway, for yesterday's discussion :P
  196. waqas has joined
  197. zinid has left
  198. marc Ge0rG, :P
  199. marc Ge0rG, are you on 34c3?
  200. Ge0rG marc: I don't think so
  201. marc Too bad
  202. jonasw marc, the traditional XSF meetup is at FOSDEM
  203. jonasw the SUMMIT
  204. marc jonasw, okay, maybe I'll come to FOSDEM as well :D
  205. jonasw I need to schedule that for me
  206. jere has joined
  207. dropcash77 has joined
  208. dropcash77 has left
  209. pep. has left
  210. daniel has left
  211. uc has left
  212. jere has joined
  213. uc has left
  214. uc has left
  215. marc Ge0rG, are you on FOSDEM 2018?
  216. Ge0rG marc: I might be able to make it to the SUMMIT. Maybe.
  217. Ge0rG marc: at least I've prepared a talk about what's wrong with XMPP ;)
  218. marc :D
  219. marc Ge0rG, but not submitted, right?
  220. Ge0rG marc: you can't submit to SUMMIT
  221. Ge0rG marc: the XSF summit is a separate conference taking place in the days before FOSDEM
  222. marc Ge0rG, ah
  223. Guus has left
  224. Guus has joined
  225. marc I was talking about FOSDEM submission :)
  226. Ge0rG marc: https://wiki.xmpp.org/web/Summit_22
  227. jere has joined
  228. Ge0rG marc: giving my talk at fosdem would be a huge disservice to the XMPP community
  229. marc :D
  230. Ge0rG or I would end up with a reputation similar to Poettering :P
  231. lovetox has joined
  232. jonasw he's fun when he crashes other peoples talks
  233. Ge0rG I've crashed a talk about SCCS once. It was not particularly challenging
  234. Flow Ge0rG who gave the talk?
  235. Ge0rG Flow: I'm not naming names here, but it was at a conference venue known to you.
  236. jcbrand has left
  237. Flow schilling at CLT
  238. Guus has left
  239. efrit has joined
  240. sonny has left
  241. sonny has joined
  242. Tobias has joined
  243. daniel has left
  244. sonny has left
  245. sonny has joined
  246. daniel has left
  247. jcbrand has joined
  248. jubalh has joined
  249. Kev has left
  250. sonny has left
  251. sonny has joined
  252. mimi89999 has joined
  253. jere has joined
  254. sonny has joined
  255. sonny has joined
  256. efrit has left
  257. daniel has left
  258. daniel has left
  259. lskdjf has left
  260. marc Ge0rG, almost everybody except you is voting for server-side implementation, is that correct? :D
  261. Ge0rG marc: I'm not opposed to server side implementations, but please have a look at bookmarks in PEP.
  262. marc the pep idea has some nice features
  263. marc Ge0rG, bookmarks in PEP? what do you mean?
  264. Ge0rG marc: the bookmarks xep recommends pep as the storage backend for a decade now, and there is no proper server support yet
  265. marc well, the PEP can not be used for user-invitation because it can not be limited
  266. marc this is not good for account creation :D
  267. Kev Ge0rG: No, that's just not true. You mean that Prosody doesn't support it, which isn't the same as there being *no* support.
  268. edhelas Kev +1
  269. marc but I like the idea of generating offline tokens
  270. Ge0rG Kev: last time I've heard that prosody completely lacks support, whereas other widely deployed implementations only leak your bookmarks to the general public.
  271. Ge0rG Kev: from a client interoperability perspective, that discussion is moot anyway.
  272. edhelas that's false
  273. Holger Ge0rG: Er, this is specific to bookmarks, and the reason is that the XEP is broken.
  274. goffi has left
  275. edhelas whitelist support is quite great
  276. Holger Ge0rG: Daniel is currently trying to fix it. Once that happened, it will be fixed in the next ejabberd release, for example.
  277. edhelas Holger Daniel is trying to fix what ?
  278. Holger Well, I should say "probably" I guess :-) But I'm quite confident.
  279. zinid has left
  280. Holger edhelas: https://mail.jabber.org/pipermail/standards/2017-December/034023.html
  281. Holger (I was assuming that this is Ge0rG's point.)
  282. edhelas "specified perist_items"
  283. edhelas small typo in the PR :p
  284. daniel Ge0rG, ejabberd leaks your private pep nodes to the public?
  285. Ge0rG Kev: I don't have stats, but I would say that ejabberd and prosody are the most widely deployed servers. They lack support for a feature that's specified for a decade now.
  286. Ge0rG Kev: now please try to convince me this won't happen to server-side-PARS.
  287. daniel i think one could implement bookmarks in pep on conversations.im
  288. Ge0rG daniel: isn't that why you are trying to fix 60 now?
  289. daniel Ge0rG, no?
  290. Ge0rG daniel: I'm sure this will be approved by the Conversations Council of Elders.
  291. Holger Ge0rG: Unless you configure the node with access_model=opoen, then of course it's not leaked.
  292. Ge0rG Holger: I'm sorry for being ignorant about 0060, but what's the default access_model?
  293. Holger Ge0rG: 0163 says "The default access model is 'presence'."
  294. Zash For PEP
  295. Ge0rG Holger: so bookmarks are only leaked to your contacts?
  296. jubalh has left
  297. goffi has joined
  298. edhelas can we not change that to whitelist ?
  299. Zash edhelas: For PEP? That'd make it useless
  300. edhelas servers can also enforce access_model for some PEP namespaces
  301. edhelas the issue is that the user will have to know if the access_model is good somehow
  302. Zash I was intending to have some defaults for well known PEP nodes coded in.
  303. Holger Ge0rG: I know that 0048 uses publish options to set the access model. Right now this doesn't work because it conflicts with 0060. The thing I don't understand is why you take this as an example for servers being slow with implementation. You can't implement a broken spec.
  304. Zash edhelas: That's what you use publish-options preconditions for
  305. edhelas okay
  306. edhelas never heard of it
  307. Kev And therein lies the problem.
  308. Zash But, it's like the most starred issue in the Prosody issue tracker ^^
  309. Holger Ge0rG: But clients can configure the node's access_model even without that spec fix, of course.
  310. Zash Mostly because it has its own marketing team, but still
  311. Kev publish-options isn't exactly well-specified, which is what Daniel's just brought up on list.
  312. daniel > was intending to have some defaults for well known PEP nodes coded in. Zash i'm planning on writing a module that just disables access control for omemo pep nodes. that's why i asked about how to write modules the other day
  313. edhelas ah, here's another piece of 0060 that I'm discovering today
  314. Ge0rG Holger: bookmarks is referencing 223 for over a decade now. Please don't tell me nobody noticed it's broken until now.
  315. Zash Ge0rG: I'm sorry, but nobody noticed that it is broken until now.
  316. Holger Ge0rG: I think I mentioned it on standards@ quite a while ago.
  317. Ge0rG So apparently nobody implementing servers cared enough about this spec, for over a decade.
  318. daniel i noticed about a year ago. i just didn't get around to write a PR
  319. Holger Yeah sure.
  320. Zash Ge0rG: Correct
  321. Kev Ge0rG: They didn't, because 49 for 48 worked fine and there was no reason to change.
  322. Holger If a spec is broken, blame server devs.
  323. Kev And 223 was meant to be a profile of 60, so no-one read 223.
  324. Ge0rG And 0060 is so mind-boggingly complex that nobody read that either.
  325. Zash Soooo, we should get around to finishing that 60 splitup
  326. Ge0rG So everybody just bails out on "*pubsub*"
  327. jonasw Ge0rG, that’s not true, I read it!
  328. Ge0rG And now people come and try to convince me to make my shiny new account registration flow depend on all that mess. Thanks, but no thanks.
  329. Holger jonasw: Me too, but that doesn't help, because the text changes whenever you re-read it.
  330. daniel we should really revisit that hiring famous actors and actresses to make audiobook versions of XEPs
  331. Ge0rG daniel: you can't imagine how much time you need to spend to explain to them the corrent pronounciation of all the tech terms
  332. jonasw Holger, that was my impression too
  333. edhelas daniel :D Book 36 - Pubsub - Chapter 342 - Configuring your node, 64min
  334. Holger :-)
  335. Ge0rG edhelas: that title almost reads like a Bible verse.
  336. Ge0rG "And so saith Saint Peter: it shall be XML"
  337. edhelas 0060 is a bit like the Bible, each people reading it have their own understanding
  338. mathieui and let’s not talk about the religious wars
  339. mathieui and their thousands of casualties
  340. Zash Don't mention the war
  341. Ge0rG Okay, let's longjump out of this mess again. My initial provocative statement was "nobody is implementing server-side PEP bookmark storage". Let me change that to "PEP bookmark storage is mandated for a decade now, and nobody noticed that it's essentially broken for so long"
  342. moparisthebest HAHAHA I almost spit out coffee ‎[10:17:02 AM] ‎edhelas‎: 0060 is a bit like the Bible, each people reading it have their own understanding
  343. moparisthebest that needs to go in the implementation notes of 60 or something
  344. jonasw Ge0rG, where did we setjmp though?
  345. Ge0rG jonasw: just unwind enough stack to get back to PARS
  346. mathieui Ge0rG, I did notice
  347. daniel Ge0rG, in any case, as a council member you could read my two! PRs on xep60 and form an opinion on which one you prefer
  348. Ge0rG daniel: I suppose this is unavoidable.
  349. Ge0rG daniel: and still, I lack sufficient understanding of 0060 so far to be able to contribute an informed opinion. I'll work on it.
  350. daniel has left
  351. la|r|ma has left
  352. zinid has left
  353. jubalh has joined
  354. efrit has joined
  355. Ge0rG Could we please mandate that a server with IBR also MUST provide valid XEP-0157 contact info?
  356. arc has left
  357. arc has joined
  358. Zash Write a XEP
  359. Zash Info XEP on "Things your public server should support"
  360. Ge0rG you can't enforce info-xep's
  361. uc has left
  362. jonasw Ge0rG, you can if you check it on s2sin :>
  363. jonasw and send a <policy-violation/> stream error back.
  364. Zash -xep 222
  365. Ge0rG jonasw: technically, I can. But if it's not official policy, I am not allowed to
  366. Zash -xep 223
  367. Bunneh Zash: Persistent Storage of Public Data via PubSub (Informational, Active, 2008-09-08) See: https://xmpp.org/extensions/xep-0222.html
  368. Bunneh Zash: Persistent Storage of Private Data via PubSub (Informational, Active, 2008-09-08) See: https://xmpp.org/extensions/xep-0223.html
  369. jonasw Ge0rG, that’s why the info XEP :)
  370. Zash Informational, both. Why nobody looked at them?
  371. sonny has left
  372. sonny has joined
  373. la|r|ma has left
  374. lskdjf has left
  375. lskdjf has left
  376. lskdjf has left
  377. zinid has left
  378. lskdjf has left
  379. lskdjf has left
  380. lskdjf has left
  381. jere has joined
  382. lskdjf has left
  383. daniel has left
  384. jere has joined
  385. jere has joined
  386. lskdjf has joined
  387. lskdjf has left
  388. lskdjf has joined
  389. lskdjf has joined
  390. lskdjf has left
  391. lovetox has left
  392. zinid has left
  393. Holger If a server stores groupchat messages into the user archive, the server would have to de-duplicate if multiple resources joined the room, right?
  394. Zash Yes
  395. Holger Fun.
  396. Ge0rG It will also be fun for the client to receive those messages without realizing it was a MUC
  397. Ge0rG not so bad for proper MUC messages, but MUC-PMs will be a PITA
  398. Ge0rG Are MUC-PMs to be stored in the user's MAM?
  399. daniel Holger, Zash: also outgoing and reflected
  400. Zash Makes purely append-only storage reeeeally hard
  401. Ge0rG Finally, the server devs are going to experience the joy of synchronizing a MUC history.
  402. daniel Fun fun fun. All for having an incomplete archive of the room
  403. Ge0rG Especially the ones calling for MUC messages in MAM.
  404. Zash I don't wanna!
  405. Ge0rG Zash: I don't see you complaining on standards@
  406. Holger Maybe the user archive should query the MUC archive to sync missing messages.
  407. Ge0rG Holger: awesome idea.
  408. Ge0rG And the MUC archive should just crowdsource the request to other participants' MAMs.
  409. Ge0rG Distributed storage!
  410. Ge0rG It's all in the cloud now!
  411. Ge0rG wanders off, laughing weirdly.
  412. moparisthebest since the cloud is just other people's computers everything has always been there
  413. jere has joined
  414. lskdjf has left
  415. lskdjf has left
  416. Zash Maybe the clients could send MAM queries to each other!
  417. Ge0rG Zash: then we don't need MUC any more. Just have clients poll each other in a round-robin way to distribute history and messages
  418. Zash Ge0rG: Next, have them connect to each other instead of servers!
  419. daniel has left
  420. jonasw Zash, somebody seriously suggested that a while ago
  421. jubalh has joined
  422. Zash jonasw: Was it me?
  423. daniel has joined
  424. jonasw I don’t think so
  425. jonasw (and I’m referring to "Maybe the clients could send MAM queries to each other")
  426. Zash You could in theory do that among your own clients and have serverless MAM
  427. Ge0rG Zash: ChatSecure used to bundle a HTTP server, minidns and some other tech debt to allow for serverless messaging
  428. Zash WTF HTTP server?
  429. Ge0rG I don't remember any more the rationale for that.. picture sharing maybe? Or forwarding of the app APK?
  430. Ge0rG But I remember their stack was so high it resembled the tower of babel.
  431. marc has left
  432. daniel Http over otr
  433. daniel For file transfer
  434. jere has joined
  435. Ge0rG right!
  436. Zash Why not p2p http. Like p2p proxy65 that already exists
  437. Ge0rG So should I implement XEP-0049 in yaxim now?
  438. jonasw Ge0rG, yes
  439. Kev I think client-only MAM is not at all stupid - and is probably the only sane thing to do in the world of E2E.
  440. Zash It wouldn't be too hard to sync bookmarks between PEP and private xml
  441. jonasw Zash, would be great to have that in prosody
  442. Ge0rG Kev: client-side MAM queries that get around E2EE are also stupid.
  443. Ge0rG Or at least notoriously hard to get right.
  444. Zash jonasw: Depends on PEP with configurable access models, which isn't quite there yet.
  445. Zash In theory possible to hard-code some nodes to be private
  446. Kev Ge0rG: Sure. Just needs a vector clock and the server to inject MAM IDs into every stanza, right? :)
  447. jonasw Zash, might not be the worst idea
  448. blabla has joined
  449. Ge0rG Kev: I'm not quite sure what you are referencing, and I'm even less sure I can keep my sanity if you explain it.
  450. Kev Not worth thinking about. I'm just distracting myself from far too many hours worth of Council work.
  451. Kev I'd forgotten how much of the week Council takes.
  452. Zash Kev: Vector clocks? I thought blockchain was the hip thing for everyhing now?
  453. Kev Choose your poison :)
  454. daniel has left
  455. daniel has joined
  456. jonasw my favourite gem out of XEP-0153 (vcard avatars): > The XML character data of the <TYPE/> element is a hint. If the XML character data of the <TYPE/> specifies a content type that does not match the data provided in the <BINVAL/> element, the processing application MUST adhere to the content type of the actual image data and MUST ignore the <TYPE/>. If the <TYPE/> is something other than image/gif, image/jpeg, or image/png, it SHOULD be ignored.
  457. jonasw TL;DR: ignore <TYPE/>
  458. daniel Kev: I'm not sure if "all messages I ever received excluding messages I didn't receive in group chats because I was offline" is actually a use case you have or if you just believe it to be the right thing. We have mam for a couple of years now and none of the servers seem to store them and I haven't seen anyone complaining that their mam archive *lacks* group chat messages
  459. Kev M-Link does, FWIW, although not in all circumstances.
  460. jonasw I’m pretty confident that having MUC groupchat in MAM is horrible
  461. Ge0rG I think that adding any MUC messages into local MAM opens up a can of worms.
  462. Kev I could be wrong on this one, but over the weekend I convinced myself I was wrong before when I thought I was wrong, and that I was originally right.
  463. debacle has joined
  464. Kev So I'm not refusing to make the proposed change, but I'm not sold on it at the moment.
  465. Ge0rG Kev: could you please annotate your right-wrong statement with the content of the respective opinions, so others can follow?
  466. daniel It will always be incomplete be definition. It will be a nightmare to dedup with muc history coming in multiple time and receiving the reflections for outgoing messages
  467. Kev I originally though MUC should be in MAM. Daniel said it shouldn't, and I temporarily believed him, but when I went to make the change I persuaded myself MUC belongs in MAM again.
  468. daniel Sure the dedup issues can be resolved
  469. daniel But to what end? Almost all clients will throw the messages away or not request them
  470. Kev Dedup sounds like a somewhat strong argument.
  471. Holger "Incomplete archive" sounds stronger to me :-)
  472. Kev I don't think it's an incomplete archive, is it?
  473. Kev It's a complete archive of what the user has received in her live sessions.
  474. Kev It's incomplete w.r.t. to the MUC, but that's ok because the user wasn't in the MUC at the time.
  475. Holger Sure. We invented MUC MAM because users didn't perceive this as "ok".
  476. Holger I thought.
  477. Ge0rG users want a full MUC archive.
  478. Kev That's probably true, and one reason for MIXxing it up.
  479. Ge0rG I've heard that messages getting lost is the #1 problem with XMPP.
  480. Kev Could someone collate all these reasons and shove them in response to my mail to standards@ so we have a record in the right venue, please?
  481. Holger (I did respond with mine already.)
  482. zinid has left
  483. Ge0rG Today I got a dozen of error bounces for half an hour worth of conversation I had with a friend, because his mobile client's session was hibernated and killed, and apparently the mobile client was receiving full messages and not just carbons.
  484. bjc has joined
  485. Kev Carbons are a *nightmare* for bounce handling.
  486. Kev If you want to talk about server dedup handling being nearly impossible - Carbons can be taken out and shot immediately :)
  487. lovetox has joined
  488. bjc has left
  489. Holger "When a server attempts to deliver a (locally generated) carbon copy, and that carbon copy bounces with an error for any reason, the server MUST NOT forward that error back to the original sender."
  490. Ge0rG Kev: I received error bounces from my contact, and error bounces for Carbons should go to the account and not to the chat partner, so obviously there were no carbons involved.
  491. Kev Holger: But what when the carbons were delivered and the originals bounced? It's horrid.
  492. Kev Ge0rG: ^
  493. Ge0rG Kev: yes. That's exactly what happened.
  494. Holger Kev: Yes. Or when the user will receive the messages from MAM.
  495. Holger You can easily make the right decision simply by looking into the future.
  496. Ge0rG I had a nice conversation full of green checkmarks, and then *BAM!* the zombie exploded and it was all full of "✖ cancel: recipient-unavailable"
  497. Kev Holger: I'm not convinced it'd be easy, even then :)
  498. daniel The real jid annotation for non anonymous mucs also won't work if the archive is on the user's server
  499. daniel I've made all these arguments in my original mail by the way
  500. Kev All of them? I'd forgotten about dedup, in that case.
  501. Ge0rG It wasn't explicitly called dedup, but: > And even worse the messages will be included in a normal catchup (when I don't necessarily want them)
  502. Ge0rG So, what about storing MUC-PMs in MAM?
  503. Kev Those you certainly want in there, because they won't be stored anywhere else. That much I'm confident I'm not wrong about.
  504. jonasw Ge0rG, blame the client for taking type='error' responses into account after a MDR has been received.
  505. Kev (The real-jid thing is a problem with stripping elements, that I'm fairly convinced MAM shouldn't do too liberally)
  506. jonasw Kev, MUC-PMs are really bad in MAM. how would a client not knowing about the MUC distinguish one or more MUC-PM conversations in the same MUC from a single conversation with a random entity?
  507. Ge0rG jonasw: in a multi-client scenario, there is no right way to handle MDR / error responses, in any order.
  508. jonasw Kev, MUC-PMs are really bad in MAM. how would a client not knowing about the MUC distinguish one or more MUC-PM conversations in the same MUC from a single conversation with an entity having the MUCs JID?
  509. Ge0rG jonasw: <x/> tags!
  510. jonasw Ge0rG, what’s wrong with MDR wins?
  511. Holger jonasw: MUC PMs are really bad regardless of MAM.
  512. jonasw Holger, no reason to make them worse by offering them to clients which don’t even know about the MUC
  513. Kev jonasw: The issue there is really clients not knowing that it's a MUC - and they do have that information available to them.
  514. jonasw Kev, so essentially clients need to support XEP-0045 to use MAM? :)
  515. Ge0rG jonasw: "MDR wins" will lead to situations where only a buried secondary client received the message and MDRed it, and it still didn't arrive where it was urgently needed
  516. Holger jonasw: So don't offering them to clients who do know about the MUC is the obvious solution?
  517. Holger s/don't/not/
  518. jonasw Holger, I think so
  519. Ge0rG Kev: clients don't generally know which JID is a MUC
  520. Holger jonasw: "Jonas, you installed me this app and now I LOST MESSAGES!"
  521. Steve Kille has left
  522. Kev Ge0rG: They can do, they only have to ask.
  523. jonasw Ge0rG, tricky, but then again, that other client which wanted to have them is offline, and should sync with MAM on reboot
  524. daniel I mean the dedup issue can be solved fairly easily by a simple store everything and blame the clients rule
  525. Steve Kille has left
  526. jonasw Holger, we should disable MUC PMs in all clients.
  527. jonasw being polemic here :)
  528. daniel Plus nobody will notice because we will just discard messages anyway
  529. Holger jonasw: I would agree if you weren't polemic :-)
  530. daniel > jonasw: I would agree if you weren't polemic :-) 👍
  531. jonasw Holger, I may be even serious, I’m not entirely sure.
  532. Ge0rG Kev: that involves at least one connection over an unreliable network medium.
  533. Ge0rG jonasw: except not all clients support MAM.
  534. Ge0rG Kev: in your client architecture, it might be okay to delay the processing of an incoming message until a separate query to a server has been fired off and completed.
  535. Ge0rG I just hope that you have a query manager that doesn't fire off the lookup for each individual message in the MAM flood.
  536. Steve Kille has joined
  537. jere has joined
  538. Ge0rG > Each field MUST specify whether it defines METADATA to be attached to the item, a per-item OVERRIDE of the node configuration, or a PRECONDITION to be checked against the node configuration. What does that sentence from 0060 mean in English?
  539. Zash You have to say what the field does when you register it.
  540. Ge0rG when I register the field?
  541. jcbrand has left
  542. jere has joined
  543. jere has joined
  544. Zash Yes. In the registry for that. Publish-options?
  545. Ge0rG But I'm publishing an item, not registering a field.
  546. Zash Ge0rG: Do you want to know what each of those three terms mean or somethnig?
  547. jonasw Ge0rG, I hate things
  548. Ge0rG Zash: that, too.
  549. Ge0rG Zash: it just doesn't make any sense to me.
  550. jonasw Ge0rG, <publish-options/> uses a form with defined fields
  551. Ge0rG jonasw: right.
  552. jonasw the field registry tells you whether it’s METADATA, per-item OVERRIDE or PRECONDITION
  553. jonasw the sentence you quoted enforces that
  554. Zash preconditions makes the publish fail if the value does not match the node config
  555. Zash overrides changes the node config, but only for that item
  556. Ge0rG jonasw: when grepping the XEP for METADATA, I only find other metadata and the quoted sentence, not an explanation.
  557. Zash Ge0rG: "metadata"
  558. Zash Ge0rG: I think that might be what the stuff in Push is
  559. Ge0rG §5.4 Discover Node Metadata?
  560. daniel Ge0rG, it exists because you have to register all form fields and you might want form fields that are NOP
  561. Ge0rG or maybe Stanza Headers and Internet Metadata (XEP-0131)?
  562. daniel https://gist.github.com/iNPUTmice/7c52785ed69787516abb60e31703dbd2 describes how to use publish-options from a client perspective in case this helps
  563. Ge0rG daniel: thanks, maybe that will enlighten me.
  564. jonasw Ge0rG, https://xmpp.org/extensions/xep-0357.html#publishing Example 13. Server publishes a push notification with provided publish options
  565. jonasw I think that’s an example of metadata
  566. jonasw it is neither a precondition nor a per-item override
  567. jonasw it is neither a precondition nor a per-item override of configuration
  568. jonasw but something which is used by the pubsub service to do things
  569. Zash Do Things™
  570. Ge0rG okay, so publish-options is overloaded with three comepletely different semantics, one of them to add meta-data content to the published event, another to check node configuration and a third one to change node configuration for this item?
  571. Zash Yes
  572. jonasw Ge0rG, yes.
  573. Ge0rG Can't they just write that into the XEP?
  574. Zash It would be nice to split that into three different forms.
  575. goffi has left
  576. Zash Buuuuut uh
  577. daniel fwiw one of my PRs gets rid of override
  578. Ge0rG Zash: I presume "But backward compat"
  579. Zash Ge0rG: p much
  580. Ge0rG now I need to understand what "node configuration" is.
  581. daniel because it was never used we can savely removeit
  582. Holger Or just ditch METADATA and OVERRIDE.
  583. Zash Altho since nobody used any of that until daniel started doing it with OMEMO ...
  584. Zash Holger: And ditch PubSub in Push entirely?
  585. Holger Zash: Yes, currently it's non-standard anyway.
  586. daniel > Altho since nobody used any of that until daniel started doing it with that's probably true for a couple of things
  587. Zash Altho it is mentioned by 222 or 223, which nobody supports.
  588. Zash So, nm
  589. Holger Zash: push says I can add arbitrary custom data. 0060 forbids that.
  590. Zash Hnng
  591. daniel Zash, the push xep is not really an issue because that particular pubsub service doesn't have to annouce publish-options and all is good
  592. daniel put we can register that one push publish-options keyword as metadata if you prefer that
  593. Holger Yes, it is just not a PubSub service.
  594. daniel it's just the app server sort of accepting one pubsub like command for what ever reason
  595. Holger As you can't use a standard PubSub service for this anyway, it doesn't matter indeed.
  596. zinid has left
  597. Holger daniel: ChatSecure uses different fields FWIW.
  598. daniel Either way it doesn't conflict wit the wording in xep60
  599. tux has joined
  600. jjrh has left
  601. Holger Well but only because this is not 0060-PubSub but a 0357-specific protocol with PubSub-like syntax.
  602. daniel has left
  603. Holger This still annoys me but admittedly it's a separate issue.
  604. jjrh has left
  605. Ge0rG 0357 is overly complex, isn't it?
  606. jubalh has joined
  607. daniel You just couldn't run a pubsub service and an app server on the the jid
  608. daniel Not sure why one would want that
  609. Holger Ge0rG: No it's simple IMO. Just (a) underspecified and (b) used PubSub-like syntax for no good reason except to mislead client developers into believing they could use a PubSub service when implementing an app server.
  610. Holger daniel: Yes there's just problem if the developer understands all that.
  611. Holger *no problem
  612. stefandxm has left
  613. jjrh has left
  614. jjrh has left
  615. zinid has left
  616. uc has left
  617. uc has joined
  618. jcbrand has joined
  619. jonasw okay
  620. jonasw now for real: what is the most deployed avatar protocol currently?
  621. Zash Define deployed
  622. jonasw actually used in the wild
  623. jonasw "will make my client show an avatar with the highest likelihood"
  624. tux has left
  625. jcbrand has left
  626. Zash "All of the above"
  627. Zash Make a thing that collects stats?
  628. jonasw I’m slightly frustrated after seeing that XEP-0153 support doesn’t bring much in my roster and now I’m afraid that it might in fact all be xep8
  629. Zash Conversations popularity might have shifted it quite a bit for 84
  630. Zash But, don't like Pidgin even support both?
  631. jonasw pidgin doesn’t support PEP for sure
  632. jonasw or medium-sure
  633. Zash Are you sure?
  634. jonasw no
  635. jonasw I’m confused
  636. Holger It does.
  637. jonasw and frustrated
  638. arc has left
  639. arc has joined
  640. jonasw and hungry
  641. Zash I thought I saw Mood and stuff in there
  642. Holger Pidgin supports both vCard and PEP avatars.
  643. Holger And it publishes both.
  644. jonasw okay, but not XEP8?
  645. arc has left
  646. Zash That's the second time you write XEP8
  647. Zash -xep 8
  648. Bunneh Zash: IQ-Based Avatars (Historical, Deferred, 2005-06-16) See: https://xmpp.org/extensions/xep-0008.html
  649. Zash Wat?!
  650. Holger Hah.
  651. Holger jonasw: I don't think so :-)
  652. Zash Now I'm possibly just as confused as you are
  653. Zash -xep 84
  654. Bunneh Zash: User Avatar (Standards Track, Draft, 2016-07-09) See: https://xmpp.org/extensions/xep-0084.html
  655. jonasw Zash, that’s good
  656. jonasw I don’t feel so alone anymore
  657. Zash Let's all just switch to xep 8 and {xep user profile}
  658. Bunneh Zash: Multiple matches: User Profile https://xmpp.org/extensions/xep-0154.html Extensible SASL Profile https://xmpp.org/extensions/inbox/sasl2.html Tree Transfer Stream Initiation Profile https://xmpp.org/extensions/xep-0105.html Profiles https://xmpp.org/extensions/xep-0006.html XMPP Date and Time Profiles https://xmpp.org/extensions/xep-0082.html Message Stanza Profiles https://xmpp.org/extensions/xep-0226.html Extensible SASL Profile https://xmpp.org/extensions/xep-0388.html User Mood https://xmpp.org/extensions/xep-0107.html User Tune https://xmpp.org/extensions/xep-0118.html User Time Zone https://xmpp.org/extensions/inbox/peptzo.html User Avatar https://xmpp.org/extensions/xep-0084.html User Activity https://xmpp.org/extensions/xep-0108.html
  659. Zash oh dear
  660. jonasw I‘d like to know for example how the heck to get georgs avatar
  661. Zash -xep 6
  662. Bunneh Zash: Profiles (SIG Formation, Obsolete, 2002-05-08) See: https://xmpp.org/extensions/xep-0006.html
  663. jonasw because it doesn’t seem to be in either PEP or vCard
  664. jonasw cc @ Ge0rG ^
  665. Zash -xep 154
  666. Bunneh Zash: User Profile (Standards Track, Deferred, 2008-04-18) See: https://xmpp.org/extensions/xep-0154.html
  667. Zash A data form?
  668. jonasw pidgin shows much more avatars than jabbercat with 153 and 84.
  669. jonasw could still be a bug in the 153 impl, but ...
  670. Zash I have this feeling that it uses the wrong namespace for something
  671. Zash Or am I confused?
  672. arc has joined
  673. Zash -xep 154
  674. Bunneh Zash: User Profile (Standards Track, Deferred, 2008-04-18) See: https://xmpp.org/extensions/xep-0154.html
  675. Zash -xep 153
  676. Bunneh Zash: vCard-Based Avatars (Historical, Active, 2006-08-16) See: https://xmpp.org/extensions/xep-0153.html
  677. Zash After performing an unscientific test, 27% of presence I see seems to have vcard-temp
  678. jonasw any jabber:x:avatar?
  679. Zash In a moment
  680. jonasw thank you very much for measuring
  681. Zash This CLI client tends to become unhappy about presence floods
  682. Zash rlwrap + long, colored lines => unhappyness
  683. Zash Also, FWIW, I did not count the cached presence I got, which has only <show> and <delay>
  684. jonasw I’m happy with a > 0 result in fact
  685. Zash Hm, but are these even comparable?
  686. jonasw why wouldn’t they?
  687. Guus has joined
  688. Zash Not all servers send presence for offline contacts
  689. Zash Also some may have multiple online devices
  690. Zash I get '84 notifications from 37% of contacts
  691. Zash And like 2.4 presences per contact...
  692. jjrh has left
  693. Zash jonasw: 153 needs at least one *currently online client* to work (or you could poll vcards)
  694. jonasw Zash, does it?
  695. Zash While 84 needs at least one client to have published an avatar at some point in the past (modulo server persistence support or uptime)
  696. jonasw but 153 stores the avatar at the server, too?
  697. jonasw and there’s that presence notification thing
  698. Zash jonasw: Right. Notifications as defined by 153 requires an online client. Altho I suppose a server could inject the thing into offline presence.
  699. Zash Not aware of any doing the later
  700. Zash Could inject into online presence too
  701. Zash Server could even sync the avatar data between them. Mine does that for example.
  702. jonasw can we have that in prosody? ;-)
  703. Zash Write a plugin ;)
  704. jonasw how does your server do that?
  705. zinid jonasw, done in ejabberd like 10 years ago 🙂
  706. Zash zinid: which part?
  707. zinid Zash, both
  708. zinid pep<->vcard sync, and xupdate injection
  709. goffi has joined
  710. jonasw zinid, neat, that probably explains why I’m seeing a lot of PEP avatars
  711. zinid as well as possibility to convert between image formats
  712. Zash Someone did a thing for that for prosody too
  713. zinid yeah, prosody also has such modules, but not sure about xupdate injection
  714. Zash I'm not aware of any doing that, no
  715. Zash Wouldn't be hard
  716. zinid yeah, it's trivial
  717. zinid it was a contribution back then
  718. arc has left
  719. zinid the only problem is to make sure direct presences are also modified, it's a bit harder in ejabberd
  720. zinid probably in prosody this doesn't matter
  721. Zash Not too hard, no
  722. zinid well, resending all direct presences is a problem, I need to solve it finally 🙂
  723. arc has joined
  724. Zash 57% image/png 29% image/webp 14% image/jpeg
  725. zinid we recommend webp -> jpeg convertion
  726. zinid I mean in ejabberd
  727. stefandxm has joined
  728. Ge0rG has left
  729. Ge0rG has left
  730. zinid has left
  731. Ge0rG has left
  732. stefandxm has left
  733. waqas has left
  734. waqas has joined
  735. waqas has left
  736. blabla has left
  737. Ge0rG has joined
  738. Ge0rG has left
  739. goffi has left
  740. zinid has left
  741. goffi has joined
  742. ralphm has joined
  743. moparisthebest has left
  744. daniel has left
  745. ralphm has left
  746. lskdjf has left
  747. lskdjf has left
  748. stefandxm has joined
  749. arc has left
  750. arc has joined
  751. Guus has left
  752. Guus has joined
  753. lskdjf has joined
  754. Kev Right, GOK how many hours later, I think I'm finally up to date with LC reviews and feedback.
  755. lskdjf has left
  756. marc Ge0rG, one problem of combining user-invitation (account creation) and PARS is that both have different constraints regarding token lifetime
  757. marc a token for account creation should only valid for a single invitation whereas a PARS token could be used multiple times (see ML)
  758. marc combining both would mean that we have to set N=1 for PARS as well
  759. Guus has left
  760. jubalh has joined
  761. jubalh has left
  762. lskdjf has left
  763. zinid has left
  764. lskdjf has left
  765. lskdjf has left
  766. daniel has left
  767. lskdjf has left
  768. lskdjf has left
  769. jere has joined
  770. zinid has left
  771. lskdjf has left
  772. SamWhited has left
  773. Ge0rG marc: if you read the PARS XEP, you might find out that the default use case is N=1 😜
  774. lskdjf has left
  775. lskdjf has left
  776. Guus has joined
  777. lskdjf has joined
  778. marc Ge0rG, yes, just read the ML and saw the idea of N > 1 and offline usage
  779. Ge0rG marc: obviously the token limitations need to be shared by pars and account invitation
  780. marc Ge0rG, yes, that's what I said ;)
  781. Ge0rG Yes, and how is that a problem?
  782. lskdjf has left
  783. marc Ge0rG, just liked the idea of offline usage and N > 1 for PARS
  784. marc Just that ;)
  785. jcbrand has joined
  786. lskdjf has joined
  787. Ge0rG I didn't like N>1 very much, but I can live with it
  788. lskdjf has left
  789. lskdjf has left
  790. arc has left
  791. lskdjf has left
  792. tux has joined
  793. zinid has joined
  794. lskdjf has joined
  795. daniel Ge0rG: wait didn't you introduce this?
  796. arc has joined
  797. daniel I vaguely remember me trying to convince you that we only need n=1
  798. Ge0rG daniel: wait. I didn't like N=infinity.
  799. daniel there is only 0,1 and infinity
  800. Ge0rG daniel: but then you convinced me that 1 and infinity are the only two useful cases, or some such.
  801. daniel so everything >1 is infitiny
  802. Ge0rG daniel: but if we start out with an ad hoc command anyway, we can make it N=1
  803. efrit has left
  804. efrit has joined
  805. daniel oh right i wanted to make it time constrained to cover the use case of sending the same email to multiple recipients
  806. lskdjf has joined
  807. lskdjf has left
  808. andrey.g has left
  809. debacle has left
  810. andrey.g has joined
  811. Ge0rG Yeah, and I hoped that people expect invitation links to work only once
  812. daniel has left
  813. daniel has left
  814. daniel has joined
  815. marc Ge0rG, as long as you can live with server-side PARS everything is fine :D
  816. zinid has left
  817. lskdjf has joined
  818. lskdjf has left
  819. intosi has left
  820. moparisthebest I missed the recent stuff, but wasn't PARS originally supposed to work if implemented by server OR client ?
  821. lskdjf has left
  822. lskdjf has left
  823. Ge0rG moparisthebest: yes. I still can see a sensible fallback for servers without support
  824. mimi89999 has left
  825. moparisthebest I think that's the ideal situation
  826. marc Ge0rG, but that's a client decision and I would vote against it :]
  827. moparisthebest requiring server support immediatly puts widespread use off for years
  828. Ge0rG marc: you would vote against what exactly?
  829. marc providing user invitation on client-side as fallback
  830. marc because it leads to different behaviour and might confuse users
  831. moparisthebest so it's better to have no fallback and things just not work?
  832. moparisthebest that wouldn't confuse users
  833. Ge0rG "why don't I have that invite button you are talking about?"
  834. Ge0rG marc: I'm not sure if you try to out-troll me or if you are serious...
  835. marc IMO it is better to tell user why something is not available / possible instead of silenty change the behaviour
  836. marc Ge0rG, no, I don't waste my time with trolling
  837. marc Ge0rG, that's just my experience with XMPP/Jabber novices
  838. Ge0rG marc: so you want to teach users how what they want is impossible, instead of making it work in the 90% case?
  839. marc Ge0rG, client-side PARS is available in a single client
  840. marc 90 %?
  841. marc What is for users with other clients, older versions etc.
  842. moparisthebest so a "Sorry please tell your server administrator to enable PARS" is preferable to it just working?
  843. Ge0rG marc: even with manual approval, the invitation link is a great improvement of the user story
  844. moparisthebest that's how you get "I tried XMPP once, it sucks"
  845. Ge0rG marc: pars will work with your client, I just need to push one more button
  846. moparisthebest marc, if I had to guess, a single client is 90%+ of new users (conversations)
  847. daniel has left
  848. daniel has joined
  849. marc moparisthebest, I have lots of users with old Conversations versions
  850. marc Same is true for Gajim
  851. marc Because your distro doesn't always provide the newest version
  852. Ge0rG marc: the nice thing about PARS is it's 100% backwards compatible
  853. marc It's just my experience with my users
  854. Ge0rG marc: so I really don't understand what's your problem
  855. Zash FWIW Conversations having a server features list thing seems to work.
  856. Zash I don't think normal users actually understand it, other than a list of checkboxes that they want to be all green
  857. marc Ge0rG, I wouldn't call it problem, just my opinion regarding UX and experience with non-pro-users
  858. Zash And like, don't underestimate how much humans wants to collect imaginary internet points
  859. Ge0rG marc: I've implemented pars in yaxim, so it might have some 5000 users now. And it doesn't need users to migrate to another server or seeing "you are not allowed to do this, Dave"
  860. lovetox has left
  861. Ge0rG marc: computers are supposed to do the work for their user, not to teach them how they are doing it wrong
  862. Zash Ge0rG: +inf
  863. jubalh has joined
  864. jubalh has left
  865. jubalh has joined
  866. moparisthebest marc what % of users use old clients vs what % use old servers I wonder
  867. moparisthebest seems clients update much more often to me
  868. zinid has joined
  869. Zash Survey time?
  870. jere has joined
  871. lskdjf has left
  872. lskdjf has left
  873. lskdjf has left
  874. lskdjf has joined
  875. marc moparisthebest, that's correct but implemting a feature on client-side because all the public servers suck is not a solution. Nobody will join the XMPP network without "standard" features which are not available on exactly those server you're talking about
  876. marc So the basic problem are the available servers and their operators
  877. moparisthebest so if something can be implemented on the server with a sane on the client fallback, you should do it that way, imho
  878. Ge0rG marc: let's just shut down all public servers except conversations.im
  879. Ge0rG It's the only one supporting all conversations features anyway
  880. marc Ge0rG, you don't agree?
  881. marc It's hard to convince somebody to join XMPP because of privacy,decentralization, etc.
  882. marc But if you tell the users "Image sharing is not possible in group chat" they just laugh at you
  883. moparisthebest no you want to convince them that it works better than anything else
  884. zinid has left
  885. moparisthebest and uh, wasn't that image sharing in muc solved by http upload years ago?
  886. marc moparisthebest, yes, but lots of server don't support it
  887. marc That's my point ;)
  888. Zash Nothing matters, except network effects.
  889. marc Zash, not really, if you lack basic features you have no chance
  890. Zash I'm pretty sure people will use garbage if it lets them talk to their friends.
  891. moparisthebest so I had a question about that actually, http upload doesn't need server support right? at least from *your* server, like apps could hardcode httpupload.someremote.component
  892. zinid has joined
  893. moparisthebest is that frowned upon or disallowed in XEPs or
  894. Zash Garbage with a larger marketing department than what you have
  895. Ge0rG marc: so now you try to force users to move by telling them that their server sucks. They won't like that
  896. Zash moparisthebest: That'd be like Pidgin & co hardcoding proxy.eu.jabber.org as file transfer proxy
  897. moparisthebest so what I imagined, not sure how legit this is or not
  898. moparisthebest is what if xsf set aside some subdomains
  899. moparisthebest *.component.xmpp.org
  900. moparisthebest and http upload registered httpupload.component.xmpp.org
  901. moparisthebest and all clients could hardcode a fallback to that
  902. moparisthebest and all servers could hardcode a local service serving that domain if they wished
  903. marc Ge0rG, sorry to say that but most server sucks... last time I ask somebody to send me a picture and I received a jingle file transfer (not working of course) and I forget that this user is on a shitty server...
  904. moparisthebest are there downsides to that?
  905. Zash Data at rest is afaik legally different from data in transit (eg passing through a proxy)
  906. Zash so, that would be horrifying
  907. Zash And not something I'd wanna do if I were on the iteam
  908. moparisthebest so possibly httpupload is a bad example because of that
  909. moparisthebest but what if it was a passthrough type component
  910. moparisthebest I'm particularly interesting because I have something exactly like this in mind :)
  911. SamWhited All of this is why you shouldn't try to get people to "use XMPP" or "use Jabber" you should get them to "use jabber.at" or "use <my-favorite-service>" and don't even tell them that it's "XMPP" or "jabber"
  912. Ge0rG I don't even want to know what my users upload to http.
  913. Zash HTTP passtrough? Still, look at how well proxy.eu.jabber.org is doing
  914. lumi has left
  915. marc SamWhited, +1
  916. jcbrand has left
  917. marc Ge0rG, of course I offered this guy to join my server...
  918. Ge0rG marc: of course you did.
  919. moparisthebest Zash, think of it as a bot type thing, you send it things, it sends them back
  920. marc Ge0rG, yeah because now this guy is in 2017 and can send images without configuring a STUN server or use other shitty solutions...
  921. Ge0rG Yesterday I migrated a user from jabber.org to yax.im because of Emoji in nicknames
  922. marc Ge0rG, :>
  923. Zash Robot face strikes again, sorta
  924. marc Ge0rG, and that's just HTTP upload, let's not talk about E2E/OMEMO...
  925. Zash has left
  926. Ge0rG marc: you need to give the users positive incentives to switch, not force them
  927. Ge0rG I don't even know why we are arguing here
  928. Zash I don't even know what you are arguing about.
  929. marc Ge0rG, switch to XMPP or other servers?
  930. Ge0rG Zash: About whether PARS should have a client side fallback to compensate for outdated servers
  931. marc And about the general idea to solve the "shitty server" problem with client-side workarounds
  932. zinid has left
  933. Zash Aren't we all doing that, solving problems by fixing them locally? :)
  934. Zash It probably doesn't matter as much if you manage peoples expectations.
  935. Zash has left
  936. daniel has left
  937. daniel has joined
  938. Ge0rG Zash: expectations like "XMPP sucks anyway"?
  939. Zash If people expect it to suck, then they can only have positive suprises! :)
  940. edhelas has left
  941. ralphm has left
  942. lskdjf has joined
  943. sonny has joined
  944. uc has left
  945. uc has joined
  946. lskdjf has left
  947. lskdjf has joined
  948. daniel has left
  949. daniel has joined
  950. lskdjf has left
  951. lskdjf has joined
  952. lskdjf has left
  953. lskdjf has joined
  954. lskdjf has left
  955. lskdjf has joined
  956. lskdjf has left
  957. lskdjf has joined
  958. lskdjf has left
  959. lskdjf has joined
  960. uc has joined
  961. tux has joined
  962. SamWhited has left
  963. lskdjf has left
  964. lskdjf has joined
  965. lskdjf has left
  966. lskdjf has joined
  967. lskdjf has left
  968. lskdjf has joined
  969. arc has left
  970. arc has joined
  971. arc has left
  972. daniel has left
  973. daniel has joined
  974. uc has joined
  975. lskdjf has left
  976. arc has joined
  977. lskdjf has joined
  978. valo has left
  979. daniel has left
  980. daniel has joined
  981. daniel has left
  982. daniel has joined
  983. uc has joined
  984. vanitasvitae has left
  985. vanitasvitae has joined
  986. lumi has joined
  987. daniel has left
  988. daniel has joined
  989. daniel has left
  990. daniel has joined
  991. daniel has left
  992. daniel has joined
  993. uc has joined
  994. marc has left
  995. marc has left
  996. sonny has left
  997. sonny has left
  998. sonny has left
  999. sonny has left
  1000. sonny has left
  1001. efrit has left
  1002. lskdjf has joined
  1003. efrit has joined
  1004. lskdjf has left
  1005. sonny has left
  1006. sonny has left
  1007. uc has joined
  1008. sonny has left
  1009. uc has joined
  1010. efrit has left
  1011. sonny has joined
  1012. efrit has joined
  1013. efrit has left
  1014. uc has joined