XSF Discussion - 2017-03-13

  1. intosi has joined
  2. bjc has joined
  3. Mancho has left
  4. intosi has left
  5. jere has left
  6. jere has joined
  7. vurpo has left
  8. vurpo has joined
  9. sezuan has left
  10. intosi has joined
  11. Alex has left
  12. intosi has left
  13. kalkin has joined
  14. Yagiza has joined
  15. moparisthebest has joined
  16. Tobias has left
  17. intosi has joined
  18. vurpo has left
  19. vurpo has joined
  20. intosi has left
  21. SouL has left
  22. SouL has joined
  23. kaboom has left
  24. Tobias has left
  25. Vinilox has joined
  26. vurpo has left
  27. vurpo has joined
  28. intosi has joined
  29. kalkin has left
  30. daniel has left
  31. daniel has joined
  32. intosi has left
  33. kalkin has joined
  34. nicolas.verite has joined
  35. vurpo has left
  36. vurpo has joined
  37. intosi has joined
  38. intosi has left
  39. nicolas.verite has left
  40. Mancho has joined
  41. sezuan has left
  42. SamWhited has left
  43. sezuan has left
  44. sezuan has left
  45. sezuan has left
  46. SamWhited has joined
  47. SamWhited has joined
  48. SamWhited has joined
  49. SamWhited has joined
  50. intosi has joined
  51. nicolas.verite has joined
  52. intosi has left
  53. moparisthebest has left
  54. moparisthebest has joined
  55. mimi89999 has left
  56. mimi89999 has left
  57. mimi89999 has joined
  58. nicolas.verite has left
  59. intosi has joined
  60. Valerian has joined
  61. dwd has joined
  62. Guus has left
  63. nyco has joined
  64. intosi has left
  65. Flow has joined
  66. nicolas.verite has joined
  67. nyco has left
  68. nicolas.verite has left
  69. rion has joined
  70. mimi89999 has joined
  71. nicolas.verite has joined
  72. uc has left
  73. uc has joined
  74. mimi89999 has joined
  75. nicolas.verite has left
  76. kalkin has left
  77. kalkin has joined
  78. Vinilox has joined
  79. Flow has left
  80. Guus has left
  81. Mancho has left
  82. nyco has left
  83. intosi has joined
  84. waqas has joined
  85. pep. has left
  86. pep. has left
  87. suzyo has joined
  88. Guus has left
  89. nyco has joined
  90. nicolas.verite has joined
  91. nyco has left
  92. Guus has left
  93. Guus has left
  94. sonny has joined
  95. sonny has joined
  96. jere has left
  97. jere has joined
  98. nicolas.verite has left
  99. Valerian has left
  100. blipp has left
  101. nicolas.verite has joined
  102. uc has left
  103. uc has joined
  104. pep. has joined
  105. Valerian has joined
  106. intosi has left
  107. intosi has joined
  108. Laura has joined
  109. Laura has left
  110. waqas has left
  111. Laura has joined
  112. Laura has left
  113. Laura has joined
  114. sonny has joined
  115. nyco has joined
  116. kaboom has joined
  117. Steve Kille has left
  118. Steve Kille has left
  119. sezuan has left
  120. zeank has joined
  121. Guus has left
  122. Steve Kille has joined
  123. zeank Hidiho! In the light of Push Notifications I wondered if it wouldn't make sense to add a <no-push xmlns="urn:xmpp:hints"/> to https://xmpp.org/extensions/xep-0334.html ?
  124. rion has left
  125. Ge0rG zeank: where should it be used, then?
  126. nyco has joined
  127. zeank To not trigger a push on the server side
  128. Tobias and you want remote parties in control of that?
  129. zeank in certain cases, yes
  130. zeank Ok, I see a problem … they could control it all then :/
  131. nicolas.verite has left
  132. Tobias zeank, what cases are those?
  133. zeank in our scenario we exchange let's call it meta information between clients
  134. zeank as messages though
  135. zeank and we don't want to trigger a push for those
  136. Kev Servers need to not act on hints, because you almost never want a remote client being able to tell your server what to do about things like storing or copying or pushing.
  137. zeank typing notifications could be another
  138. Tobias why would servers trigger push notifications on body-less messages
  139. ralphm has left
  140. blipp has joined
  141. zeank hm, fair point in our case all messages are body less because they are encrypted and have no body in general
  142. zeank it's a proprietary system
  143. zeank just thought it might be useful for others as well
  144. zeank @Kev so the whole XEP is wrong?
  145. Ge0rG I think we need a common ruleset for decisions about pushing, carbon-copying and MAM-archiving of messages.
  146. Kev zeank: I thought 334 said that they were just hints, and entities didn't have to honour them.
  147. Ge0rG Kev: the alternative would be to encode stateful processing rules in the server, right?
  148. Kev But if it really says that a remote client can choose whether my server puts things in my archive, then yes, it's of limited applicability (rather than wrong, as it might still be useful in closed systems), and we need to be very careful about anything depending on it.
  149. zeank yes, they are just "hints", but they are targeting the behaviour of the server, not sure how push and MAM are so different in this regard then
  150. sonny has joined
  151. kalkin has left
  152. Tobias zeank, that proprietary system sounds interesting if it can encrypt even typing notifications, which OMEMO currently can't afaik :)
  153. kalkin has joined
  154. zeank we don't have typing notifications yet, just to be clear ;)
  155. Tobias is much less excited now
  156. zeank :p
  157. Ge0rG Kev: do you happen to have an idea how to make the desired functionality of hints secure and proper, in the context of the right trust boundaries?
  158. Laura has left
  159. Laura has joined
  160. Kev Ge0rG: Put the rules in the server not the remote client, is all I have.
  161. mhterres has joined
  162. Holger As for the copying of messages, doesn't XMPP core allow the sender to control this by addressing the full vs. bare JID and using certain message types?
  163. Kev What gets archived by the server is very clearly a server decision, not a remote client decision.
  164. Kev Holger: Not with carbons.
  165. Tobias right, but there are currently few sensible guidelines on that, not?
  166. Ge0rG Kev: "A message of type 'chat' is not eligible for carbon copies if it contains a body and the body starts with the verbatim string '?OTR'"
  167. Holger Yes then XEP-0280 breaks this, which is why we need hints for that :-)
  168. zeank :p
  169. Ge0rG Holger: actually, the remote party can only choose between "deliver to THIS resource" and "deliver to somebody implementation-defined"
  170. Holger Sure.
  171. Ge0rG and I really despise the last part of it.
  172. Holger I think the desired behavior is to be able to address either an individual device or the account.
  173. Ge0rG because you can't rely on it, but you need to for a proper notification implementation.
  174. jonasw we could all agree that "somebody implementation defined" is "nobody, but everyone interested gets a carbon copy" :)
  175. jere has joined
  176. Ge0rG jonasw: that makes sense if all your clients enable carbons and if you make no client-side semantic difference between "real" messages and carbons
  177. Ge0rG jonasw: but the latter will bite you in a multi-client context.
  178. Ge0rG e.g. in the "I have my phone on the desk and use my desktop" user story.
  179. jonasw Ge0rG: you need to solve that anyways, no matter if you CC everything or not
  180. nicolas.verite has joined
  181. jonasw because the user can switch at any point in time
  182. Ge0rG jonasw: yes, but you can use carbons as a hint
  183. jonasw for the former part: clients who cannot into CC are annoying anyways and they’re gambling on whether they get messages or not as-is
  184. jonasw Ge0rG: but you depend on the server implementation-defined mess if your peer always addresses the bare JID like your client does ;)
  185. nicolas.verite has left
  186. jonasw I’d rather use xep 84 as a hint actually.
  187. Ge0rG > clients who cannot into CC are annoying anyways said the pidgin user
  188. jonasw yes, that means that I must know, Ge0rG.
  189. Martin has joined
  190. narcode has left
  191. Martin has left
  192. Ge0rG It's obviously getting complicated and complicated, on the client side. This is the opposite of the general idea of XMPP, but we could do something like this: on received message: if (message is carbon or sent to bare JID) and (we got presence/activity from another resource of our account recently): delay notification by a 1-minute timer which is cancelled on activity from another client
  193. Martin has joined
  194. Holger Conversations does the "we got presence/activity from another resource" check.
  195. Laura has left
  196. Ge0rG Holger: Conversations does many things that are not codified. While this is good for Conversations users, it makes it harder for future client implementations
  197. Holger A better solution might be looking at the CSI state. Then again, at least desktop clients probably just don't have a good idea of whether they're currently active or not.
  198. Ge0rG What about just reading tea leaves?
  199. Kev I think 'implement Kev's upcoming read-sync XEP' might be a good approach ;)
  200. Kev I really need to write something there, though :/
  201. Tobias Ge0rG, that won't float well with coffee enthusiasts
  202. Mancho has joined
  203. Ge0rG Tobias: they wouldn't even notice, if we provide centralized access to tea-leaves-entropy. Otherwise, we'd need to kindly ask the user to make a photograph.
  204. blipp has left
  205. blipp has joined
  206. kaboom has left
  207. kaboom has left
  208. nyco has joined
  209. kaboom has left
  210. kaboom has left
  211. kaboom has left
  212. goffi has joined
  213. rion has joined
  214. efrit has joined
  215. goffi has left
  216. goffi has joined
  217. jubalh has joined
  218. jubalh has left
  219. nyco has joined
  220. Ge0rG Kev: the read-sync sounds like a more explicit way to tell other clients that messages have been read. I'm not sure if it will also help in the notification-delay/prevention situation
  221. Kev Well, it helps, because it's an explicit way of knowing that a message doesn't need to be notified (or that a notification can be cleared), but it doesn't prevent you needing some logic somewhere about delaying notifications, indeed.
  222. Kev I think that's just the cost of doing business.
  223. Ge0rG Kev: will it be similar to chat state notifications?
  224. Kev Not particularly, no :)
  225. kaboom has left
  226. efrit has joined
  227. nicolas.verite has joined
  228. nicolas.verite has left
  229. Valerian has left
  230. Valerian has joined
  231. Valerian has left
  232. kaboom has left
  233. mhterres has left
  234. Guus has left
  235. lloydwatkin has joined
  236. kaboom has left
  237. kaboom has left
  238. kaboom has left
  239. kaboom has left
  240. kaboom has left
  241. kaboom has left
  242. kaboom has left
  243. Ge0rG Kev: why not?
  244. Kev Because CSN go to the other party, and read sync goes to your server, and from there to your clients?
  245. Ge0rG Hm. So it's an account-centric thing.
  246. kaboom has left
  247. Kev Yes.
  248. jonasw Kev: you could send CSN to your own bare JID :-)
  249. jonasw and let carbons do the rest
  250. Ge0rG jonasw: it would get reflected to yourself.
  251. jonasw exactly
  252. Kev jonasw: That doesn't work for saying which messages are read, though.
  253. Ge0rG there is no xmpp primitive to "send something to all the other clients of yours"
  254. jonasw Kev: yes, but isn’t there something for that already?
  255. jonasw Ge0rG: ah, that’s what you mean
  256. jonasw Ge0rG: well, we may need one
  257. Ge0rG one could use PEP
  258. jonasw ugh
  259. Tobias Ge0rG, with carbons there is, not?
  260. jonasw Tobias: all *other* clients
  261. Ge0rG Tobias: what'd be your destination JID? the server?
  262. Tobias Ge0rG, your own bare JID? :)
  263. Ge0rG message to "account-domain.xmpp" would get carboned to all other clients
  264. Ge0rG Tobias: no. you'd get the message twice
  265. jonasw on each resource (once as <sent/>, once as <received/>)
  266. Ge0rG Tobias: first the 'sent' carbon, then the delivered message/carbon
  267. Ge0rG except on the sending client, it would only get one copy
  268. Tobias Ge0rG, "at least once" semantic is easier than "exactly once"
  269. Ge0rG Tobias: but using the "most probably twice" semantics is just wrong.
  270. Holger What's wrong with PEP BTW?
  271. jonasw redundancy!
  272. nicolas.verite has joined
  273. nicolas.verite has left
  274. suzyo has left
  275. suzyo has joined
  276. kaboom has left
  277. nyco has joined
  278. kalkin has left
  279. kaboom has left
  280. kalkin has joined
  281. lskdjf has joined
  282. kaboom has left
  283. kaboom has left
  284. kaboom has left
  285. nyco has joined
  286. kaboom has left
  287. Mancho has left
  288. Alex has joined
  289. nicolas.verite has joined
  290. Alex has left
  291. Holger has left
  292. nicolas.verite has left
  293. lskdjf has left
  294. Tobias and that would be the last XMPP related fosdem talk tweeted about
  295. kaboom has left
  296. Guus which reminds me: we could use a new post for the blog. Anyone interested in writing one?
  297. sonny has joined
  298. sonny has joined
  299. nicolas.verite has joined
  300. Ge0rG Guus: what should it be about?
  301. kaboom has left
  302. Tobias Ge0rG, federal reserve, rainforest, and that sort of thing
  303. Ge0rG Tobias: xsf world domination plans? Because it's a greater challenge if we announce the plans in advance?
  304. nicolas.verite has left
  305. Tobias we already have a retracted XEP for that :P that should be enough of an announcement
  306. kaboom has left
  307. kaboom has left
  308. kaboom has left
  309. Valerian has joined
  310. nyco has joined
  311. Ge0rG Retracted? People don't even care about experimental...
  312. kaboom has left
  313. Guus Ge0rG: I have no specific agenda, other than trying to help make sure that the blog gets regular updates. So far, I've reached out to Daniel for an OMEMO post, and Rikard for an IoT one.
  314. Tobias well..it's kind of hidde
  315. Tobias *hidden
  316. kaboom has left
  317. Yagiza has left
  318. Guus If you have a good idea, feel free to submit something. You can easily add a blog post via a PR on the website, or send it to me by text, and I'd be happy to post on your behalf.
  319. Tobias Ge0rG could write about how snarky comments in open standards communities result in improved protocols ;)
  320. Ge0rG Guus: sounds good to me. I'm sure nobody wants ME to write a guest post.
  321. Tobias or more seriously, about his efforts on improving UX and usability
  322. Guus Ge0rG: guest? you're a member, right?
  323. Ge0rG Guus: right. But I'm not a regular contributor to the blog.
  324. Ge0rG Tobias: im sure that would get flagged immediately because of neutrality concerns.
  325. Tobias Ge0rG, a blog without regular posts doesn't have any regular contributors at all
  326. Tobias Ge0rG, we could neutralize it
  327. Guus Ge0rG: I wonder if anyone considers themselves a 'regular blogger' here. There's people that posted more than others, but that's more because of a lack of input by the others. :)
  328. nicolas.verite has joined
  329. Ge0rG Tobias: also, what would be the target audience? It seems that it's widely irrelevant to users, and there are two camps of developers: the ones who don't care, and the ones who have no time to improve
  330. Tobias yeah...try to channel that optimism into words for the blog post
  331. nicolas.verite has left
  332. Guus (no response, which presumably means he's drafting a post!)
  333. Guus eyes dwd
  334. Ge0rG I feel a bit like Aragorn, having his motivational speech before the fight of helm's deep. Except there is no army. Actually, now that I think of it, it's probably more like Tyrion Lannister's "don't fight for your king" speech.
  335. Guus so, you're good with words...
  336. Guus Ge0rG: You might be making a bit to much of it :)
  337. nyco has joined
  338. Ge0rG Guus: this is probably a sign that I'm overqualified ;)
  339. Guus Ge0rG: Perhaps. You should take this as a challange to see if you can lower yourself to our level!
  340. Tobias Ge0rG, it might result in more users demanding better usability for their clients, who knows
  341. vurpo has left
  342. Ge0rG Tobias: quite seriously, I'm not sure how to frame the whole thing. "Here is this new set of ideas how to make XMPP better"?
  343. vurpo has joined
  344. vurpo has left
  345. vurpo has joined
  346. vurpo has left
  347. Ge0rG Tobias: the obvious question for the readers would be "why are they talking about it, instead of just doing it"
  348. Guus Ge0rG: perhaps frame the fact that we need a solution for a probem? "Clients look aweful, we could use an effort to stream line things. We've started doing that at xyz"
  349. Guus (but nicer)
  350. vurpo has joined
  351. Tobias Ge0rG, well..it makes little sense talking here about it, as you already made your point and few new people come here
  352. vurpo has left
  353. Tobias i think our blog has a wider target audience than this room
  354. dwd Also more tweetable.
  355. Guus Tobias: do you have access to pageview stats?
  356. Tobias no
  357. vurpo has joined
  358. Tobias i'd also would like to have access to xmpp twitter account analytics...to see if all that tweeting increased out followers (it did, but how much)
  359. Ge0rG Guus: the next problem is: I'd really like to use specific examples of how things can be improved, namely conversations and (to a degree) yaxim. But then it'd result in something like https://yaxim.org/blog/2017/01/31/yaxim-0-dot-9-security-easy-xmpp/ and obviously violate XSF neutrality in a way that's hard to neutralize
  360. vurpo has left
  361. Guus Ge0rG: I'd almost consider that a follow-up post. I'm not to bothered by the neutrality thing (but others disagree), but, referencing to Yaxim as an example should be fine I think - more so if you can reference another implementation too
  362. vurpo has joined
  363. vurpo has left
  364. vurpo has joined
  365. Ge0rG I fear that even mentioning https://github.com/ge0rg/easy-xmpp-invitation which is really client-agnostic (except for the hardcoded list of yaxim+conversations) would be seen as a violation
  366. Guus There's always goign to be someone that sees something as a violation of something. If that stops people, nothign would get done.
  367. jonasw Guus: +1
  368. Ge0rG Guus: I just extrapolate the previous feedback I've received from XSF members to my public statements about the state of XMPP.
  369. Ge0rG Guus: if I disregard that, I can imagine writing a call-to-action post about Easy XMPP. And I'll try hard to make it as positive as possible
  370. Guus Ge0rG: you might generate more feedback than others here :)
  371. Ge0rG Guus: I'm not sure if the feedback I generate is of the right sort.
  372. vurpo has left
  373. vurpo has joined
  374. Guus Ge0rG: I'd love for you to draft a rough outline of a post. We can do a PR on that, and have some reviews.
  375. Ge0rG Guus: deal
  376. Guus awesome, thanks!
  377. Guus and again - I think it might be a good idea to smear this topic out over a couple of posts. One that describes the problem and the approach taken to start working on a fix - another one that describes a few of the fixes, and more that illustrate how individual implementations are now improved. Then, a final one where you claim victory.
  378. daniel has left
  379. Guus Ge0rG: there might be a handful of posts and world dominition in this for you ;)
  380. daniel has joined
  381. Ge0rG Guus: I don't aim for world domination
  382. Ge0rG Guus: all I want is a nice big yacht. :D
  383. vurpo has left
  384. vurpo has joined
  385. Guus Ge0rG: if you want, I can put you in contact with one of my Nigerian royal friends who badly need to transfer money out of the country? Supposedly, that's a win/win and risk-free.
  386. Ge0rG Guus: I think I'm already in negotiations with that person
  387. jonasw :)
  388. Guus Ge0rG: I am sure then that your ship will litererally and figuratively come in any minute now.
  389. vurpo has left
  390. Guus Tobias: could you do a review of https://github.com/xsf/xmpp.org/pull/185 ?
  391. Guus I think it's ready to merge now (finally)
  392. Tobias will do this evening
  393. vurpo has joined
  394. Guus Thanks
  395. vurpo has left
  396. vurpo has joined
  397. jonasw is my dynamic list generation code live already?
  398. Guus jonasw: I think so, yes.
  399. jonasw then we can start the attack on the quality of listed software, right?
  400. Guus I fixed the problem that prevented a bunch of commits to go live, after which the changes that were visible to me popped up.
  401. jonasw with requiring projects to re-request their listing and so on
  402. Guus jonasw: I see a blogpost in your immediate future :D
  403. jonasw ugh
  404. jonasw pelican-based blog?
  405. Guus yup
  406. jonasw can do
  407. Guus tx
  408. jonasw but I might forget
  409. Guus add something here: https://github.com/xsf/xmpp.org/tree/master/content/posts/blog
  410. jonasw I’m super tired right now, not sure if writes to my task memory persist currently :)
  411. Guus no worries, I'll be here to haun...remind you.
  412. Yagiza has joined
  413. Yagiza has joined
  414. Ge0rG Guus: https://github.com/xsf/xmpp.org/pull/274 - I'm sure this will ignite a discussion.
  415. vurpo has left
  416. vurpo has joined
  417. vurpo has left
  418. intosi has left
  419. vurpo has joined
  420. suzyo has left
  421. blipp has left
  422. Yagiza has joined
  423. intosi has joined
  424. daniel has left
  425. sonny has joined
  426. daniel has joined
  427. sonny has joined
  428. kalkin has left
  429. kalkin has joined
  430. Yagiza has left
  431. Flow has joined
  432. Alex has joined
  433. Guus Thanks Ge0rG. I responded on github
  434. Yagiza has joined
  435. Ge0rG Guus: the verbatim tldr will get out, but I'm used to make the first paragraph of long posts effectively a tldr
  436. suzyo has joined
  437. Guus Ge0rG: that might be a sign that the text is to long for a blogpost :)
  438. Guus but, a matter of personal preference, probably
  439. Guus My main point is that I really dislike 'tl;dr'
  440. Ge0rG Guus: I'd say it is a sign of respect to the prospective reader. I tell them in a single paragraph if the remaining part worth reading.
  441. Ge0rG *is
  442. Guus personal preference. :)
  443. Guus go for it - it's your text.
  444. Flow has left
  445. Ge0rG Guus: thanks for your feedback. I'll update the pr when I find some more time
  446. blipp has joined
  447. Zash has joined
  448. Alex has left
  449. Alex has joined
  450. Alex has left
  451. uc has left
  452. uc has joined
  453. mimi89999 has joined
  454. Yagiza has left
  455. mimi89999 has joined
  456. kaboom has left
  457. kaboom has left
  458. kaboom has left
  459. kaboom has left
  460. intosi has left
  461. kaboom has left
  462. jonasw Guus: you could call it "Abstract", is that better?
  463. intosi has joined
  464. Ge0rG jonasw: what's wrong with an implicit "summary"
  465. jonasw I don’t know.
  466. kaboom has left
  467. kaboom has left
  468. kaboom has left
  469. kaboom has left
  470. kaboom has left
  471. mimi89999 has left
  472. Alex has joined
  473. bjc has joined
  474. mimi89999 has left
  475. bjc has left
  476. bjc has joined
  477. mimi89999 has joined
  478. mimi89999 has left
  479. mimi89999 has left
  480. mimi89999 has left
  481. kaboom has left
  482. bjc has left
  483. bjc has joined
  484. kaboom has left
  485. kaboom has left
  486. kaboom has left
  487. Valerian has left
  488. kaboom has left
  489. kaboom has left
  490. kaboom has left
  491. kaboom has left
  492. kaboom has left
  493. kaboom has left
  494. kaboom has left
  495. kaboom has left
  496. winfried has left
  497. kaboom has left
  498. kaboom has left
  499. dwd So... The only point where mam:2 makes any difference is in the one place where the XML namespace is not used.
  500. Holger has left
  501. Holger has left
  502. nyco has joined
  503. nicolas.verite has joined
  504. dwd ... and this has no impact *at all* on MIX.
  505. nicolas.verite has left
  506. kaboom has left
  507. lskdjf has joined
  508. mimi89999 has joined
  509. kaboom has left
  510. Holger has left
  511. mimi89999 has joined
  512. mimi89999 has left
  513. jere has joined
  514. kaboom has left
  515. mimi89999 has joined
  516. kaboom has left
  517. Yagiza has joined
  518. kaboom has left
  519. kaboom has left
  520. kaboom has left
  521. Yagiza has left
  522. Alex has left
  523. Alex has joined
  524. Yagiza has joined
  525. Tobias has joined
  526. Holger has left
  527. Zash has left
  528. Zash has joined
  529. Mancho has left
  530. Holger has left
  531. Holger has left
  532. Alex has left
  533. bear has joined
  534. waqas has joined
  535. jere has joined
  536. Kev Question, UX experts.
  537. Valerian has joined
  538. Kev Hypothetically if you were writing an XMPP client and wanted the experience when opening a chat from within a MUC to not suck (i.e. to open to the real JID instead of the room JID) in the usual case, how (if at all) would you protect it against spoofing on untrusted remote MUC services?
  539. jere has joined
  540. lskdjf has left
  541. Ge0rG Kev: you are talking about private chats?
  542. dwd Hypoethetically, if I were using an untrusted remote MUC service, how stupid would I be to be sending it messages anyway?
  543. Kev It depends on the trust, I think?
  544. Ge0rG with my UX hat: I'd just open a chat wit the bare JID advertised in the MUC. with my security hat: what dwd said.
  545. dwd Kev, What are you trusting it to do and not do?
  546. Kev I mean, I may trust my inane discussions to something, but not want it to be able to lie about someone's real JID and have me spam a helpless person directly.
  547. Ge0rG Kev: this is the same security concerns I'm pondering about for some weeks already, in the context of mediated vs. direct MUC invitations
  548. dwd Kev, That's not a security concern.
  549. Kev Turning occupants into a DDoS probably is :)
  550. dwd Kev, That's a concern you might annoy someone, not a concern about leaking information.
  551. Kev I don't think I said anything about it being a concern leaking information, did I?
  552. Kev (Or even security)
  553. dwd Kev, Hardly; you're reliant on having users PM people. And if you're a remote MUC, you can spoof the PMs directly, causing people to get any responses.
  554. Kev You can't spoof the PM as being from my server, though.
  555. dwd Kev, No, but I can spoof them as being from you, via a MUC.
  556. Kev Yes. I'm thinking about people not in the room at all.
  557. dwd Kev, Who isn't in the room?
  558. Kev You annoy me, so I tell all jabber.org MUCs to say that every occupant's real JID is yours, and then you get spammed every time someone tries to send a PM.
  559. dwd Kev, That was you?
  560. dwd Kev, You git.
  561. Kev I do.
  562. Kev Although I don't tend to use it as a verb.
  563. jonasw has left
  564. Kev Regardless, this feels like it might not be ideal, to me.
  565. dwd Kev, True, that would be subversion.
  566. Kev Very good.
  567. jonasw has left
  568. dwd Kev, OK. So I think the "real-jid" issue here remains irrelevant. It's one case where a (popular) MUC service could abuse trust.
  569. Kev I'm pondering possible options being "Meh, you're in the MUC, you're showing some trust", "Do it if it's someone in your roster" (so you can probably work through the social issue if it gets spoofed), "do it if it's a local service". (where 'it' is opening to the real JID).
  570. Ge0rG Kev: I think the only sane solution to that is having MUC presence signed by the user's account key.
  571. Kev There's also revealing your own JID in the case that you're a moderator in a room.
  572. dwd Ge0rG, Seems fair.
  573. Zash How do you know what account key is the right one?
  574. dwd Kev, I think any of your options is fine.
  575. Kev Certainly the irritation of having PMs outside your normal flow is significant and I want to fix it.
  576. dwd Zash, By asking the MUC for the public key of its occupant of course. Duh!
  577. Zash MUC can't lie
  578. SamWhited MUC real-JID dial-back verification? When you want to verify a JID in a MUC you send them a token (through the MUC), and then they echo it back via their real-JID. I'm not sure this is necessary either, but it's fun to think about.
  579. dwd Zash, Evil-MUC-bit?
  580. Ge0rG Zash: you query the bare JID for a signed presence, or check your roster
  581. Kev SamWhited: Sure, but that only works if you've running over jidnssec, which no-one is :)
  582. Ge0rG Kev: may I point you to https://mail.jabber.org/pipermail/standards/2017-January/032021.html
  583. SamWhited Kev: jidnssec? Not sure if real thing or a joke I didn't get…
  584. Tobias it's a DNSSEC deployment joke
  585. SamWhited Oh, heh, right
  586. Kev SamWhited: It's a joke. You mentioned dialback, which is a fine thing to use for S2S as long as you have dnssec.
  587. nicolas.verite has joined
  588. dwd (And you also use TLS).
  589. nicolas.verite has left
  590. Tobias and .im domains can't do DNSSEC because people from the isle of man are afraid of locsk
  591. Tobias *locks
  592. SamWhited I think it works in this case though if you trust the s2s connection at all
  593. SamWhited (the s2s connection doesn't have to do dialback, I just used that name because they're echoing an HMAC or something back at you)
  594. Kev Yes, it's not a stupid idea.
  595. SamWhited You'd have to do it two ways though for mutual verification, so there's probably a better way
  596. Ge0rG SamWhited: like... distributed MUCs
  597. Ge0rG or maybe we need to replace JIDs with pubkey-based identities
  598. SamWhited Ge0rG: I'm assuming this was a question for a MUC implementation today, not for a future-widely-used-thing implementation.
  599. ralphm has left
  600. Ge0rG or we just ignore the problem and pretend it doesn't exist.
  601. Zash Let's build an elaborate PKI!
  602. Zash The world needs more of those
  603. Ge0rG Or we introduce a "security level slider" into our apps, ranging from "I don't care, just make it work" to "I'm ultraparanoid"
  604. Kev (And thanks all, BTW)
  605. dwd Ge0rG, Excellent. The world need more security options that users don't understand the implications of.
  606. Ge0rG Kev: so have you come to a conclusion how to do it?
  607. Zash Ge0rG: Key based identity would be interesting, but I don't think that's even XMPP 2, that's gotta be something completely new.
  608. Ge0rG dwd: most users don't understand the implications of any of the security options provided to them.
  609. Kev Ge0rG: I think the conclusion is "Meh, just do it"
  610. Ge0rG Zash: TOX maybe. It's got an "X" in it at least.
  611. Ge0rG Kev: this conclusion was also reached at the end of the lively security debate in the thread I pointed to.
  612. Kev FWIW, for mediated invitations, Swift shows it but warns that it could have been spoofed.
  613. Kev I can't remember if we replied to the thread or not.
  614. Tobias has left
  615. Kev But the whole mediated invite thing is horrid anyway and everyone needs to just use direct invites :)
  616. Ge0rG Kev: direct invites don't auto-add the receiver to the MUC affiliation
  617. nicolas.verite has joined
  618. mimi89999 has joined
  619. Tobias Ge0rG, jet fuel can't melt steel beams
  620. Tobias Ge0rG, i think setting up specific affiliations for participants is a quite rare use case
  621. nicolas.verite has left
  622. nyco has left
  623. Ge0rG Tobias: I want to have a private group chat with my family members. Do you have an idea of the steps I have to perform to achieve that, client-side?
  624. Ge0rG Hint: none of them are described in 0045.
  625. Kev Ge0rG: You open Swift, you choose 'start chat' and drag all of them into it? :)
  626. Tobias just create a UUID MUC and invite the people you want to join
  627. Ge0rG Tobias: but I need to make that MUC invite-only and hidden.
  628. Ge0rG I think there are some forms to enable that.
  629. Tobias hidden yes, invite-only (why, who will know the JID?)
  630. vurpo has left
  631. Ge0rG Tobias: and then I need to add all the folks into the affiliation
  632. vurpo has joined
  633. Tobias has left
  634. Ge0rG Tobias: so you are using the JID as a password?
  635. tim@boese-ban.de has joined
  636. Tobias basically, yes
  637. Ge0rG Am I the only one who thinks this is significantly worse than following invites from a remote untrusted MUC?
  638. Tobias Ge0rG, what's your fear? people guessing the JID? that one of the participants leaks the JID?
  639. Ge0rG Tobias: accidental leaking of the JID
  640. Tobias how?
  641. Ge0rG Tobias: pastebinned client debug logs, server bugs
  642. Tobias what says the way you'd accidentially leak your JID wouldn't also leak the password if it were password protected?
  643. Ge0rG Tobias: JIDs are not generally considered "secret"
  644. Ge0rG Tobias: by violating that assumption, you are bringing your users one step closer to the abyss
  645. Ge0rG Tobias: leaking a password requires gross negligence
  646. SamWhited User probably shouldn't see or know that a JID exists (especially if it's really just a UUID), so I don't see why it matters.
  647. Tobias well...if you want to provide a true sense of security to your users you should do OMEMO in the MUC anyway
  648. Ge0rG Tobias: my point is that it's good to have additional guards
  649. Ge0rG and "closed affiliation" is one such
  650. mimi89999 has left
  651. mimi89999 has joined
  652. Ge0rG has left
  653. vurpo has left
  654. vurpo has joined
  655. vurpo has left
  656. vurpo has joined
  657. Holger Tobias: For OMEMO you want to have the group members affiliated with the room anyway, though :-)
  658. Holger And simply for listing the offline members of your group chat.
  659. Holger And because you want that anyway, you can just as well make the room members-only (since *this* step is simple).
  660. Tobias i wish there were a XEP for taht
  661. Tobias *that
  662. Holger For what?
  663. Alex has left
  664. Ge0rG Holger: for creating a members-only private MUC, I suppose
  665. Ge0rG I'm going to add that to yaxim soon, and write it down in the process. I'm interested in such an XEP as well
  666. Ge0rG Sufficiently interested to actually write it, if nobdy else *cough*daniel*cough* jumps in.
  667. Ge0rG https://wiki.xmpp.org/web/Easy_Group_Chats is the first iteration
  668. Ge0rG I've had another crazy idea: to use the "long description" of the MUC to store a link to an http-uploaded avatar
  669. Holger I think it's all in 0045 even though it wasn't written with that use-case in mind.
  670. Ge0rG Holger: you must be talking of https://xmpp.org/extensions/xep-0045.html#createroom-instant
  671. Holger (Except for an option to enable MUC MAM for servers who want to make this configurable.)
  672. Holger Ge0rG, no I wasn't suggesting an instant room. Maybe I'm missing something but what I have in mind is simply using a plain members-only room with MAM for private/presence-less group chat.
  673. Ge0rG Holger: and where is that written down in the XEP?
  674. Ge0rG I'm not quite sure what the use case of the 0045 "instant room" is, except for being comparably bad to instant soup.
  675. Holger Only the building blocks are there of course. It doesn't say "to create a private group chat, do this and that".
  676. Ge0rG Holger: but I want it to be in there.
  677. Ge0rG Holger: your statement is comparable to "all the building blocks for a group chat are in rfc 6120+21" :P
  678. Holger Ge0rG: I don't think that's comparable; 0045 adds protocol on top of the RFCs while my point is that you don't really need anything on top of 0045. But I see how a document explaining how to use 0045 to implement group chat would be useful.
  679. SouL has left
  680. Ge0rG Holger: I would even 1-up that and say that 0045 should contain it
  681. Ge0rG maybe the council will not be strictly opposed to adding a new informational section to 0045
  682. Holger Sounds good to me.
  683. Ge0rG But first, I need to sort out #418 and #436
  684. Bunneh Ge0rG: XEP-0280: Add 'Usability Considerations' section #418 https://github.com/xsf/xeps/pull/418
  685. Holger And maybe #204 should be sorted out first as well :-)
  686. Bunneh Holger: XEP-0045: Define option name for enabling/disabling MAM #204 https://github.com/xsf/xeps/pull/204
  687. suzyo has joined
  688. Ge0rG Holger: btw, being a server developer. Would you rather prefer more rules in 0280 clarifying what to do with [xep 0184] acks and [xep 0333] states, or have those two contain explicit <copy> hints?
  689. Holger I think adding more rules to 0280 modules is wrong.
  690. Zash +1
  691. MattJ +2
  692. jonasw https://xkcd.com/1810/ is sad.
  693. intosi +3
  694. Alex has joined
  695. Ge0rG case in point: 0184 does not mandate to use type=chat
  696. Vinilox has left
  697. Holger Indeed. I use local patches that add rules to fix such things :-/
  698. Ge0rG but Kev said that we shall not rely on remote clients telling us what to do
  699. Holger And I disagree, at least when it comes to addressing accounts vs. individual devices.
  700. dwd has left
  701. SamWhited Does anyone here have any idea how communication with IANA should work? I've been googling things like "IANA registration procedure" and "IANA expert review rules" and so far everyting is completely undocumented and worthless as usual⁢… *grumble, grumble*
  702. Zash Email someone. ???, PROFIT!
  703. SamWhited I found one old document that explicitly said that IANA procedures were currently not documented, so I'm just about ready to assume taht's still right, everything is tribal knowledge, and then just start spamming people until someone updaets the registry.
  704. Guus hargh - the US went to/from DST?
  705. intosi Yup.
  706. zeank has left
  707. SamWhited Guus: Yup; be warned, everyone on this side of the pond is confused and grumpty today (actually, that's most days, but *more so* today)
  708. Guus Which explains why this meet is pretty empty...
  709. intosi They probably measure DST in furlongs per fortnight or something.
  710. Guus It's bad enough that we have DST in the first place - but everyone having a different date when it kicks in does not help either...
  711. suzyo has left
  712. intosi DST: collectively tricking your employers into accepting it's okay to start and leave an hour earlier.
  713. suzyo has joined
  714. Lance has joined
  715. Ge0rG on a slightly related note, I'd really love board meetings to be one hour earlier.
  716. Alex has left
  717. Vinilox has joined
  718. nicolas.verite has joined
  719. nicolas.verite has left
  720. suzyo has joined
  721. jubalh has joined
  722. suzyo has joined
  723. bjc has joined
  724. bjc has joined
  725. jere has left
  726. jere has joined
  727. SamWhited has left
  728. kalkin has left
  729. intosi has left
  730. vurpo has left
  731. vurpo has joined
  732. SamWhited Oh typical, and the IANA contact apparently doesn't work for Cisco anymore so the only email listed is broken.
  733. nicolas.verite has joined
  734. kalkin has joined
  735. SamWhited Found a personal email; let's try that.
  736. nicolas.verite has left
  737. SamWhited Oh no, matt already forwarded it. Convenient.
  738. intosi has joined
  739. vurpo has left
  740. vurpo has joined
  741. Alex has joined
  742. ralphm has left
  743. vurpo has left
  744. vurpo has joined
  745. Holger has left
  746. intosi has left
  747. Yagiza has left
  748. Guus has left
  749. blipp has left
  750. blipp has joined
  751. goffi has left
  752. suzyo has left
  753. mimi89999 has left
  754. ilmaisin has joined
  755. intosi has joined
  756. mimi89999 has left
  757. Martin has left
  758. SamWhited has left
  759. mimi89999 has left
  760. Guus has left
  761. Steve Kille has left
  762. Steve Kille has left
  763. Steve Kille has joined
  764. Guus has left
  765. vurpo has left
  766. vurpo has joined
  767. jubalh has left
  768. jubalh has joined
  769. nyco has joined
  770. SouL has left
  771. Zash has left
  772. rion has left
  773. Zash has joined
  774. Zash has left
  775. Zash has left
  776. Alex has left
  777. Alex has joined
  778. Valerian has left
  779. Alex has left
  780. Alex has left
  781. Alex has left
  782. SamWhited has left
  783. Alex has left
  784. Valerian has joined
  785. intosi has left
  786. Guus has left
  787. Alex has left
  788. tim@boese-ban.de has joined
  789. tim@boese-ban.de has joined
  790. Valerian has left
  791. Guus has left
  792. efrit has joined
  793. Alex has left
  794. Valerian has joined
  795. goffi has joined
  796. Guus has left
  797. alhiti has joined
  798. alhiti has left
  799. Lance has left
  800. kalkin has left
  801. Alex has left
  802. Laura has joined
  803. Laura has left
  804. Neustradamus has left
  805. daniel has left
  806. Alex has joined
  807. nyco has joined
  808. rion has joined
  809. Alex has left
  810. jonasw has left
  811. Ge0rG has left
  812. nicolas.verite has joined
  813. jubalh has left
  814. nicolas.verite has left
  815. Alex has joined
  816. suzyo has joined
  817. Alex has left
  818. nicolas.verite has joined
  819. alhiti has joined
  820. jubalh has joined
  821. alhiti has left
  822. kaboom has left
  823. Mancho has left
  824. kaboom has left
  825. Guus has left
  826. suzyo has left
  827. Valerian has left
  828. Valerian has joined
  829. Valerian has left
  830. Valerian has joined
  831. Valerian has left
  832. kalkin has left
  833. Valerian has joined
  834. nicolas.verite has left
  835. nyco has joined
  836. uc has left
  837. uc has joined
  838. Ge0rG has left
  839. Valerian has left
  840. kaboom has left
  841. nyco has joined
  842. jonasw has left
  843. nicolas.verite has joined
  844. Valerian has joined
  845. moparisthebest has left
  846. nicolas.verite has left
  847. rion has left
  848. rion has joined
  849. tim@boese-ban.de has joined
  850. tim@boese-ban.de has joined
  851. efrit https://xkcd.com/1810/
  852. suzyo has joined
  853. moparisthebest has joined
  854. nyco has joined
  855. rion has left
  856. rion has joined
  857. rion has left
  858. rion has joined
  859. kaboom has left
  860. SamWhited has left
  861. kaboom has left
  862. lskdjf has joined
  863. lskdjf has left
  864. kaboom has left
  865. nyco has joined
  866. kaboom has left
  867. kaboom has left
  868. kaboom has left
  869. kaboom has left
  870. kaboom has left
  871. nicolas.verite has joined
  872. Valerian has left
  873. kaboom has left
  874. kaboom has left
  875. kaboom has left
  876. kaboom has left
  877. rion has left
  878. SouL has left
  879. kaboom has left
  880. kaboom has left
  881. efrit has joined
  882. nicolas.verite has left
  883. Mancho has left
  884. kaboom has left
  885. Alex has left
  886. kaboom has left
  887. kaboom has left
  888. tim@boese-ban.de has joined
  889. tim@boese-ban.de has joined
  890. sezuan has left
  891. kaboom has left
  892. Alex has joined
  893. Alex has left
  894. suzyo has left
  895. Mancho has left
  896. nicolas.verite has joined
  897. intosi has joined
  898. daniel has left
  899. daniel has joined
  900. sezuan has left
  901. kaboom has left
  902. SouL has left
  903. kaboom has left
  904. SouL has left
  905. kaboom has left
  906. kaboom has left
  907. waqas has left
  908. kaboom has left
  909. jubalh has left
  910. Guus has left
  911. Alex has left
  912. vurpo has left
  913. vurpo has joined
  914. winfried has left
  915. jere has left
  916. Lance has joined
  917. sonny has joined
  918. sonny has joined
  919. Alex has joined
  920. nyco has joined
  921. Tobias has joined
  922. Lance has left
  923. efrit has joined
  924. nicolas.verite has left
  925. sezuan has left
  926. nyco has joined
  927. nicolas.verite has joined
  928. Alex has left
  929. intosi has left
  930. nicolas.verite has left
  931. kaboom has left
  932. kaboom has left
  933. vurpo has left
  934. vurpo has joined
  935. vurpo has left
  936. vurpo has joined
  937. vurpo has left
  938. efrit has joined
  939. nyco has joined
  940. vurpo has joined
  941. Mancho has left
  942. moparisthebest has joined
  943. Mancho has left
  944. nicolas.verite has joined
  945. sonny has left
  946. sonny has joined
  947. moparisthebest SamWhited: sorry, I can't help but feel this is all my fault :-)
  948. blipp has left
  949. blipp has joined
  950. kaboom has left
  951. goffi has left
  952. nicolas.verite has left
  953. Holger has left
  954. Holger has left
  955. Holger has left
  956. Holger has left
  957. Holger has left
  958. Holger has left
  959. Holger has left
  960. Holger has left
  961. Holger has left