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