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