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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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.


  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


  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


  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


  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