XSF Discussion - 2018-06-27

  1. daniel has joined
  2. lumi has left
  3. Dave Cridland has left
  4. Dave Cridland has left
  5. daniel has left
  6. lorddavidiii has left
  7. daniel has joined
  8. daniel has left
  9. lorddavidiii has left
  10. daniel has joined
  11. jjrh has left
  12. la|r|ma has left
  13. MattJ has joined
  14. daniel has left
  15. marc has left
  16. daniel has joined
  17. lumi has joined
  18. daniel has left
  19. xnyhps has left
  20. xnyhps has joined
  21. dos has left
  22. Dave Cridland has left
  23. daniel has joined
  24. Zash has left
  25. lumi has left
  26. daniel has left
  27. daniel has joined
  28. jere has left
  29. jjrh has left
  30. SamWhited has left
  31. Dave Cridland has left
  32. jjrh has left
  33. muppeth has left
  34. muppeth has joined
  35. daniel has left
  36. daniel has joined
  37. daniel has left
  38. Dave Cridland has left
  39. Dave Cridland has left
  40. Dave Cridland has left
  41. daniel has joined
  42. Dave Cridland has left
  43. Dave Cridland has left
  44. daniel has left
  45. Dave Cridland has left
  46. Zash has joined
  47. Zash has left
  48. Zash has joined
  49. Zash has left
  50. Zash has joined
  51. Zash has left
  52. Zash has joined
  53. Zash has left
  54. Zash has joined
  55. Zash has left
  56. Zash has joined
  57. Dave Cridland has left
  58. daniel has joined
  59. daniel has left
  60. daniel has joined
  61. daniel has left
  62. Dave Cridland has left
  63. SamWhited has left
  64. j.r has joined
  65. j.r has joined
  66. daniel has joined
  67. Dave Cridland has left
  68. j.r has joined
  69. j.r has joined
  70. daniel has left
  71. daniel has joined
  72. Nekit has joined
  73. daniel has left
  74. kasper.dement has joined
  75. Dave Cridland has left
  76. daniel has joined
  77. kasper.dement has left
  78. jere has joined
  79. lnj has joined
  80. lskdjf has joined
  81. goffi has joined
  82. tux has left
  83. tux has joined
  84. Dave Cridland has left
  85. lskdjf has joined
  86. marmistrz has joined
  87. lskdjf has joined
  88. jere has joined
  89. Dave Cridland has left
  90. la|r|ma has joined
  91. goffi has left
  92. goffi has left
  93. daniel has left
  94. Chobbes has joined
  95. Chobbes has joined
  96. Dave Cridland has left
  97. goffi has left
  98. goffi has left
  99. goffi has left
  100. Dave Cridland has left
  101. daniel has joined
  102. Ge0rG has left
  103. Nekit has left
  104. Nekit has joined
  105. goffi has left
  106. goffi has left
  107. Ge0rG has left
  108. moparisthebest has left
  109. daniel has left
  110. Ge0rG has left
  111. goffi has left
  112. Guus has left
  113. daniel has joined
  114. SaltyBones has left
  115. SaltyBones has joined
  116. andy has joined
  117. Guus has left
  118. Dave Cridland has left
  119. Guus has left
  120. Ge0rG has left
  121. alacer has left
  122. alacer has joined
  123. mikaela has joined
  124. alacer has left
  125. alacer has joined
  126. alacer has left
  127. Ge0rG Sam is bringing up a point. How do you protect a web service from files uploaded by users?
  128. labdsf has left
  129. jonasw context?
  130. Dave Cridland has left
  131. Ge0rG I upload a html+js file via http-upload, share the link with you, it's executed in your browser, I get your webchat / account login session cookie
  132. Chobbes has joined
  133. jonasw right, this should probably be in the security considerations
  134. jonasw but I don’t see where he brings that up
  135. Ge0rG the c.im cookie is only valid for account.c.im, so this specific issue doesn't apply
  136. Ge0rG standards, three days ago, re Council Minutes 2018-06-20
  137. jonasw (the solutions I’ve seen so far is to (a) be careful with the domain you choose for your upload service and (b) use Content-Disposition: attachment with anything which may contain executable code)
  138. jonasw sure, I see that mail, but not what you’re saying in it :)
  139. j.r has joined
  140. j.r has joined
  141. Ge0rG maybe I extended the focus of the question slightly. the general question was about "executable content"
  142. Ge0rG whatever that is.
  143. jonasw right
  144. Ge0rG there is nothing about content-disposition in the XEP
  145. jonasw somehow I didn’t get at all what that bullet point was trying to say
  146. jonasw but what you interpret into it kinda makes sense
  147. Ge0rG this is actually something I didn't have on my agenda on the last LC.
  148. jonasw or maybe not, I’m not sure. I think when I first read it I thought something along the lines of "okay, a client really should not download and run an .exe, but that’s obvious"
  149. Ge0rG ponders between "+1 but" and "-1 because"
  150. jonasw I think those are mostly operational concerns which will probably evolve with how the web treats content in the future.
  151. jonasw (nothing specific in mind)
  152. jonasw they’re also not directly related to XMPP
  153. Dave Cridland has left
  154. jonasw so I would probably not block based on that
  155. marmistrz has joined
  156. daniel has left
  157. jonasw they also don’t require a namespace bump or otherwise interaction with the entities implementing the protocol, AFAICT
  158. Ge0rG yes
  159. Ge0rG we are only giving server operators a huge, back-facing gun.
  160. Ge0rG nothing wrong with that.
  161. jonasw that’s not what I wanted to s ay
  162. jonasw I wanted to say that it should be expected that we have to modify this in the future anyways, so modifying it right when it goes to draft should be ok too (regarding your "+1 but").
  163. Ge0rG yeah, also don't want to be an asshole for security's sake. I played that card last time already.
  164. jonasw this should be fixed ASAP, but blocking advancement based on that might not help with that
  165. jonasw (something something demotivating authors something)
  166. Ge0rG yeah, that.
  167. Kev has left
  168. daniel has joined
  169. Dave Cridland has left
  170. j.r has joined
  171. j.r has joined
  172. j.r has left
  173. daniel has left
  174. j.r has joined
  175. SaltyBones has left
  176. SaltyBones has joined
  177. Dave Cridland has left
  178. Dave Cridland has left
  179. labdsf has left
  180. xnyhps has joined
  181. xnyhps has joined
  182. Dave Cridland has left
  183. daniel has joined
  184. Dave Cridland has left
  185. winfried has left
  186. marmistrz has joined
  187. goffi Hi, nobody answered my remarks on expiration date for HTTP upload, does anybody care? It seems a major point to me.
  188. winfried has joined
  189. Guus has left
  190. jonasw goffi, I can’t recall your feedback. I think it would help the discussion if you would provide a link to your feedback.
  191. goffi jonasw: https://mail.jabber.org/pipermail/standards/2018-June/035181.html
  192. rion has left
  193. jonasw goffi, I now recall that email. I do remember that you wrote it, but I also remember not seeing this as particularly important
  194. goffi you don't think expiration date is important ?
  195. jonasw maybe you should clarify on the mailing list why you think this is particularly important
  196. jonasw I’m not sure it’s extremely important to have this on the protocol. ✎
  197. goffi we upload file on a server, we don't know for how long, and we have no access to it then.
  198. jonasw I’m not sure it’s extremely important to have this on the protocol level, it should be included in the Privacy Policy for sure. ✏
  199. goffi jonasw: OK I'll try to explain more, thanks for feedback, I had the feeling to be ignored which is quite frustrating as it is a major point to me (even if it's to say that it's not that important for whatever reason).
  200. jonasw sure
  201. jonasw I fully understand that
  202. labdsf has left
  203. jonasw to me, it really did not come across to me that you thought that this is an important point, mostly because it lacked any rationale
  204. moparisthebest has joined
  205. Chobbes has joined
  206. jonasw (typically when I try to raise a point I think is important, I’ll put a rationale on it *why* I think its important.)
  207. Valerian has joined
  208. Kev has left
  209. ralphm has joined
  210. daniel goffi: in parts that was due to me being extremely busy with work these days. And in parts I was taking the easy way out and was waiting for someone to write a me too or something
  211. jonasw daniel, FWIW, I think this is a good idea and supplements the work I was aiming to do with ToS.
  212. jonasw I also think that this can easily be added later because it’s a data form \o/
  213. j.r has joined
  214. j.r has joined
  215. daniel yeah i’m ok with just putting it in there as an optional data form field
  216. daniel but I don’t see a technical use case for it because it won’t be reliable anyway
  217. daniel i see it as a pure TOS informational thing
  218. jonasw maybe
  219. Valerian has left
  220. Valerian has joined
  221. Dave Cridland has left
  222. goffi jonasw: indeed, I've made a new message. daniel: OK, thanks to come in the discussion here, I've sent a new message to explain. I know it's not reliable, but it's informational, and there is a relation of trust with a server anyway (if I can trust retention date, I can't trust anything). It's the same with ToS.
  223. Dave Cridland has left
  224. lnj has left
  225. Dave Cridland has left
  226. Dave Cridland has left
  227. Ge0rG Did you just add data forms to http upload?
  228. goffi the think with putting it in the HTTP Upload XEP is to make it mandatory. If it's not, nobody will set the data. Also the HTTP Upoad Component probably knows when the files are deleted so it can be set automatically.
  229. jonasw Ge0rG, they were always there
  230. jonasw Ge0rG, in disco#info
  231. j.r has joined
  232. daniel goffi, i see and agree with most of your points. and don’t think the suggested solution is a very good one or a solution at all
  233. Ge0rG Ah
  234. daniel if anything we would need the client to mark a file as permanent (for avatars or blogs posts) or shortlived
  235. daniel and maybe a deletion command
  236. jonasw daniel, +1
  237. Dave Cridland has left
  238. j.r has joined
  239. daniel just putting the information in there on how long a server might store it doesn't do anything
  240. daniel or very very little
  241. daniel i mean what i'm a supposed to do? reupload the avatar every 30 days?
  242. Dave Cridland has left
  243. goffi having a way to specify retention time in the request would be better, my email is not discarding this option.
  244. Ge0rG Permanent storage requirements will break my GDPR compliance script... 🤔
  245. j.r has joined
  246. Ge0rG Or we need to have multiple upload components for temporary and permanent storage
  247. jonasw ew
  248. goffi daniel: is is possible to write your comments on standard@ even in a short email, so we can have other people input?
  249. Kev I imagine it's generally down to local policy.
  250. jonasw Ge0rG, your component could implement this trivially by putting permanant files in a different directory (and reflecting that in the URL)
  251. Kev But avatars are an exception as they are 'always' permanent.
  252. daniel jonasw, yeah. the problem with that is that you still need some policy on the server that prevents stupid clients from always using the permanent store
  253. daniel and cluttering your file system
  254. Kev Do you?
  255. Kev I mean, you can always have usage limits.
  256. jonasw daniel, quotas? and explicit request for permanent storage so that stupid clients need to be actively stupid at least
  257. jonasw then it blows up in their face for reaching quotas and you’re done :)
  258. jonasw quotas can be really small for permanent storage on IM deployments, 10 MiB or something
  259. jonasw that’ll be reached extremely quickly
  260. daniel jonasw, yes and yes. but it makes implementations a bit more complicated then 'just put it in a different folder' is what i'm saying
  261. jonasw (when abused for sending gifs to MUCs)
  262. jonasw daniel, you need to have some type of quota anyways
  263. j.r has joined
  264. daniel right. but then you need different quotas
  265. Dave Cridland has left
  266. j.r has joined
  267. jonasw that’s true
  268. daniel i'm not saying it can’t be done. but right now most http upload implementations are very very simple
  269. Steve Kille has left
  270. jonasw indeed
  271. jonasw and I think if one went around and started abusing that, many servers would fail very quickly with ENOSPC
  272. Dave Cridland has left
  273. Ge0rG this sounds like a quick escalation from "file sharing" to "cloud storage provider"
  274. daniel yes
  275. daniel especially if you start doing delete
  276. daniel and list files
  277. Steve Kille has left
  278. jonasw just implement WebDAV with XMPP auth
  279. Ge0rG if you want to provide permanent storage, you need both listing and deletion. and quotas
  280. daniel has left
  281. jonasw actually, that doesn’t sound *too* bad for permanent HTTP-based storage.
  282. daniel that’s why i see a general desire to have those features but am hesitent to put them in the xep
  283. goffi that looks like the component I'm doing with Jingle.
  284. Ge0rG jonasw: but custom http headers for obscure aws servers!11!
  285. jonasw you’ll probably find a WebDAV library and servers which support WebDAV. just make the client pass some token in the HTTP Auth header and done.
  286. lorddavidiii has left
  287. goffi in this case why not keeping HTTP Upload for simple temporary storage, and specifying date of expiration, and having more elaborated components for stuff like avatar or blogs ?
  288. Dave Cridland has left
  289. jonasw goffi, this sounds very reasonable
  290. goffi and explicitly forbidding permanent storage with HTTP Upload
  291. jonasw I wouldn’t go that far
  292. daniel what’s the use case for the expiration then?
  293. Dave Cridland has left
  294. daniel *the expiration date
  295. goffi if we want to keep the implementation simple, which is the main interest of this XEP I think, permanent storage doesn't seem an option.
  296. goffi daniel: knowing when the file is deleted, how long we can still use the link.
  297. goffi I'm not confortable in uploading a picture if I don't know how long it will stay
  298. goffi I can encrypt, but I then have the feeling to waster resources.
  299. daniel apperently you are comfortable with sending messages without knowing how long they will stay in archive
  300. Dave Cridland has left
  301. daniel that's what the TOS are for…
  302. goffi I know how long they stay
  303. goffi on my server at least
  304. Kev How?
  305. jonasw you also know how long files are stored on your server ;-)
  306. Dave Cridland has left
  307. goffi right, but I have no MAM at the moment, so my server is not keeping anything. But the same question is valid for MAM I've never said the opposite.
  308. alexis has left
  309. daniel yeah i’m not sure that every feature in xmpp that has the ability to store something needs to signal it's own retention period
  310. goffi and about resource, it's not the same about a couple of message, and one or several MB files
  311. daniel my vcard service never report how long it will store that either
  312. Valerian has left
  313. alexis has joined
  314. jonasw goffi, not your department; the server is responsible for managing the resources it offers to you.
  315. jonasw it must not rely on your goodwill
  316. Dave Cridland has left
  317. goffi daniel: in this case in ToS, but it may be mentioned in the XEP
  318. Dave Cridland has left
  319. goffi jonasw: I usually have different usage if I know I'm wasting resources
  320. Dave Cridland has left
  321. jonasw you shouldn’t
  322. goffi why ?
  323. Kev Sure you should. Wasteful is wasteful.
  324. jonasw it’s the servers responsibility to take care of that.
  325. Kev Whether it's you paying the bill or someone else doesn't change that.
  326. jonasw I mean right, uploading a screenshot of each message instead of the message itself *is* wasteful and you shouldn’t do that
  327. Dave Cridland has left
  328. goffi jonasw: put on an analogy, if I can choose between plastic and something else, and I know plastic can't be recycled correctly and something else can, I'll take something else.
  329. jonasw but I don’t think you should base your individual upload decisions on whether and which retention policy the server implements. you might base your decision which server to use on that, though (that makes sense to me for resource use and privacy reasons)
  330. goffi and don't say "once it's in the trash, it's not my problem"
  331. jonasw goffi, I’m not arguing against that, it makes sense. and choosing a server based on those factors may make a lot of sense.
  332. Dave Cridland has left
  333. goffi to get back to initial subject, it make sense to put this on ToS, but is there anyway to make it mandatory ? Or at least a SHOULD ?
  334. jonasw having this information in the disco#info is good, I think
  335. jonasw but we need to make the semantics clear
  336. goffi yes disco#info make sense
  337. Dave Cridland has left
  338. jonasw a service could have a dynamic retention time based on resource use for example. something like "at least 7 days, at most 14 days, and everything in between depends on how full our disk is". how would that be reflected? should the sevrice say 7 days (this will confuse users who expect their data to be gone after the threshold) or 14 days (which will confuse users who expect the data to be available up to the threshold)?
  339. Valerian has joined
  340. jonasw do we need a min-retention and max-retention field?
  341. Kev And how do you signal policy changes?
  342. goffi that's what framadrop is doing
  343. goffi large file => short rentention
  344. Kev You uploaded when it was a policy to keep for 30 days, and now the server is changed to 15.
  345. Dave Cridland has left
  346. goffi in this case it need to be returned in the HTTP Upload <IQ> result
  347. jonasw goffi, Expires header on the HTTP response would be my suggestion
  348. alexis has joined
  349. jonasw (which gives a min-retention)
  350. goffi jonasw: I'm fine with that as long as it is explained in a XEP, either HTTP Upload itself, or a separated one mentioned in HTTP Upload.
  351. jonasw yupp
  352. goffi if it's not specified anywher, nobody will do it.
  353. Steve Kille has left
  354. Dave Cridland has left
  355. lorddavidiii has left
  356. Dave Cridland has left
  357. Guus has left
  358. Dave Cridland has left
  359. Dave Cridland has left
  360. daniel has left
  361. blabla has left
  362. blabla has joined
  363. Dave Cridland has left
  364. rishiraj22 has left
  365. labdsf has left
  366. alexis has left
  367. marmistrz has left
  368. alexis has joined
  369. Dave Cridland has left
  370. muppeth has joined
  371. Dave Cridland has left
  372. Dave Cridland has left
  373. muppeth has joined
  374. Kev has left
  375. lorddavidiii has left
  376. Valerian has left
  377. vanitasvitae has left
  378. mikaela has joined
  379. Valerian has joined
  380. Valerian has left
  381. muppeth has joined
  382. blabla has left
  383. blabla has joined
  384. lorddavidiii has left
  385. Valerian has joined
  386. muppeth has joined
  387. muppeth has joined
  388. Dave Cridland has left
  389. moparisthebest has joined
  390. lumi has joined
  391. moparisthebest has joined
  392. Dave Cridland has left
  393. alexis has joined
  394. alexis has left
  395. alexis has joined
  396. Kev has left
  397. j.r has joined
  398. j.r has joined
  399. alexis has joined
  400. daniel has left
  401. muppeth has joined
  402. rishiraj22 has joined
  403. Dave Cridland has left
  404. Dave Cridland has left
  405. Andrew Nenakhov has left
  406. ThibG has joined
  407. Andrew Nenakhov has joined
  408. jubalh has joined
  409. rishiraj22 has left
  410. Dave Cridland has left
  411. rishiraj22 has joined
  412. Guus has left
  413. Valerian has left
  414. Nekit has left
  415. Nekit has left
  416. Dave Cridland has left
  417. rishiraj22 has left
  418. Dave Cridland has left
  419. edhelas has left
  420. rishiraj22 has joined
  421. edhelas has joined
  422. j.r has joined
  423. alexis has joined
  424. lorddavidiii has left
  425. Ge0rG has left
  426. alexis has left
  427. alexis has joined
  428. Guus has left
  429. daniel has left
  430. Ge0rG has joined
  431. lorddavidiii has left
  432. j.r has joined
  433. Ge0rG has left
  434. moparisthebest has joined
  435. moparisthebest has joined
  436. jubalh has joined
  437. Dave Cridland has left
  438. Nekit has left
  439. alexis has left
  440. Dave Cridland has left
  441. alexis has joined
  442. Dave Cridland has left
  443. Dave Cridland has left
  444. Guus has left
  445. Dave Cridland has left
  446. alexis has left
  447. Valerian has joined
  448. Dave Cridland has left
  449. Dave Cridland has left
  450. pep. has left
  451. alexis has joined
  452. lumi has left
  453. Dave Cridland has left
  454. Dave Cridland has left
  455. j.r has joined
  456. rishiraj22 has left
  457. flow has left
  458. Dave Cridland has left
  459. Dave Cridland has left
  460. Dave Cridland has left
  461. jubalh has joined
  462. Dave Cridland has left
  463. Dave Cridland has left
  464. j.r has joined
  465. Valerian has left
  466. Valerian has joined
  467. Valerian has left
  468. Valerian has joined
  469. Valerian has left
  470. Valerian has joined
  471. Valerian has left
  472. Dave Cridland has left
  473. moparisthebest has joined
  474. Dave Cridland has left
  475. moparisthebest has joined
  476. Dave Cridland has left
  477. jubalh has joined
  478. karp has left
  479. karp has joined
  480. Dave Cridland has left
  481. Dave Cridland has left
  482. Dave Cridland has left
  483. Dave Cridland has left
  484. Dave Cridland has left
  485. ralphm has left
  486. Guus has left
  487. Dave Cridland has left
  488. Kev has left
  489. marc has joined
  490. ThibG has joined
  491. Dave Cridland has left
  492. ThibG has joined
  493. jubalh has joined
  494. j.r has joined
  495. Dave Cridland has left
  496. ThibG has joined
  497. ThibG has joined
  498. marmistrz has joined
  499. efrit has joined
  500. Dave Cridland has left
  501. Guus has left
  502. Dave Cridland has left
  503. Dave Cridland has left
  504. j.r has joined
  505. Dave Cridland has left
  506. Dave Cridland has left
  507. Dave Cridland has left
  508. Dave Cridland has left
  509. jere has joined
  510. jere has left
  511. jere has joined
  512. jubalh has joined
  513. Dave Cridland has left
  514. Dave Cridland has left
  515. jubalh has joined
  516. Dave Cridland has left
  517. j.r has joined
  518. SaltyBones has left
  519. SaltyBones has joined
  520. daniel has left
  521. j.r has joined
  522. Dave Cridland has left
  523. j.r has joined
  524. j.r has joined
  525. moparisthebest has joined
  526. moparisthebest has joined
  527. muppeth has joined
  528. Dave Cridland has left
  529. muppeth has joined
  530. Dave Cridland has left
  531. ralphm has joined
  532. efrit has left
  533. daniel has left
  534. jubalh has joined
  535. Dave Cridland has left
  536. tux has joined
  537. Dave Cridland has left
  538. daniel has left
  539. blabla has left
  540. Valerian has joined
  541. blabla has joined
  542. j.r has joined
  543. alexis has left
  544. j.r has joined
  545. alexis has joined
  546. marmistrz has joined
  547. mikaela has joined
  548. alexis has left
  549. Dave Cridland has left
  550. Dave Cridland has left
  551. winfried has left
  552. Dave Cridland has left
  553. Dave Cridland has left
  554. dos has joined
  555. SaltyBones has left
  556. SaltyBones has joined
  557. jjrh has left
  558. Dave Cridland has left
  559. andy has left
  560. andy has joined
  561. SamWhited has left
  562. SamWhited has joined
  563. daniel has left
  564. Dave Cridland has left
  565. la|r|ma has joined
  566. Dave Cridland has left
  567. marmistrz has joined
  568. Dave Cridland has left
  569. marmistrz has left
  570. Guus has left
  571. Guus has left
  572. j.r has left
  573. jjrh has left
  574. Maranda has joined
  575. j.r has joined
  576. ThibG has joined
  577. ThibG has joined
  578. Maranda since we're in disco#info topic, a good chunk of, if not all of, the examples in https://xmpp.org/extensions/xep-0045.html don't have the disco#info feature set (and apparently that's a MUST)
  579. intosi has left
  580. intosi has joined
  581. jonasw Maranda, I think it is generally understood that examples showing disco#info query replies are always exceprts
  582. Maranda is it?
  583. lskdjf has joined
  584. Maranda 🤔
  585. Maranda 😁
  586. jonasw all the XEPs do that
  587. Maranda I see nothing that makes me assume that, but okay.
  588. goffi re: HTTP Upload, would a del URL as suggested by Tess Sterr be a big deal? I don't think it complicates too much on server side, and after it's up to the client to keep it or not.
  589. Dave Cridland has left
  590. jonasw Maranda, it’s easy. disco#info has the disco#info feature as MUST. it is not included. ergo, the examples are excerpts :)
  591. jonasw goffi, it’s not very useful IMO
  592. goffi jonasw: why ?
  593. MattJ goffi, I'm not strictly against it (especially if optional for the server), but just because there's a delete URL doesn't mean the file will stay until it's deleted
  594. jonasw it would require the client to save the URL somewhere, and the multi-client story isn’t tight either
  595. Maranda jonasw, if it was an excerpts I would expect some ... or around in 'em, https://xmpp.org/extensions/xep-0045.html#disco-rooms don't look like excerpts (to myself at least).
  596. goffi it would solve the "oops I've uploaded nuclear codes" case, or at least reduce the problem.
  597. jonasw Maranda, that’s disco#items, not disco#info :)
  598. Maranda jonasw, disco#info examples are in there as well.
  599. Maranda brb
  600. jonasw Maranda, feel free to submit a patch which adds ... to all the disco#info examples
  601. goffi MattJ: I'm not sure to understand your sentence: "just because there's a delete URL doesn't mean the file will stay until it's deleted"
  602. goffi you mean if we want to upload it forever ?
  603. MattJ goffi, I was referring to the second part of your message, "and after it's up to the client to keep it or not"
  604. jonasw MattJ, that was referring to the delete URL I think
  605. MattJ Since earlier we were discussing retention times
  606. MattJ Oh, I see
  607. MattJ Ok, ignore me then :)
  608. goffi :)
  609. goffi but I think delete URL and retention time are complementary, and both are trivial to implement.
  610. MattJ I can certainly see value in DELETE, even if it only works from a single client it solves the "oops" problem
  611. goffi (where retention time can be "forever as long as you don't kill your quota")
  612. goffi daniel: ^
  613. Dave Cridland has left
  614. Maranda has left
  615. MattJ Though considering the "oops" problem, if your contact is online, they are probably already downloading your file, or downloaded it
  616. Zash Is that not an UX issue? That clients send stuff without any confirmation
  617. MattJ Does it ask for confirmation every time you press enter after typing a message?
  618. MattJ http://alistapart.com/article/neveruseawarning
  619. SaltyBones has left
  620. flow has left
  621. lnj has joined
  622. goffi MattJ: you may not have shared the link already (think about blogging for instance)
  623. Dave Cridland has left
  624. goffi it's not solving 100% the oops, as long at it's gone in the wild, it's not possible anyway. But it does mitigate it for sure.
  625. jere has left
  626. jere has joined
  627. Ge0rG MattJ: embedding the chosen file as a preview in the input box with an explicit [send] action might improve the UX
  628. pep. I'd prefer a DELETE as well, rather than a delete link that's not deterministic, so clients don't have to store anything
  629. andy has left
  630. lnj has left
  631. MattJ pep., that can't work, because it needs auth
  632. pep. Right, maybe if we had a solution within xmpp already to upload files.. ah wait
  633. winfried has left
  634. pep. MattJ, not an HTTP verb then
  635. pep. Just send an iq or sth, with the generated url and a delete action? :/
  636. ralphm has joined
  637. Ge0rG pep.: and the iq response yields an URL that you can run HTTP DELETE on?
  638. goffi pep.: but then you have to keep generated URL, it's the same as a delete URL.
  639. Ge0rG How to get rid of the inadvertently uploaded file in 12 easy steps.
  640. pep. Ge0rG, no, just tells you "yes it's deleted"
  641. pep. goffi, that's in the message already
  642. Dave Cridland has left
  643. Dave Cridland has joined
  644. Ge0rG pep.: but that doesn't work with external upload servers
  645. pep. Ge0rG, the answer of that external upload server doesn't go back through the xmpp server?
  646. pep. Ah wait no it's http..
  647. pep. pff
  648. goffi pep.: only if you are in a chat use case.
  649. pep. goffi, what's the other use case?
  650. Zash Avatar use for one
  651. pep. :(
  652. j.r has joined
  653. pep. seriously.. don't we already have stuff for that
  654. goffi yep, I was about to say blog, but you have the URL there too
  655. pep. Well in any case you already have the url in the message
  656. goffi and for avatar we can find it
  657. pep. Or the blog post, or the vcard, or..
  658. goffi so it's not a bad suggestion actually.
  659. pep. external upload server is going to be annoying
  660. pep. is there a way to predict that url, from the xmpp server, or is that handled by the upload server all the way down
  661. Zash Turtles
  662. MattJ pep., not without storing something
  663. pep. Do we care really? The xmpp server can tell the upload thing, "YOU SHALL USE THIS ID"
  664. Guus (I'm a big fan of servers shouting stuff to things)
  665. pep. :)
  666. Dave Cridland has left
  667. pep. Well either the servers stores, or the client stores
  668. pep. You decide
  669. MattJ pep., to be clear, there is no communication between Prosody and an external upload server, other than the admin giving them a shared secret
  670. pep. MattJ, yeah I got that bit
  671. pep. :/
  672. pep. So, server devs vs client devs fight?
  673. MattJ Has been going on for nearly two decades :)
  674. ralphm has left
  675. pep. Good luck
  676. Zash Is it not just a branch of the still ongoing mainfraimes vs fat workstations war?
  677. jjrh has left
  678. jjrh has left
  679. edhelas now we have both, big cloud-mainframes and fat terminals to run big JS apps
  680. jjrh has left
  681. jjrh has left
  682. lnj has joined
  683. Ge0rG the current round is serverless clown infrastructure
  684. Ge0rG But then again, Metal-as-a-Service is a thing too
  685. jjrh has left
  686. daniel has left
  687. alexis has joined
  688. Dave Cridland has left
  689. alexis has left
  690. Dave Cridland has left
  691. alexis has joined
  692. Dave Cridland has left
  693. ThibG has joined
  694. ThibG has joined
  695. alexis has joined
  696. karp has left
  697. karp has joined
  698. Valerian has left
  699. SaltyBones has joined
  700. marmistrz has joined
  701. jjrh has left
  702. dos has left
  703. daniel has left
  704. Valerian has joined
  705. daniel has left
  706. jjrh has left
  707. mikaela has left
  708. Yagiza has joined
  709. ThibG has left
  710. daniel has left
  711. lnj has left
  712. daniel has left
  713. Zash Maybe editor/iteam-related... but what if the XEP revision history was also made into an RSS feed?
  714. edhelas Zash we could even use a feed system built in XMPP, with publications or subscriptions 🤔 wait
  715. Zash Yes, put them into pubsub.xmpp.org!!
  716. MattJ I think I suggested this ~10 years ago
  717. Ge0rG We could just http upload an atom xml
  718. daniel has left
  719. Zash (When I say RSS, I mean Atom)
  720. edhelas Zash https://github.com/edhelas/atomtopubsub :)
  721. Zash yes yes and https://modules.prosody.im/mod_pubsub_feeds.html
  722. edhelas :)
  723. vanitasvitae has left
  724. lnj has joined
  725. lskdjf has joined
  726. flow has left
  727. flow has left
  728. flow has joined
  729. Zash and https://modules.prosody.im/mod_pubsub_post.html
  730. Valerian has left
  731. Valerian has joined
  732. Ge0rG has left
  733. dos has joined
  734. daniel has left
  735. daniel has left
  736. daniel has left
  737. rishiraj22 has joined
  738. edhelas https://news.ycombinator.com/item?id=17408041
  739. muppeth has joined
  740. muppeth has joined
  741. daniel that reminds me that i still have feedback for activity pub
  742. Dave Cridland has left
  743. Dave Cridland has left
  744. Kev has left
  745. jjrh has left
  746. ralphm has joined
  747. Ge0rG daniel: could you add a subsection about properly securing a http upload service in a way that won't allow uploading of html/js to compromise other web applications on the same infrastructure? e.g. an account login portal, or a webchat client
  748. MattJ Hmm, was there a standard for adding custom non-standard items in e.g. a MUC configuration form?
  749. MattJ I vaguely recall something, but I can't remember if it was just a discussion or actually a standard
  750. MattJ Aha, found in XEP-0068
  751. Zash -xep 68
  752. Bunneh Zash: Field Standardization for Data Forms (Informational, Active, 2012-05-28) See: https://xmpp.org/extensions/xep-0068.html
  753. MattJ https://xmpp.org/extensions/xep-0068.html#approach-fieldnames
  754. Dave Cridland has joined
  755. jjrh has left
  756. SaltyBones has left
  757. marmistrz has joined
  758. moparisthebest has left
  759. moparisthebest has joined
  760. pep. has joined
  761. SaltyBones has joined
  762. Seve/SouL has left
  763. pep. has joined
  764. rishiraj22 has left
  765. Seve/SouL has joined
  766. Seve/SouL has joined
  767. ralphm has left
  768. rishiraj22 has joined
  769. Guus has left
  770. dos has left
  771. Ge0rG has left
  772. nyco has joined
  773. dos has joined
  774. alacer has joined
  775. karp has left
  776. karp has joined
  777. waqas has joined
  778. Valerian has left
  779. Valerian has joined
  780. alacer has left
  781. labdsf has left
  782. alacer has joined
  783. Andrew Nenakhov has left
  784. Lance has joined
  785. Andrew Nenakhov has joined
  786. Lance has left
  787. Valerian has left
  788. SamWhited has left
  789. daniel has left
  790. daniel has joined
  791. alacer has left
  792. alacer has joined
  793. Guus has left
  794. Dave Cridland has left
  795. ralphm has joined
  796. Ge0rG has left
  797. lumi has joined
  798. Guus has left
  799. Guus has left
  800. Guus has left
  801. Guus has left
  802. Guus has left
  803. rishiraj22 has left
  804. Guus has left
  805. jjrh has left
  806. SaltyBones has left
  807. jjrh has left
  808. Guus has left
  809. rishiraj22 has joined
  810. Guus has left
  811. Guus has left
  812. lskdjf has left
  813. Guus has left
  814. Nekit has left
  815. Nekit has joined
  816. ThibG has joined
  817. Andrew Nenakhov has left
  818. jjrh has left
  819. Steve Kille has left
  820. tux has joined
  821. Steve Kille has left
  822. Steve Kille has joined
  823. Andrew Nenakhov has joined
  824. Guus has left
  825. alacer has left
  826. Andrew Nenakhov has left
  827. Andrew Nenakhov has joined
  828. j.r has left
  829. j.r has joined
  830. ThibG has left
  831. lskdjf has joined
  832. daniel has left
  833. daniel has joined
  834. daniel has left
  835. daniel has joined
  836. daniel has left
  837. daniel has joined
  838. Andrew Nenakhov has left
  839. Andrew Nenakhov has joined
  840. Zash has left
  841. alexis has left
  842. dos has left
  843. karp has left
  844. karp has joined
  845. SaltyBones has joined
  846. karp has left
  847. karp has joined
  848. marmistrz has joined
  849. dos has joined
  850. ta has joined
  851. SaltyBones has left
  852. SaltyBones has joined
  853. Guus has left
  854. daniel has left
  855. daniel has joined
  856. alacer has joined
  857. rion has left
  858. SamWhited has left
  859. blabla has joined
  860. SaltyBones has left
  861. SaltyBones has joined
  862. dos has left
  863. Andrew Nenakhov has left
  864. Valerian has joined
  865. Andrew Nenakhov has joined
  866. lskdjf has joined
  867. la|r|ma has left
  868. daniel has left
  869. daniel has joined
  870. flow Kev, Steve Kille: you are currently pursuing user#channel@domain(/resource) as MIX JID, is that still correct?
  871. rion has joined
  872. Dave Cridland has left
  873. anjan has left
  874. rishiraj22 has left
  875. Andrew Nenakhov has left
  876. Andrew Nenakhov has joined
  877. daniel has left
  878. daniel has joined
  879. Andrew Nenakhov has left
  880. Andrew Nenakhov has joined
  881. Kev has left
  882. marc has left
  883. SaltyBones has left
  884. Andrew Nenakhov has left
  885. Andrew Nenakhov has joined
  886. Steve Kille flow: yes. The spec of this is now in XEP-403, as this encoding is not needed for the basic message distribution specified in MIX core. This encoding is used for sharing presence status of MIX participants and to address Mix participants through the channel. The discussion concluded that it was desirable that each participant bare JID was unique to the participant.
  887. xnyhps has joined
  888. xnyhps has joined
  889. goffi has left
  890. SaltyBones has joined
  891. goffi has left
  892. goffi has left
  893. marmistrz has joined
  894. daniel has left
  895. daniel has joined
  896. alacer has left
  897. valo has joined
  898. dos has joined
  899. mikaela has joined
  900. anjan has left
  901. mikaela has joined
  902. jubalh has joined
  903. Guus has left
  904. valo has joined
  905. mikaela has joined
  906. anjan has joined
  907. lskdjf has joined
  908. mikaela has joined
  909. lskdjf has joined
  910. Guus has left
  911. blabla has joined
  912. jjrh has left
  913. edhelas has left
  914. jere has joined
  915. jjrh has left
  916. Valerian has left
  917. jere has joined
  918. valo has joined
  919. lorddavidiii has left
  920. lskdjf has joined
  921. j.r has joined
  922. jubalh has left
  923. j.r has joined
  924. valo has joined
  925. Yagiza has left
  926. xnyhps has left
  927. xnyhps has joined
  928. Guus has left
  929. goffi has left
  930. alexis has joined
  931. Guus has joined
  932. rishiraj22 has joined
  933. valo has joined
  934. alexis has left
  935. alexis has joined
  936. j.r has joined
  937. valo has joined
  938. Lance has joined
  939. daniel has left
  940. jubalh has joined
  941. daniel has joined
  942. j.r has joined
  943. j.r has joined
  944. waqas has left
  945. waqas has joined
  946. j.r has joined
  947. j.r has joined
  948. j.r has left
  949. j.r has joined
  950. alacer has joined
  951. lnj has left
  952. Chobbes has joined
  953. Valerian has joined
  954. rion has left
  955. rion has joined
  956. dos has left
  957. Valerian has left
  958. rishiraj22 has left
  959. muppeth has left
  960. muppeth has joined
  961. rion has left
  962. rion has joined
  963. Valerian has joined
  964. Valerian has left
  965. moparisthebest has joined
  966. waqas has left
  967. rishiraj22 has joined
  968. ta has joined
  969. alacer has left
  970. la|r|ma has left
  971. Syndace has joined
  972. moparisthebest has joined
  973. moparisthebest has joined
  974. lskdjf has left
  975. rion has left
  976. Syndace has joined
  977. la|r|ma has left
  978. lskdjf has left
  979. la|r|ma has left
  980. vanitasvitae has left
  981. lorddavidiii has left
  982. SamWhited has left
  983. goffi has left
  984. moparisthebest has joined
  985. moparisthebest has joined
  986. lskdjf has left
  987. lskdjf has left
  988. rishiraj22 has left
  989. Zash has left
  990. marmistrz has joined
  991. marmistrz has joined
  992. Nekit has joined
  993. dos has joined
  994. rishiraj22 has joined
  995. alexis has joined
  996. j.r has joined
  997. lskdjf has joined
  998. j.r has joined
  999. j.r has joined
  1000. j.r has joined
  1001. marc has joined
  1002. Guus has left
  1003. Guus has joined
  1004. Guus has left
  1005. Guus has joined
  1006. rishiraj22 has left
  1007. waqas has joined
  1008. rishiraj22 has joined
  1009. marmistrz has joined
  1010. MattJ has joined
  1011. mikaela has left
  1012. lumi has joined
  1013. labdsf has left
  1014. nyco has left
  1015. nyco has joined
  1016. Lance has left
  1017. marmistrz has left
  1018. marmistrz has joined