XSF logo XSF Discussion - 2019-02-05


  1. pep. How bad would it be to s/http:\/\/xmpp\.org/https:\/\/xmpp\.org/ in the xeps repo? Do I have any chance of breaking normative language
  2. Zash You'll find that one place where someone used http://xmpp.org in a xmlns
  3. pep. I feel http://jabber.org is used most often (when not urn:xmpp), but yeah I guess
  4. Zash ...
  5. Zash xeps$ ack http://xmpp.org/protocol inbox/sxe.xml 262: <query xmlns='http://xmpp.org/protocol/disco#info'/> 268: <query xmlns='http://xmpp.org/protocol/disco#info'> xep-0284.xml 268: <query xmlns='http://xmpp.org/protocol/disco#info'/> 274: <query xmlns='http://xmpp.org/protocol/disco#info'>
  6. pep. grep
  7. pep. *great
  8. pep. pff
  9. Zash That's gotta be a typo for jabber.org/protocol tho?
  10. pep. Ok I'll be careful then
  11. pep. Probably in examples?
  12. pep. let's see
  13. Zash xep-0397.xml has a bunch of xmlns="https://xmpp.org/....
  14. pep. that's fine, I won't change this one :P
  15. pep. But yeah that should be fixed
  16. Zash https://xmpp.org/extensions/xep-0284.html#host this points to xep 30, so looks like a mistake
  17. pep. With a bit less effort we should probably add HSTS first
  18. pep. The 301 is already there
  19. karoshi1 has left
  20. pep. What about: "<p>The &REGISTRAR; shall add 'urn:xmpp:idle:1' to its registry at <link url='https://xmpp.org/registrar/namespaces.html'>https://xmpp.org/registrar/namespaces.html</link>.</p>" ? Is that normative? the registrar uri
  21. Zash PR'd
  22. pep. (I changed to https in this quote)
  23. Zash It is technically a completely different URL, that doesn't have to have the same content as the http: URL
  24. remko has joined
  25. pep. err, I don't have access to the nginx that should do HSTS, do I
  26. pep. This docker thing only serves 80
  27. Zash <meta name='horrible-hack-no-372' http-equiv='strict-transport-security' value='max-age=infinity'>
  28. pep. :/
  29. labdsf has joined
  30. Neustradamus has left
  31. pep. Technically I can already do that with the nginx inside, but that will send it on both http and https, and it's invalid on http (or just useless?)
  32. Zash wasn't 80 just serving a redirect?
  33. pep. I should be able to check for x-forwarded-proto maybe
  34. pep. Zash, 80, as seen from the outside, yes
  35. pep. Not from the container
  36. Zash so
  37. Zash the outside won't see hsts on port 80?
  38. pep. So?
  39. pep. HSTS SHOULD(MUST?) only be on https
  40. Zash so if the container spits it out on port 80, which is reverse-proxied to port 443 with tls
  41. Zash then it should all be in order
  42. moparisthebest Browsers will ignore it over http
  43. pep. It will also spit it on http. But then maybe as I said I can check for X-Fowarded-For
  44. pep. moparisthebest, sure
  45. moparisthebest So it's fine to send it either way
  46. pep. browsers are as compatible as one can be, because the web if full of crap
  47. moparisthebest The point is they never visit http again anyhow?
  48. pep. I just like to do things properly :x
  49. moparisthebest Don't forget to set up a redirect to https from http, and put it in the preload list :)
  50. pep. it's already there
  51. Zash pep.: if the public port 80 is configured to only s/http/https/ then I don't see how anyone can get hsts via http
  52. moparisthebest Do things properly, the web, bahaha :)
  53. pep. So I might as well ask iteam directly
  54. pep. And not put this hack in the xeps repo
  55. pep. Zash, true.
  56. pep. Still that's probably not something for the xeps repo
  57. pep. Maybe the website, but I feel that should go in the host's conf
  58. Zash Is there a container that contains the conainer-container that holds the 7th proxy?
  59. jmpman has joined
  60. UsL has left
  61. UsL has joined
  62. pep. Anyway, I should stop procrastinating the procrastination
  63. pep. Anyway, I should stop procrastinating procrastination
  64. Alex has left
  65. remko has left
  66. Zash has left
  67. rtq3 has left
  68. rtq3 has joined
  69. mimi89999 has joined
  70. rtq3 has left
  71. rtq3 has joined
  72. j.r has left
  73. j.r has joined
  74. Neustradamus It will be nice to have same base for all without www. etc
  75. lskdjf has joined
  76. waqas has joined
  77. mimi89999 has joined
  78. moparisthebest has left
  79. jmpman has joined
  80. moparisthebest has joined
  81. moparisthebest has left
  82. moparisthebest has joined
  83. wurstsalat has joined
  84. kokonoe has left
  85. rtq3 has left
  86. rtq3 has joined
  87. j.r has left
  88. lskdjf has left
  89. mrDoctorWho has left
  90. Maranda has joined
  91. Maranda has joined
  92. neshtaxmpp has joined
  93. neshtaxmpp has joined
  94. alexis has joined
  95. alexis has left
  96. lumi has left
  97. matlag has joined
  98. rtq3 has left
  99. rtq3 has joined
  100. Yagiza has joined
  101. mrDoctorWho has left
  102. Yagiza has left
  103. lskdjf has joined
  104. lskdjf has joined
  105. Yagiza has joined
  106. mrDoctorWho has joined
  107. mrDoctorWho has left
  108. jmpman has joined
  109. ThibG has joined
  110. mrDoctorWho has left
  111. Nekit has joined
  112. rtq3 has left
  113. remko has joined
  114. lskdjf has joined
  115. 404.city has joined
  116. remko has left
  117. 404.city has left
  118. kokonoe has joined
  119. vaulor has joined
  120. thorsten has left
  121. ThibG has left
  122. ThibG has joined
  123. lorddavidiii has joined
  124. Tobias has joined
  125. Tobias has left
  126. Tobias has joined
  127. j.r has joined
  128. waqas has left
  129. moparisthebest has joined
  130. mimi89999 has joined
  131. jmpman has joined
  132. l has joined
  133. jmpman has joined
  134. sezuan has left
  135. labdsf has left
  136. lnj has joined
  137. sezuan has left
  138. sezuan has left
  139. j.r has joined
  140. remko has joined
  141. andy has joined
  142. kokonoe has left
  143. kokonoe has joined
  144. Alex has joined
  145. Maranda has joined
  146. Maranda has joined
  147. andy has left
  148. andy has joined
  149. vaulor has left
  150. Tobias has joined
  151. lorddavidiii has left
  152. lorddavidiii has joined
  153. ralphm has joined
  154. kokonoe has left
  155. Steve Kille has left
  156. neshtaxmpp has joined
  157. architekt has joined
  158. Steve Kille has joined
  159. kokonoe has joined
  160. architekt has left
  161. jmpman has joined
  162. frainz has left
  163. frainz has joined
  164. lovetox has joined
  165. frainz has left
  166. frainz has joined
  167. APach has left
  168. APach has joined
  169. karoshi has joined
  170. sezuan has left
  171. Guus has left
  172. edhelas I'm really tired of refusing OMEMO requests
  173. edhelas I'm thinking of hardcoding the body detection and starting to reply automatically
  174. Guus has left
  175. Ge0rG edhelas: just blacklist the OMEMO node on your PEP
  176. lovetox whats a OMEMO request?
  177. edhelas > I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo
  178. labdsf has joined
  179. lovetox tell your contacts to disable omemo?!
  180. thorsten has left
  181. edhelas yes, one by one :) if at one moment they move to conversations
  182. Ge0rG lovetox: that's O(N*M)
  183. Ge0rG with N=number of contacts and M=number of devices each contact has
  184. edhelas I'm not there to do "remote xmpp client configuration over human written messages"
  185. lovetox hm in Gajim you can deactivate publishing keys to the node
  186. lovetox but yes this problem exists because you use a client that supports omemo ..
  187. Ge0rG because you once used such a client
  188. Ge0rG if you are on prosody < 0.11, you can restart your server to "fix" it
  189. edhelas yes I do use Conversations sometimes, and Movim 95% of the rest of the time
  190. ralphm pep.: there are some, mostly deferred/retracted, XEPs that use http://xmpp.org/ as the start of their namespace. I'd leave them be. If we ever resurrect them, they'd have to go with a urn one anyway.
  191. lovetox fastest way would probably to set the devicelist node to whitelist
  192. Ge0rG edhelas: write a Movim plugin that subscribes to the siacs namespace and removes all devices
  193. Ge0rG or what lovetox said
  194. lovetox Ge0rG that does not help
  195. lovetox as devices are instantly republished
  196. lovetox you can configure nodes in Gajim 🙂
  197. ralphm pep.: and probably everything that still has shtml in a link should get looked at.
  198. jmpman has joined
  199. moparisthebest has joined
  200. vanitasvitae edhelas: does movim support Explicit Message Encryption?
  201. edhelas vanitasvitae I as looking into that
  202. vanitasvitae You could use that to determine, if a message is omemo encrypted or not
  203. vanitasvitae Might be better than to check the body
  204. edhelas conversations is adding the tag ?
  205. vanitasvitae Pretty sure it does
  206. edhelas ok
  207. Ge0rG lovetox: how do you configure PEP in Gajim? I've opened the "Configure services.." menu on my server, but there are no items listed and the buttons are greyed out, except for "Close"
  208. lovetox because your server does not support configuring nodes
  209. Ge0rG lovetox: would be awesome to have that displayed in that box
  210. lovetox yes once i rework the dialog, its still from ancient times
  211. Ge0rG Ah, the Good Old Times!
  212. pep. What happened about the LC on 345 BTW, did I miss any decision made about it?
  213. goffi has joined
  214. Ge0rG pep.: I suppose the Board needs to vote on advancing it next.
  215. Ge0rG Or maybe somebody can make a PR incorporating LC feedback
  216. thorsten has left
  217. mimi89999 has left
  218. Ge0rG dwd: I would kindly ask you to put https://github.com/xsf/xeps/pull/752 and XEP-0410 advancement on the next Council agenda. cc jonas’
  219. kokonoe has left
  220. Zash has left
  221. moparisthebest has joined
  222. moparisthebest has joined
  223. kokonoe has joined
  224. igoose has joined
  225. igoose has joined
  226. ralphm Ge0rG: with the Summit happening, we haven't had a meeting to discuss the LC feedback on XEP-0345 yet. Thursday is the first opportunity.
  227. Ge0rG pep.: ^
  228. Ge0rG There was also a Board PR that Council was asked to look into.
  229. ralphm has left
  230. Zash has left
  231. architekt has joined
  232. wurstsalat has joined
  233. architekt has left
  234. rtq3 has joined
  235. j.r has joined
  236. goffi hey there. I was thinking this morning, it would be nice to have a QR code with my jid in it on my website, so people could get it easily from phone, and it would be nice to have a way to make it easy to recognise. It's possible to put an image inside QR codes, so would not it be nice to agree on something (e.g. putting XMPP logo inside) so we could know immediatly "OK this is a XMPP identifier"? Would it make sense to have an informational XEP on this?
  237. ta has left
  238. ta has joined
  239. Ge0rG goffi: yes, you can increase the FEC on QR codes and then just bump some picture over the middle
  240. Guus sounds like a fun little shareable service.
  241. goffi Ge0rG: FEC?
  242. jonas’ (forward error correction)
  243. pep. Wasn't it "the image isn't part of the standard, it's just ignored with error correction"
  244. Ge0rG goffi: forward error correction. Also related: https://github.com/ge0rg/easy-xmpp-invitation
  245. jonas’ although I’% not entirely sure that’s the correct term for QR codes
  246. pep. hah, right
  247. jonas’ although I’m not entirely sure that’s the correct term for QR codes
  248. goffi I know it's possible, that why I'm proposing it, we don't need much characters for a jid.
  249. Ge0rG jonas’: but it still is FEC.
  250. jonas’ ok
  251. Ge0rG just because people invent new fancy names... 🤷
  252. pep. goffi, what do you want to do with "a JID"?
  253. pep. Add as contact?
  254. goffi pep.: yes
  255. goffi not only on website, on visit card too
  256. Ge0rG goffi: what if the person scanning the code doesn't have a Jabber client yet?
  257. goffi I just want a way to recognise immediately "oh this is a jid"
  258. pep. goffi, have a look at what Ge0rG pasted
  259. Ge0rG I'd put a Jabber lightbulb in it.
  260. pep. We can probably just put a QR code there
  261. goffi Ge0rG: it's the same issue with a xmpp:myjid@example.net link.
  262. pep. https://yax.im/i/#vladimir@xmpp.example
  263. goffi my point is just to have a way to recognise the QR code as XMPP related.
  264. Ge0rG goffi: I've heard you are good at webdev.
  265. mightyBroccoli has left
  266. mightyBroccoli has joined
  267. goffi using http or xmpp is an other thing. There are issues with http (you have to keep a service, and it won't be catched by registered client). But that's not the point of my idea, I just wonder if it would make sense to agree on a way to recognise XMPP QR Code (image inside is one thing, we could also play with colors).
  268. Ge0rG > it won't be catched by registered client yaxim will catch both yax.im and conversations.im landing pages
  269. goffi Ge0rG: what do you mean ? I'm working with web sometimes yes, and on a XMPP web framework.
  270. pep. I'd have a QR code with the XMPP logo (to add to the bikeshed discussions)
  271. Ge0rG goffi: the easy-xmpp-invitation project is looking for volunteers 😁
  272. goffi Ge0rG: and what I have gajim ?
  273. Ge0rG goffi: how do you scan images in Gajim?
  274. debacle has joined
  275. goffi Ge0rG: I would love to help on that, but I'm already close to burn out with my paid job + work on SàT + all side stuff (like preparing FOSDEM)
  276. Ge0rG goffi: alright, thanks anyway :)
  277. rion has left
  278. rion has joined
  279. goffi Ge0rG: I was mentioning gajim for the contact link, a xmpp:toto@example.net will work there, https://yax.im/i/#vladimir@xmpp.example wont
  280. rtq3 has left
  281. rtq3 has joined
  282. thorsten has left
  283. Ge0rG goffi: on my OS, Gajim doesn't handle xmpp: URIs
  284. goffi is it possible with QR code to have 2 links ? A http: one and a xmpp: one ?
  285. Ge0rG nope. But the landing page contains an xmpp: link ;)
  286. goffi what if the size is down ?
  287. goffi site*
  288. pep. Then it's down I guess
  289. dele has joined
  290. goffi xmpp: will still work. I mean I get the point with https: link, and I agree on most of them, but the xmpp: is the standard way of doing, it's not linked to an entity, in short it has many advantages too.
  291. goffi it's not linked to a client or service*
  292. pep. goffi, what if your xmpp server is down
  293. Ge0rG goffi: it's got many advantages, but it doesn't work for normal people.
  294. pep. Will the other server resend the subscription request(?)
  295. goffi pep.: it won't prevent you to add the contact, after the subscription will happen when it will be up again.
  296. Tobias has left
  297. pep. goffi, ok. I wouldn't mind having the xmpp: uri in there, but then you only target people already present on xmpp
  298. goffi best way would be to find a way to have both in a easy way, but doesn't looks like possible.
  299. pep. (I agree we're mixing two issues, but I don't know how to entangle them)
  300. mtavares have two qr codes...
  301. mtavares just to make it more complicated.
  302. pep. mtavares, I think that's be even more confusing
  303. mtavares using a http link works well enough, me thinks.
  304. pep. "So which one is it??" "It's the same" "Why do you have two then?" -- my mom
  305. goffi https://qr-creator.com/multiple-url.php
  306. goffi it seems possible
  307. mtavares ahh.. interesting.
  308. pep. goffi, it's just text right, you put whatever format you want in there
  309. Wiktor has left
  310. Tobias has left
  311. Wiktor has joined
  312. jonas’ pep., QR codes have multiple subformats for different payloads
  313. pep. I see
  314. jonas’ partly because they use different codes for different payloads to save bits
  315. pep. And of course this website only accepts URLs
  316. Zash has left
  317. pep. not XMPP URIs
  318. goffi ah it's just redirecting and shows the 2 links
  319. goffi pep.: yes I know, but the QR code readed need to know how to handle both.
  320. mtavares it's just a https link to qr-creator.
  321. goffi mtavares: yes, so not good :(
  322. dele has left
  323. Tobias has left
  324. Ge0rG https://op-co.de/tmp/georg@yax.im-bulb.png
  325. Ge0rG https://op-co.de/tmp/georg@yax.im-xmpp.png
  326. goffi I like more the second one
  327. goffi it's neat :)
  328. pep. yeah me too
  329. Ge0rG This is the moment to complain about our well-known marketing name being absolutely burned, and our official protocol name being too technical for regular people.
  330. pep. Maybe just remove the "XMPP" from there
  331. pep. So you don't have to pronounce it.
  332. goffi yeah the logo only is fine I think
  333. goffi also I think the text could be used for something else.
  334. goffi for instance, would it make sense to distinguish QR Code depending on their use: for instance a contact to add, or an ad-hoc command to execute, or a pubsub service ?
  335. goffi so you would but the XMPP logo, and "contact" under it instead of "xmpp"
  336. Ge0rG did I mention that normal people in our region consider QR codes as something awkward?
  337. goffi why ?
  338. Ge0rG dunno
  339. goffi nearly everybody is getting use to it, it's a nice techno
  340. Ge0rG http://picturesofpeoplescanningqrcodes.tumblr.com
  341. Andrew Nenakhov has left
  342. ta I have it on my applications as vCard. I still hope some technical employer finds it nerdy.
  343. Zash has left
  344. Ge0rG ta: do you have a utm tag in it?
  345. ta well, i don't have a link in it, so no...
  346. ta I mean application as in paper/pdf. QR-code being just contact information as vcard.
  347. ta But i should consider tracking when applying at some online shops. they like everything i try to block ;-)
  348. lnj has left
  349. Andrew Nenakhov has left
  350. Andrew Nenakhov has joined
  351. rtq3 has left
  352. rtq3 has joined
  353. lnj has joined
  354. Zash has left
  355. lovetox woever wrote me a pm here, i cant answer because converse does not support pm 😃
  356. ta <-- is just asking about the gajim muc not beeing reachable from some servers.
  357. lovetox ta, would be interested what the error is
  358. lovetox im joined and im on jabber.at currently
  359. equil has joined
  360. ta if you guide me. gajim and xml console didn't give me much feedback.
  361. ta you can guess my JID, so we don't spam here. I am using trashserver.net (no comments on that name ;-)
  362. lovetox but it should, restart gajim open xml console, join the muc and maybe wait for 1 minute, whatever the servers timeout is, at one point your server should inform you why its not possible to connect
  363. lovetox otherwise ask the admin
  364. architekt has joined
  365. Zash lovetox: Looks like a IPv6 problem, please try to fix it.
  366. lovetox can you be more specific
  367. lovetox im not the server admin, but i can tell him
  368. Ge0rG If only XMPP servers could gracefully support both IPv4 and IPv6
  369. Ge0rG looking at Zash
  370. architekt has left
  371. architekt has joined
  372. Ge0rG lovetox: traceroute to conference.gajim.org (2001:bc8:342f:101::1), 30 hops max, 80 byte packets ... 5 * * * 6 2001:bc8:400:1::8e (2001:bc8:400:1::8e) 27.964 ms 28.068 ms 28.263 ms 7 2001:bc8:400💯:26 (2001:bc8:400💯:26) 25.912 ms 26.035 ms 26.204 ms 8 * * * ...
  373. ta has left
  374. pep. has left
  375. Zash Ha. Blame Link Mauve
  376. Ge0rG Zash: is he behind gajim.org?
  377. pep. has left
  378. pep. has left
  379. Link Mauve No I’m not.
  380. Zash No, why I bumped a timeout back up to the point where it gives up completely before trying the next IP
  381. Ge0rG Zash: you bumped Link Mauve?
  382. Ge0rG can't you unbump him?
  383. Zash Link Mauves toaster was too slow for the low timeout
  384. ta Well is this the cause already? I restarted gajim, have a very spammy xml console...
  385. Ge0rG Zash: can't you also increase the *other* timeout then?
  386. Maranda has joined
  387. Maranda has joined
  388. Ge0rG Zash: it's a bit shortsighted to break connectivity for all users of prosody just because of Link Mauve
  389. lovetox ta i reported it to asterix but will not be fixed immediatly
  390. Zash Actually, this specific configuration still works because the write timeout here is 60s and the "give up completely" timeout is 90s
  391. Zash But ... this varies
  392. dwd Hi all. Do we have an incremental update for disco#items and things? I've a feeling that Sem Whited documented something that HipChat did a while back but I can't find it.
  393. jonas’ what do you mean by incremental update?
  394. neshtaxmpp has joined
  395. ta lovetox, thanks. No hurry. I was just surprised that nobody "cared" in all the other XMPP-centric MUCs ;-)
  396. dwd So if I have cached, for example, all the disco#items, and I now want to find what's changed instead of downloading the entire list again.
  397. dwd Sorta like XEP-0237 for Disco.
  398. Zash lovetox: The prosody module mod_bidi might help a bit, since it reduces the number of connections that can fail
  399. Zash dwd: Isn't that caps?
  400. Zash Or you want caps on ... things?
  401. Zash Or disco-sub or whatsitcalled?
  402. dwd Not caps. Though caps on ... things would be nice, actually - good plan.
  403. dwd But caps doesn't do disco#items.
  404. Zash Right
  405. Zash Did caps2 do that?
  406. Zash I'm sure we discussed some semi-recursive caps thingy recently
  407. dwd But yeah, if I have 1.2 quadzillion MUCs, I'd like to just fetch the three new ones and not the 1.2 quadzillion over again.
  408. jonas’ caps isn’t really incremental, either
  409. Zash Yeah. Figuring that out would be nice.
  410. dwd jonas’, Yes, indeed.
  411. rtq3 has left
  412. jonas’ disco#items versioning essentially
  413. dwd I can't recall if we decided that Sam's proposal should be a XEP or even if he submitted it.
  414. Zash I was leaning towards not returning complete results in disco#items at all and defering to some search interface
  415. jonas’ I don’t recall anything in that direction
  416. Ge0rG RSM!
  417. Zash I only recall that there was "disco-(pub)sub"
  418. dwd But otherwise, I'll do a ProtoXEP based around '237's design if there's interest.
  419. dwd Ge0rG, RSM is good for paging, less good for incremental update.
  420. Zash RSM is also weird if items can be removed
  421. Guus dwd hipchat has a couple of features documented here https://docs.atlassian.com/hipchat.xmpp/latest/xmpp/rooms.html
  422. Guus the room push comes closest to what you describe
  423. dwd Or... I could do it based on pubsub, and then list disco#items things in a pubsub node... somewhere.
  424. Guus (it also does something with service discovery - but that does not seem to match your description)
  425. Zash dwd: But if you have 1.2 quadzillion MUCs, having a cache of them locally is probably not fun anyways
  426. Ge0rG dwd: did we solve the multiple-items-per-node pubsub problem yet?
  427. Zash Ge0rG: What problem is that?
  428. dwd Zash, True, but I have a way of having a set of MUCs I'm interested in anyway. The problem is that I have a lot of them.
  429. dwd Zash, Also, caching 1.2 quadzillion items is not fun, but fetching them anew every time is even less fun.
  430. jonas’ dwd, wouldn’t some type of search interface make more sense then?
  431. dwd Perhaps, but I do have a few cases where I want all the disco#items.
  432. pep. has left
  433. j.r has joined
  434. dele has joined
  435. flow dwd: I am not sure, but you are maybe looking for https://xmpp.org/extensions/xep-0366.html
  436. flow But I guess for a delta sync of disco#items you probably want something like disco#items versioning…
  437. Zash How many implement the incemental roster versioning thing?
  438. j.r has joined
  439. dele has left
  440. dele has joined
  441. karoshi has left
  442. karoshi has joined
  443. jmpman has joined
  444. lumi has joined
  445. j.r has joined
  446. Nekit has left
  447. Nekit has joined
  448. ta has left
  449. ralphm dwd: having a pubsub node to represent available channels would definitely be interesting.
  450. jmpman has joined
  451. ralphm dwd: with RSM, it would be much easier to keep lists on the client side in sync.
  452. 404.city has joined
  453. dwd has left
  454. ralphm We kind of already have a specification for this with `pubsub#subscription_type` with the value of `nodes`, and using that in subscription options towards the root node.
  455. Ge0rG dwd: did you receive my message further above regarding Council Agenda additions for tomorrow?
  456. ralphm https://xmpp.org/extensions/xep-0248.html#notify-items suggests there's a `<create/>` element in pubsub#event to be used for notifications, but the schema in XEP-0060 doesn't current have that.
  457. l has joined
  458. dwd has left
  459. l has left
  460. architekt has joined
  461. dele has left
  462. architekt has left
  463. architekt has joined
  464. goffi I have no time to check it now, but is not this RELOAD protoxep doing something similar to jingle?
  465. l has joined
  466. Zash Based on what dwd wrote, I wonder if it's rather something for the IETF?
  467. j.r has joined
  468. lskdjf has joined
  469. architekt has left
  470. lorddavidiii has left
  471. lorddavidiii has joined
  472. lorddavidiii has left
  473. neshtaxmpp has joined
  474. lorddavidiii has joined
  475. Guus has left
  476. Alex has left
  477. l has joined
  478. ralphm Too bad the date on the inbox entries are all from yesterday.
  479. pep. has left
  480. pep. has joined
  481. pep. has joined
  482. debacle goffi, to me XOR looks more like 0174 (Serverless), but with NAT traversal
  483. jonas’ XOR depends on '174 AFAICT
  484. goffi OK, I've just overlooked and it looked like a way to establish a stream.
  485. goffi interesting then, I'll check that later.
  486. moparisthebest has joined
  487. Tobias has joined
  488. moparisthebest has joined
  489. efrit has joined
  490. sezuan has left
  491. j.r has joined
  492. moparisthebest has left
  493. krauq has left
  494. equil has left
  495. equil has joined
  496. krauq has joined
  497. dwd Ge0rG, I've not noticed it, and would welcome an email. Travelling tonight at short notice, and I'll try to do the agenda stuff on the train.
  498. Tobias has left
  499. jmpman has joined
  500. Ge0rG dwd: sure thing
  501. dwd So, XEP-0366 is more or less what I was after. I think including caps, though, is probably interesting too.
  502. Zash "I have stuff with caps hash xxxx, what's changed since?"
  503. jmpman has joined
  504. Maranda has joined
  505. Maranda has joined
  506. Tobias has left
  507. alacer has joined
  508. Zash https://tools.ietf.org/id/draft-faltstrom-unicode11-07.html
  509. MattJ oh no
  510. Andrew Nenakhov has left
  511. MattJ > Appendix A. Changes from Unicode 6.3.0 to Unicode 7.0.0 > Changes from derived property value UNASSIGNED to either PVALID or DISALLOWED.
  512. andy has left
  513. Andrew Nenakhov has joined
  514. Andrew Nenakhov has joined
  515. debacle has left
  516. j.r has left
  517. j.r has joined
  518. edhelas has left
  519. edhelas has joined
  520. alacer has left
  521. alacer has joined
  522. matlag has left
  523. Ge0rG In the context of RELOAD, I'd suggest defining an XMPP wire-format to exchange X.509 CSRs and CRTs, which could be immediately plugged into a XMPP JID-identity CA
  524. dwd Zash, No, caps can be an all-or-nothing for disco#info. But it'd save me a huge amount in this particular instance. I think an entityver thing would help with disco#items, though.
  525. vaulor has joined
  526. lorddavidiii has left
  527. j.r has joined
  528. lorddavidiii has joined
  529. goffi has joined
  530. lovetox has left
  531. Zash has left
  532. Nekit has left
  533. Nekit has joined
  534. waqas has joined
  535. ThibG has joined
  536. ThibG has joined
  537. Nekit has left
  538. Nekit has joined
  539. efrit has left
  540. ralphm MattJ: so RFC 7622 will need an update?
  541. ralphm has left
  542. Nekit has left
  543. Nekit has joined
  544. Guus has left
  545. goffi has joined
  546. Zash has left
  547. Ge0rG has left
  548. Zash has left
  549. lovetox has joined
  550. pep. ralphm, thinking about <gone/> again for <moved/>, and MUC affiliations/PubSub subscriptions. I can't just return <gone/> for everything that comes pinging my account for privacy reasons. And my server doesn't know (could know, but allegedly doesn't track) these subscriptions, so..
  551. lnj has joined
  552. ralphm Well, if you want to leave some kind of tombstone, but only to selected people, you kinda have to keep the former relationships, whichever way.
  553. alacer has left
  554. pep. It will work for contacts, because we have the roster
  555. pep. But that's about the extent of what the server keeps track of, in the general case
  556. ralphm I suppose for pubsub subscriptions it might be harder indeed.
  557. jonas’ and MUC affiliations
  558. pep. Not even talking about server shutting down etc. yet
  559. ralphm But this is one of the reasons why dwd suggested PAM, so that your server keeps track for you. When you move, you could take that with you.
  560. pep. (I'm thinking about not considering this use-case for a first rewrite of <moved/>)
  561. pep. PAM?
  562. ralphm https://xmpp.org/extensions/xep-0376.html
  563. Ge0rG pep.: the hard question with roster is how to tell multiple clients of your friend, if the first client will replace unsubscribe your old JID.
  564. pep. Ge0rG, yes I got that, you don't have to repeat it over and over, that wasn't the question
  565. pep. I know we need a tombstone of some sort, and that was discussed
  566. Zash pep.: This came up at summit, about needing to keep the roster, or maybe some magic hash of it
  567. pep. Zash, "this"?
  568. Ge0rG you could create a PEP node with a whitelist populated with your roster when moving.
  569. Ge0rG pep.: what's the question then? Who is allowed to see your tombstone? Either everyone or old-roster-only, I suppose
  570. pep. Ge0rG, no that wasn't the question
  571. pep. Ah well, yes sorry
  572. pep. But not for the roster
  573. pep. I'm asking for muc affiliations and pubsub subscriptions (read the question)
  574. Ge0rG ah!
  575. ralphm so couldn't you whitelist the muc services on your bookmark list (private storage or PEP) and the pubsub nodes you have received notifications from?
  576. Ge0rG there is no way to enumerate all your MUCs and PubSub subscriptions, unless your PAM keeps track of them all, from day 1
  577. pep. Using bookmarks for MUC seems interesting
  578. pep. But yeah for PubSub we'd need PAM or sth
  579. Ge0rG bookmarks probably contain the relevant subset (what do you care if you are affiliated with a MUC you never joined)
  580. ralphm *also*, besides leaving a tombstone, there's no reason why you couldn't send a presence with forwarding address
  581. pep. presence is ephemeral
  582. ralphm not for muc rooms
  583. Ge0rG it might suffice to let PubSub and MUCs know.
  584. ralphm i.e. you only need to have it received once
  585. Ge0rG but you don't know where to send, in the first place
  586. pep. Technically the server can know
  587. pep. But yes that has to be done from day1
  588. ralphm wouldn't you likely cover this by the list of muc servers that you frequent rooms of?
  589. ralphm unless 100% is your goal, in which case good luck
  590. jonas’ gateways & transports are another topic
  591. pep. I would hope services GC after some time being unresponsive
  592. jonas’ a tricky one, actually
  593. jonas’ I wouldn’t want to loose my biboumi MAM because I moved accounts
  594. pep. hmm.
  595. pep. We're really trying to sort all the problems in the world at the same time :/
  596. pep. This thing is never going to progress
  597. jonas’ I’m calling it "enumerating"
  598. jonas’ I don’t expect your proposal to solve all of them
  599. pep. jonas’, I guess it's time for a client-side MAM? :/
  600. jonas’ but it should enumerate them all, and clearly distinguish between those which are solvable and solved, those which are likely solvable and deferred and those which are not likely solvable
  601. jonas’ client side MAM?
  602. pep. So that you can just ditch the server archive once you've fetched it, and then have your mobile ask your desktop client for archives
  603. jonas’ yea, no
  604. pep. Why not
  605. ta has joined
  606. jonas’ I don’t want to implement the server side of MAM things in a client
  607. jonas’ huge complexity, especially with Smart MAM ahead
  608. pep. True..
  609. jonas’ (and how about the clients which have the "I don’t want to store everything locally anyways" philosophy)
  610. pep. It's really not the first time I hear about it though
  611. jonas’ yeah, you hear from it mostly from crypto fashionistas
  612. pep. Sure
  613. jonas’ who want to solve the PFS problem with a huge pile of complexity
  614. Ge0rG ...and then end up talking with people who just dump everything into sqlite
  615. pep. Anyway, this is not a crypto party, the topic is different
  616. Ge0rG but you can't just just expose your new JID to every entity that claims to be a pubsub node.
  617. jonas’ in any case, client side MAM won’t solve the biboumi case
  618. jonas’ you don’t want to have that all stored on your phone anyways
  619. pep. jonas’, it would yes? I think
  620. ralphm I see this problem as moving house. You let your friends know. In the Netherlands you have a service that informs (selected) entities of your new address so they can update their records. Also, the occupant typically temporarily forwards stuff to you.
  621. ralphm (new occupant)
  622. goffi has joined
  623. ralphm You never reach 100%, and that's fine.
  624. Ge0rG has left
  625. pep. Right. So we're inevitably going to drop mail, but yeah it's fine
  626. pep. They'll recontact us, (or not)
  627. ralphm And the rest of it is usually a thing you solve socially, out of band, not technically.
  628. alacer has joined
  629. pep. Ge0rG, would you be ready to compromise on that <moved/> thing, or do you want to get all the use-cases into the one XEP
  630. pep. If so, I'll split efforts because I'd like to have something ready by 2025 not 2030
  631. pep. (I'm being generous)
  632. Ge0rG pep.: you know, I was like you, back then in 2018. I thought "how hard can it be". But then I started work. And I realized...
  633. Ge0rG So, what exactly do you want to compromise?
  634. Zash pep.: privacy problem of gone, needing to keep the roster
  635. Ge0rG Also persistent PEP with a configurable access model.
  636. pep. I want to drop the "My server is offline" use-case. I am not sure I'll be able to support "My server is scheduled for shutdown" entirely either, because we need tombstones
  637. pep. But I guess if your server shutdown is planned in 6 months time, that's already quite enough time to migrate most of your contacts
  638. Ge0rG pep.: do you want to drop muc affiliation and pubsub?
  639. pep. I don't know. At the moment I see it as something the server will have to keep track of for us, unless you have a client-side solutions
  640. Ge0rG Do you want to support users migrating from prosody < 0.11?
  641. pep. non-persistent PEP?
  642. pep. No I don't care
  643. pep. People please update.
  644. pep. Well, there is MAM, I can do with that if you really want
  645. Ge0rG A cryptographic identity overlay network that works over XMPP as the routing layer
  646. pep. yeah no thanks
  647. alacer has left
  648. pep. I wouldn't mind trying to make it future proof, as in, compatible with a possible crypto thingy that would come on top, if that's possible. But I'd like to have something out soon
  649. pep. Actually PEP/MAM are not necessary if we do <gone/>, on the old server.
  650. Ge0rG The old server must support it then.
  651. Ge0rG Also access permissions
  652. pep. The old server must support RFC 6120?
  653. pep. I hope it does
  654. pep. Ah ok I see
  655. pep. hmm, we can prompt for support, and if not fallback(?) how is that
  656. Ge0rG > Also access permissions
  657. Ge0rG Is there a protocol to *configure* gone on your account?
  658. pep. Yes, we can prompt for support on the old server, and if not PEP/MAM?
  659. alacer has joined
  660. pep. We talked about adding that to IBR, so that'd be a new thing indeed
  661. MattJ The problem with PEP is that it needs to be explicitly checked or subscribed to, and works on a client level
  662. Ge0rG So you'd say the default access permissions for <gone/> will be the user's last roster?
  663. MattJ <gone> errors in response to probes are much nicer
  664. MattJ But do require support from the migrating server
  665. pep. MattJ, sure, they all require support on different level..
  666. pep. *Somebody* has to support *something* :(
  667. Ge0rG pep.: sending messages to all your contacts doesn't.
  668. pep. Ge0rG, yes, clients need to understand MAM, and the moved payload
  669. Ge0rG pep.: I wanted to make a protocol that gracefully degrades if it's only supported by clients on both sides.
  670. pep. How far did you get
  671. Ge0rG pep.: messages with a moved payload from the old and from the new account. MAM / Carbons on the receiving side as faux persistence.
  672. pep. (all these french words)
  673. Ge0rG pep.: maybe a private PEP node on the receiving side where the first client can store the Moved from-to pair
  674. pep. yeah I remember these discussions, and I'm fine with that
  675. pep. I thought that was dealt with already
  676. Ge0rG But then there is a nice race condition on populating that PEP node.
  677. rtq3 has joined
  678. Ge0rG pep.: not written down yet.
  679. pep. Ok, let's do it then
  680. Ge0rG pep.: you want to continue the work? I can commit and push my last sad state.
  681. Ge0rG A compliant server could process a Moved PEP node on your account, and send a gone error to entities that are allowed to read that pep node
  682. Ge0rG Or maybe always send the gone, but only fill the JID if permitted.
  683. sezuan has left
  684. pep. yeah that's details to me at this stage
  685. pep. hmm,
  686. Ge0rG pep.: https://github.com/ge0rg/xeps/tree/xep-0283
  687. Ge0rG that's the code behind the rendered version I forgot to tell you before Summit.
  688. pep. k
  689. goffi has joined
  690. pep. I wouldn't actually mind only including compliant servers or clients in my assumptions, tbh
  691. pep. Deployment is an issue, and we all know that. My goal is not to solve this. (/me eyes non-rolling release distributions)
  692. Zash has left
  693. rtq3 has left
  694. rtq3 has joined
  695. Zash has left
  696. Zash has left
  697. dwd has left
  698. moparisthebest but a feature that only requires clients to upgrade will be adopted faster, especially if users want it, because it's fully under their control
  699. pep. But their contacts also need to support it
  700. pep. So maybe not that fast
  701. moparisthebest not if they can fall back
  702. moparisthebest like 'oh you don't support automatic roster migration? ok send message "hi I was x@x now I'm y@y"
  703. Ge0rG with the main reason for this being "abandonden servers" I'd pull the line at modern client support
  704. pep. Ge0rG, it's not my main reason fwiw
  705. lskdjf has left
  706. pep. My main reason is services like quicksy, or any other public services, which are great for adoption, but then users might want to move away from that
  707. Ge0rG I've heard there are ~250 users on Quicksy.
  708. pep. Sure
  709. pep. "or any other public services"
  710. moparisthebest then it has to be a client-only feature
  711. pep. moparisthebest, why does it have to
  712. moparisthebest public services that don't want people to move away would just never enable it?
  713. moparisthebest especially if they get $ from users, directly or data mining (google)
  714. pep. Yeah I'm not considering evil services tbh, that's another can of worms
  715. moparisthebest I'm not talking about evil
  716. pep. Why would they block then
  717. moparisthebest client-only doesn't work with actively evil either, they can block stanzas etc
  718. pep. Indeed
  719. pep. Any server can just block the PEP node
  720. moparisthebest I'm talking about "should I download and install/configure this plugin that makes it easier for users to leave?"
  721. moparisthebest why would they do extra work for that?
  722. pep. moparisthebest, if it's a PEP node it's no extra work
  723. lskdjf has left
  724. moparisthebest so that's client-only?
  725. pep. PEP is not client-only no
  726. pep. Neither is MAM. They all require server support
  727. moparisthebest yea but it doesn't require specific server support is all I meant
  728. pep. Yes it does
  729. moparisthebest not for this specific thing
  730. Yagiza has left
  731. moparisthebest just PEP in general that's used for lots of other things?
  732. pep. Yes yes
  733. pep. So here's your reason why they would set it up
  734. pep. So the feature can require server support
  735. moparisthebest yea that all sounds fine then
  736. moparisthebest I just meant if it required all servers to upgrade before it was useable, it'd be worthless and never adopted
  737. moparisthebest think MIX
  738. pep. Well there are still prosody < 0.11 out there, and it's going to be the case for a while
  739. rtq3 has left
  740. moparisthebest so you are, vaguely, publishing a pep node as old@old.com saying you've moved to new@new.com ?
  741. pep. Yeah. And that tombstone should stay up for your contacts' devices to see.
  742. lskdjf has left
  743. lskdjf has left
  744. moparisthebest I tended to like what Ge0rG called a 'cryptographic overlay' better, it's maybe a bit more complicated, but not too much
  745. lskdjf has left
  746. ralphm has left
  747. pep. I don't mind having that as a goal for later, in a different XEPs, with different goals (including moar uses-cases)
  748. mtavares has left
  749. moparisthebest vaguely, you publish a public key, your contacts save this (public key for old@old.com), then if a new account sends a subscription request with a message "I was old@old.com but now am new@new.com" signed by old@old.com's key, you know to update it
  750. moparisthebest not that much more complicated, supports everything that does plus the (I would think) common usecase of a server disappearing
  751. lskdjf has joined
  752. pep. You don't actually need crypto fwiw
  753. lskdjf has joined
  754. pep. Except if your old server is _already_ offline
  755. pep. But then you're probably not in a good position anyway
  756. moparisthebest that seems like a valuable usecase to support though
  757. pep. Yeah, I'm not worried about it for now, but you're welcome to
  758. moparisthebest so is yours, uh, lazy
  759. pep. And you should have preemptively declared your key if that's the case
  760. moparisthebest it relies on all your contacts checking your old PEP node every time?
  761. pep. They can check it once and be done
  762. moparisthebest once every time the client connects or?
  763. pep. Once they've acked it
  764. j.r has joined
  765. moparisthebest it doesn't react to being sent a message though?
  766. pep. I don't understand
  767. moparisthebest it checks pre-emptively for all roster contacts?
  768. pep. "it"?
  769. moparisthebest your client
  770. pep. Yeah, you +notify on the node
  771. lskdjf has joined
  772. moparisthebest so when a client logs in it has to check them all too I guess
  773. j.r has joined
  774. j.r has joined
  775. lskdjf has left
  776. pep. them?
  777. moparisthebest xep-27 already announces a key even, 'moved' could just define a signed payload for "I've moved"
  778. moparisthebest seems far simpler
  779. moparisthebest > so when a client logs in it has to check all pep nodes for all roster contacts all too I guess
  780. lskdjf has joined
  781. pep. A client doesn't "Check", notifications gets pushed to it, but sure
  782. moparisthebest even notifications sent before the client logs in?
  783. equil has joined
  784. lskdjf has joined
  785. pep. Sure, you say add +notify in your disco stuff and the server will resend it (I think?). You'll receive the last event
  786. pep. Sure, you add +notify in your disco stuff and the server will resend it (I think?). You'll receive the last event
  787. moparisthebest if I understand it's just adding a bunch more login traffic, at least one extra outgoing stanza and an ack per contact?
  788. moparisthebest vs the key thing, which supports all the same use-cases, plus missing server, with no extra login traffic?
  789. pep. There's no extra login traffic if there's no event. And once you've seen the event on contactX, you can unsubscribe from it.
  790. pep. what key thing
  791. moparisthebest crypto signed "i've moved" roster subscription messages from the contact that moved
  792. pep. But then in my use-case you'd need an extra PEP node on your own account mapping old-jid -> new-jid of your contacts, so that all your devices can ACK.
  793. pep. Then you do that from MAM?
  794. pep. You can also use MAM without crypto. And that's how Ge0rG implements it for now in his draft
  795. moparisthebest isn't the roster stored on the server? can't only 1 client change it then?
  796. moparisthebest technically the server could change it and not involve clients
  797. pep. So what's your use-case then, do you want the server to be involved or not
  798. moparisthebest that server involvement would be optional, on the non-moving client's end?
  799. moparisthebest wouldn't need to be mentioned in the XEP, the server could just optionally do it instead of the client
  800. pep. That can be mentioned in the XEP yes, and we already had something like that in mind.
  801. moparisthebest I tend to think moved that doesn't support a server going away in the future wouldn't be very useful
  802. pep. I think it is
  803. pep. And that'd be my main use-case
  804. moparisthebest my point is that if you do it a slightly different way, it supports both use cases
  805. pep. "slightly" meaning crypto?
  806. Steve Kille has left
  807. pep. :/
  808. moparisthebest sure
  809. Steve Kille has left
  810. moparisthebest you aren't inventing primitives or anything scary, just signing a message and verifying a signature?
  811. pep. You don't need crypto for most of what you just said
  812. pep. If your use-case if "server going away in the future", you don't need crypto
  813. pep. As your identity provider is still alive
  814. moparisthebest ok let me clarify, I mean "I'm gonna go ahead and publish this now, and still want to be able to use it to move if my server goes away in the future"
  815. lnj has joined
  816. Steve Kille has joined
  817. pep. publish where
  818. moparisthebest either signed presence like xep-27 or a PEP node?
  819. pep. Ok so what about non-supporting contact clients (which is a concerned that's been raised), at the time you published it, until you server went down
  820. pep. Also presence won't work, it's ephemeral
  821. peter has joined
  822. moparisthebest but you could save the key from the first presence you see or something, in your client
  823. pep. If you support it, sure
  824. moparisthebest non-supporting clients I think is the same regardless of method, if they don't advertise support, your client sends them a manual message?
  825. pep. And if you see it, in the first place
  826. moparisthebest (after it moves I mean)
  827. pep. Which is why I just don't want to worry about this use-case. With the current changes we have in moved, nothing prevents you to also publish your signed payload
  828. lnj has joined
  829. Zash has left
  830. lorddavidiii has left
  831. labdsf has joined
  832. rtq3 has joined
  833. equil has left
  834. equil has joined
  835. labdsf has left
  836. labdsf has joined
  837. Zash has left
  838. rtq3 has left
  839. rtq3 has joined
  840. rtq3 has left
  841. rtq3 has joined
  842. rtq3 has left
  843. rtq3 has joined
  844. Andrew Nenakhov has joined
  845. Andrew Nenakhov has left
  846. Andrew Nenakhov has joined
  847. wurstsalat has joined
  848. lskdjf has joined
  849. goffi has joined
  850. krauq has joined
  851. peter has left
  852. sezuan has left
  853. Nekit has left
  854. Nekit has joined
  855. lskdjf has joined
  856. Andrew Nenakhov has left
  857. tux has left
  858. Guus has left
  859. Guus has left
  860. lskdjf has left
  861. krauq has joined
  862. lskdjf has left
  863. Guus has left
  864. lskdjf has left
  865. Guus has left
  866. Andrew Nenakhov has left
  867. Andrew Nenakhov has left
  868. lnj has left
  869. lnj has joined
  870. labdsf has joined
  871. sezuan has left
  872. marc_ has left
  873. mimi89999 has joined
  874. jmpman has joined
  875. goffi has joined
  876. Guus has left
  877. Lance has joined
  878. igoose has left
  879. igoose has joined
  880. j.r has left
  881. j.r has joined
  882. peter has joined
  883. peter has left
  884. rtq3 has left
  885. rtq3 has joined
  886. Andrew Nenakhov has left
  887. lskdjf has joined
  888. goffi has joined
  889. remko has left
  890. rtq3 has left
  891. rtq3 has joined
  892. j.r has joined
  893. j.r has joined
  894. rtq3 has left
  895. rtq3 has joined
  896. efrit has joined
  897. intosi has left
  898. goffi has joined
  899. j.r has joined
  900. j.r has joined
  901. ralphm has left
  902. labdsf has left
  903. labdsf has joined
  904. Tobias has joined
  905. Nekit has joined
  906. Lance has left
  907. lnj has left
  908. goffi has joined
  909. lnj has left
  910. lnj has joined
  911. goffi has joined
  912. equil has left
  913. Seve has left
  914. j.r has left
  915. j.r has joined
  916. j.r has left
  917. j.r has joined
  918. lnj has left
  919. j.r has joined
  920. j.r has joined
  921. moparisthebest has joined
  922. vaulor has left
  923. jeroen has joined
  924. peter has joined
  925. jeroen has left
  926. jeroen has joined
  927. jeroen has left
  928. jeroen has joined
  929. MattJ has joined
  930. jeroen has left
  931. jeroen has joined
  932. goffi has joined
  933. jeroen has left
  934. Zash has left
  935. jeroen has joined
  936. peter has left
  937. jeroen has left
  938. j.r has joined
  939. j.r has joined
  940. Lance has left
  941. jeroen has joined
  942. goffi has joined
  943. jeroen has left
  944. Zash has left
  945. jeroen has joined
  946. lskdjf has left
  947. jeroen has left
  948. sezuan has left
  949. jeroen has joined
  950. labdsf has left
  951. jeroen has left
  952. jeroen has joined
  953. labdsf has joined
  954. jeroen has left
  955. jeroen has joined
  956. rion has left
  957. jeroen has left
  958. jeroen has joined
  959. jeroen has left
  960. jeroen has joined
  961. jeroen has left
  962. jeroen has joined
  963. jeroen has left
  964. goffi has joined
  965. lovetox has left
  966. krauq has joined
  967. remko has joined
  968. rtq3 has left
  969. rtq3 has joined
  970. Maranda has joined
  971. Maranda has joined
  972. krauq has joined
  973. lnj has left
  974. jmpman has joined
  975. remko has left
  976. lskdjf has joined
  977. lskdjf has left
  978. lskdjf has joined
  979. matlag has left
  980. goffi has joined
  981. Zash has left