XSF logo XSF Discussion - 2020-02-05


  1. pdurbin has joined
  2. mukt2 has left
  3. mimi89999 has left
  4. mimi89999 has joined
  5. mukt2 has joined
  6. mukt2 has left
  7. calvin has left
  8. calvin has joined
  9. pdurbin has left
  10. debacle has left
  11. Marc has left
  12. Marc has joined
  13. mukt2 has joined
  14. calvin has left
  15. mukt2 has left
  16. alameyo has left
  17. alameyo has joined
  18. mukt2 has joined
  19. alameyo has left
  20. alameyo has joined
  21. mukt2 has left
  22. stpeter has left
  23. mukt2 has joined
  24. adiaholic has joined
  25. stpeter has joined
  26. mukt2 has left
  27. mukt2 has joined
  28. karoshi has left
  29. lskdjf has left
  30. david has left
  31. david has joined
  32. adiaholic has left
  33. adiaholic has joined
  34. stpeter has left
  35. mukt2 has left
  36. pdurbin has joined
  37. stpeter has joined
  38. Maranda has left
  39. pdurbin has left
  40. Maranda has joined
  41. andrey.g has joined
  42. adiaholic has left
  43. stpeter has left
  44. andrey.g has left
  45. mathijs has left
  46. adiaholic has joined
  47. mathijs has joined
  48. andrey.g has joined
  49. stpeter has joined
  50. mukt2 has joined
  51. mathijs has left
  52. mathijs has joined
  53. mukt2 has left
  54. stpeter has left
  55. Yagiza has joined
  56. stpeter has joined
  57. pdurbin has joined
  58. mukt2 has joined
  59. stpeter has left
  60. Tobias has joined
  61. gav has left
  62. stpeter has joined
  63. mukt2 has left
  64. mukt2 has joined
  65. stpeter has left
  66. mukt2 has left
  67. mukt2 has joined
  68. mukt2 has left
  69. mukt2 has joined
  70. stpeter has joined
  71. mukt2 has left
  72. pdurbin has left
  73. mukt2 has joined
  74. pdurbin has joined
  75. adiaholic has left
  76. adiaholic has joined
  77. stpeter has left
  78. mukt2 has left
  79. mukt2 has joined
  80. andy has joined
  81. andy has left
  82. stpeter has joined
  83. Nekit has joined
  84. mukt2 has left
  85. lorddavidiii has joined
  86. stpeter has left
  87. Max has left
  88. Max has joined
  89. mukt2 has joined
  90. Max has left
  91. Max has joined
  92. Max has left
  93. Max has joined
  94. waqas has joined
  95. stpeter has joined
  96. lorddavidiii has left
  97. lorddavidiii has joined
  98. lorddavidiii has left
  99. lorddavidiii has joined
  100. paul has joined
  101. stpeter has left
  102. paul has left
  103. adiaholic has left
  104. adiaholic has joined
  105. paul has joined
  106. david has left
  107. mukt2 has left
  108. mukt2 has joined
  109. stpeter has joined
  110. david has joined
  111. j.r has left
  112. stpeter has left
  113. j.r has joined
  114. wurstsalat has joined
  115. mukt2 has left
  116. mukt2 has joined
  117. stpeter has joined
  118. adiaholic has left
  119. adiaholic has joined
  120. Extarv has left
  121. Extarv has joined
  122. winfried Zash: free and open flu?
  123. mukt2 has left
  124. mimi89999 has left
  125. mimi89999 has joined
  126. stpeter has left
  127. karoshi has joined
  128. j.r has left
  129. stpeter has joined
  130. flow more like: free andn openly distributed epidemic
  131. aj has joined
  132. afrogeek has joined
  133. aj has left
  134. afrogeek has left
  135. stpeter has left
  136. afrogeek has joined
  137. afrogeek has left
  138. waqas has left
  139. debacle has joined
  140. Steve Kille has left
  141. stpeter has joined
  142. afrogeek has joined
  143. moparisthebest has left
  144. moparisthebest has joined
  145. lorddavidiii has left
  146. mimi89999 has left
  147. mimi89999 has joined
  148. Steve Kille has joined
  149. afrogeek has left
  150. lorddavidiii has joined
  151. afrogeek has joined
  152. stpeter has left
  153. afrogeek has left
  154. afrogeek has joined
  155. afrogeek has left
  156. afrogeek has joined
  157. dwd Yeah, kind of wishing this were a more restrictive licence.
  158. Marc has left
  159. afrogeek has left
  160. stpeter has joined
  161. afrogeek has joined
  162. adiaholic has left
  163. Marc has joined
  164. Guus How are you feeling today, dwd ?
  165. j.r has joined
  166. dwd Terrible. But nothing that can't be fixed. Doctors coming later this morning.
  167. Max has left
  168. Max has joined
  169. afrogeek has left
  170. Max has left
  171. Max has joined
  172. mathijs has left
  173. afrogeek has joined
  174. mathijs has joined
  175. Max has left
  176. ralphm I hear Guus lost 3 kg, so look on the bright side :/ Hope you feel better soon.
  177. Max has joined
  178. Guus (almost 4, actually)
  179. mathijs has left
  180. mathijs has joined
  181. Guus I hope you feel better soon, Dave.
  182. Guus when did this start? Only after you got back?
  183. afrogeek has left
  184. Max has left
  185. Max has joined
  186. stpeter has left
  187. j.r has left
  188. mathijs has left
  189. mathijs has joined
  190. mathijs has left
  191. mathijs has joined
  192. afrogeek has joined
  193. Steve Kille has left
  194. stpeter has joined
  195. afrogeek has left
  196. afrogeek has joined
  197. mathijs has left
  198. mathijs has joined
  199. afrogeek has left
  200. mathijs has left
  201. mathijs has joined
  202. afrogeek has joined
  203. stpeter has left
  204. afrogeek has left
  205. afrogeek has joined
  206. mimi89999 has left
  207. mimi89999 has joined
  208. afrogeek has left
  209. lskdjf has joined
  210. afrogeek has joined
  211. mimi89999 has left
  212. mimi89999 has joined
  213. stpeter has joined
  214. afrogeek has left
  215. adiaholic has joined
  216. afrogeek has joined
  217. mimi89999 has left
  218. mimi89999 has joined
  219. afrogeek has left
  220. afrogeek has joined
  221. stpeter has left
  222. afrogeek has left
  223. APach has left
  224. eevvoor has joined
  225. APach has joined
  226. pdurbin has left
  227. stpeter has joined
  228. debacle has left
  229. Dele Olajide has joined
  230. stpeter has left
  231. larma has left
  232. debacle has joined
  233. stpeter has joined
  234. eevvoor my colleague lost purse and smartphone on the way back of FOSDEM. He travelled the whole monday due to lost identity. But he is healthy.
  235. stpeter has left
  236. pep. I was surprised at some point because my bag had been moved from one place behind the booth to another part of the booth (behind the Matrix people!!) and under a pile of bags :x
  237. ralphm pep., you're welcome. I think I've made it clear the lounge was not a bag storage facility, so I regularly moved stray bags there.
  238. pep. I probably wasn't there when you said that, but ok
  239. ralphm I think I mentioned it at the Summit, too, but no worries.
  240. intosi That's something we say every year, in quite some abundance.
  241. ralphm Most of them were from the Matrix people.
  242. pep. intosi, not all of us have been involved for the same amount of time
  243. goffi has joined
  244. pep. Also that's a FOSDEM-specific thing, because I've been running other conferences and it usually works well that way :)
  245. ralphm Having bags behind a booth is typical indeed, but destroys the concept of a lounge. That's why I mentioned it at the end of the summit.
  246. ralphm (there were other factors that caused the lounge to not work this year, but that's a different discussion that I don't have time for to go into now)
  247. stpeter has joined
  248. eevvoor has left
  249. stpeter has left
  250. larma has joined
  251. larma has left
  252. larma has joined
  253. Kev has joined
  254. stpeter has joined
  255. pdurbin has joined
  256. pdurbin has left
  257. Marc has left
  258. Marc has joined
  259. stpeter has left
  260. eevvoor has joined
  261. stpeter has joined
  262. j.r has joined
  263. stpeter has left
  264. j.r has left
  265. Guus https://xmpp.org/extensions/xep-0424.html section 5: > Some clients may have been offline while the retraction was issued. The archiving service therefore MUST store the retraction message, regardless of whether the original message is deleted or replaced with a tombstone. This adds a server-sided restriction to this otherwise client-sided XEP, which I dislike. If the MAM implementation on the server does not follow this, retraction is very flaky (MAM retrieval will return the original message, but not the retraction). However, server support is not clearly signalled for in the XEP (service discovery examples imply that only partners are queried). Am I missing something?
  266. Guus (as the retraction message has no body, that message might not be archived by MAM implementations that are not aware of XEP-0424)
  267. pep. Maybe adding a store hint to the XEP would help?
  268. xsf has joined
  269. stpeter has joined
  270. xsf has left
  271. xsf has joined
  272. Dele Olajide has left
  273. Dele Olajide has joined
  274. flow but aren't hints deprecated?
  275. larma flow, it's deferred
  276. Ge0rG but it was very much disliked by the Council that decided on it last time
  277. j.r has joined
  278. larma There is no replacement for it other than fallback bodies which is stupid for things like retraction really
  279. lorddavidiii has left
  280. lorddavidiii has joined
  281. ralphm larma: fwiw, so is MAM itself (deferred) :-D
  282. Ge0rG there were two issues with Hints: a) you can't properly add hints later on; b) each hint has implications to a certain other XEP, and thus should better be described in that "master" XEP
  283. larma what do you mean by a)? And I agree to b) but that just means we need to update MAM instead of saying we don't do hints anymore
  284. Ge0rG larma: 334 contains the exhaustive list of hints. If you add a new hint, you need to version-bump Hints
  285. Ge0rG and if you don't version-bump, you can't have hints with new semantics that require special processing
  286. ralphm why?
  287. MattJ or just make another XEP with whatever other hints
  288. Ge0rG "Hints 4, this time it's serious"?
  289. pep. MattJ, same issue?
  290. MattJ What issue?
  291. MattJ The whole point is btw that they are "hints", it's meant to not be a disaster if they aren't followed
  292. pep. Not saying I understand what Ge0rG is saying, but bumping a XEP or creating a new one is technically equivalent in general
  293. MattJ They are also meant to be semantic, rather than tied to specific protocols
  294. Ge0rG pep.: with a new XEP, you don't auto-deprecate the old one, so you end up with five different Hints XEPs that all contain different hints
  295. MattJ So no-copy is not tied to Carbons, but any copying-to-other-resources mechanism
  296. pep. Ge0rG, even better!? :p
  297. larma Usually the hint should be in the XEP it belongs to, but now MAM and carbons don't have hints and those in 334 are widely supported and thus a de-facto standard. Also moving <store /> to MAM would mean that any other archiving XEP would need to redefine it and we'd need two hints. So at least for <store /> and related hints we should stay with the current
  298. Ge0rG pep.: so why not have each hint in the XEP that contains the actual processing semantics that are affected by the hint?
  299. Ge0rG larma: Carbons do have their own "hint"
  300. pep. Ge0rG, sure. It's not what I was replying to
  301. xsf has left
  302. xsf has joined
  303. Ge0rG but I think that Carbons and MAM are actually good causes to fix message routing and persistence semantics, i.e. IM 2.0
  304. larma We started this discussion about store hint 😉
  305. Ge0rG msg to bare --> persistent, copy-everywhere message to full --> ephemeral, no Carbon, no MAM, no offline store
  306. ralphm We at some point tried to have comprehensive processing rules (https://xmpp.org/extensions/xep-0079.html, AMP) and that was a bit of a failure.
  307. xsf has left
  308. xsf has joined
  309. xsf has left
  310. xsf has joined
  311. xsf has left
  312. Guus > There is no replacement for it other than fallback bodies which is stupid for things like retraction really I don't know if this is so stupid. It would make the retraction visible even to clients that do not support it - which makes a huge difference in semantics. Additionally, adding such a body has the side effect of the retraction having a better chance of being archived by existing MAM implementations.
  313. larma Ge0rG, I'd be fine with that, but legacy clients do send to full jid so we need to handle them (if we don't want a new IM network that is independent of the current)
  314. xsf has joined
  315. pep. Guus, how do you want to show retractions to clients that don't support it?
  316. pep. "The message you're still seeing above -- because I don't support retraction -- has been retracted" ?
  317. stpeter has left
  318. Dele Olajide has left
  319. Guus pep. basically. I'd include a copy of the retracted body, prefixed with 'retracted' or something.
  320. Guus it can be ugly
  321. Dele Olajide has joined
  322. Guus that, if anything, motivates client developers to add support. 🙂
  323. pep. It is to me, and also useless
  324. Ge0rG larma: yes, there would be tagging of IM 2 zones, and conversion from / to hints or somesuch at the 'border'. Incidentally, the same rules as discussed will apply there.
  325. Yagiza has left
  326. pep. Guus, you'd be helping the spammer to spam :P
  327. lorddavidiii has left
  328. Yagiza has joined
  329. Ge0rG Guus: that's a nice reminder to screenshot the messages!
  330. Guus Definitely not useless. A client that receives a retraction, but does not support _or_ show it through a fallback, is dangerous.
  331. xsf has left
  332. xsf has joined
  333. Guus both chat participants will have a very different understanding of the correspondence state.
  334. pep. Guus, how is it dangerous
  335. lorddavidiii has joined
  336. waqas has joined
  337. pep. I think we get into social territory, and I'd rather not
  338. Guus If I send you a bunch of messages, and retract one, and I am not aware that your client does not display the fact that I retracted that one message, very nasty stuff can happen.
  339. larma Ge0rG, so we do need hints, we just want to get rid of them longerm. Can we please stop with longterm being a reason to do stupid things now?
  340. pep. Guus, I could say the same of every single feature that's socially used in context.
  341. pep. I still use presence information and talk about it sometimes, should I put that as fallback body somewhere?
  342. Guus no, this is not a social thing
  343. Guus this is a semantic thing
  344. Ge0rG larma: what if we want to use longterm to not do stupid things now?
  345. Guus you, as a receiver, missed the fact that I, as the sender, changed the semantics.
  346. pep. You removed a spam message for convenience. It's fine if I still see it.
  347. Guus spam, sure
  348. pep. Or you removed information that I wasn't supposed to see, well too bad.
  349. Guus why would I delete my own spam, btw?
  350. pep. Not your own
  351. moparisthebest also true of any "styling" XEPs right? changed meaning and all that
  352. Guus you can only retract your own messages with that XEP, afaik.
  353. pep. Ah ok I had moderation in mind, similar case
  354. larma Ge0rG, we agree that longterm we do the IM 2 network without (or with less) hints and that the IM Legacy network that we are using now needs hints, so why is that a reason to deprecate hints when it is needed for the network we use now?
  355. Guus The fact that the receiver does not get that the information that was not ment to be sent is removed, makes the sender unaware of the fact that it was not ment to see that information.
  356. Guus that really has very nasty real-world problems.
  357. xsf has left
  358. xsf has joined
  359. larma deprecation before replacement sounds like a stupid concept for me
  360. Guus If will lead to situations where people do not _trust_ the messages they receive from XMPP.
  361. Guus and that is killing.
  362. Ge0rG larma: I told you the reasons I remember for Council not advancing hints.
  363. pep. I don't really agree with this assessment
  364. Guus pep. suffer from it once, and you will. Trust me on that one.
  365. pep. [citation required]
  366. larma Ge0rG, I wasn't specifically talking about you, but more about what seems to be a general thing in XSF (there also were voices to deprecate OMEMO without replacement etc)
  367. pep. - I don't like XXX - Oops that wasn't for you - retracted: I don't like XXX
  368. pep. :P
  369. Ge0rG larma: regarding Hints, I even do agree with the argumentation
  370. Guus pep. now imagine that you didn't type "- Oops that wasn't for you"
  371. pep. Guus, so you see twice "I don't like XXX" in clients that don'T support it?
  372. Guus (why would you type that, if you expect the receiving entity to receive the retraction)
  373. pep. Very much fixing the issue
  374. Guus You see: - I dont like XXX - RETRACTED: I dont like XXX which is ugly as hell, but at least has the correct, intended, semantic value.
  375. pep. How does that help with anything
  376. Dele Olajide has left
  377. pep. Now you've seen twice that XXX (potentially YOU), I don't like.
  378. Dele Olajide has joined
  379. Guus For clients that do not support the XEP, the message has been displayed at least once anyways, so there's little additional harm.
  380. xsf has left
  381. pep. For clients that do support it the message may be removed, so the fallback is useless
  382. Guus If you don't include the fallback message in the retraction, the receiving entity might be completely unaware that the message is retracted.
  383. Guus Those would only see: - I don't like XXX
  384. Guus (no retraction)
  385. andrey.g has left
  386. larma Guus, same as if the retraction message got lost 😉
  387. larma legacy clients might not be doing MAM
  388. Guus yes, so make sure that the retraction message never gets lost, by adding a fallback body. That way, XEP-support clients will remove/hide the retracted message, while clients that do not support the XEP can at least be trusted to 'receive the meaning'.
  389. Guus this is not a MAM issue.
  390. Guus the fact that it also makes it more likely that MAM implementations might behave a bit better is a nice side-effect.
  391. Guus the fact that it also makes it more likely that existing MAM implementations might behave a bit better is a nice side-effect.
  392. larma if my legacy client does not do mam/carbons it is likely to happen that this client does not receive the retraction message at all
  393. pep. I really don't like how we've been shoving everything into <body/> lately. This is of course not as bad as 393, as there would be a tag alongside (and hopefully the message would only be used for this), but it seems to be a trend anyway that everything and anything needs to appear in body as well
  394. larma let's call my legacy client pidgin, which apparently is the most popular XMPP client
  395. pep. It's like we're trying to write protocols on top of XMPP's <body/>
  396. Guus we can think of all kinds of situations in which this still would not work - but at the very least, it'd be a considerable improvement of not doing a fallback.
  397. Guus pep. I'm very much with you that this is ugly.
  398. Guus but I think it is necessary.
  399. adiaholic has left
  400. adiaholic has joined
  401. pep. I don't
  402. Guus a situation in which a message was retracted by the sender, without the recipient being aware of it, must be avoided.
  403. larma Guus, I believe that those clients that work proper today (= not Pidgin and other legacy clients) will support retraction soonish once it's a stable standard
  404. Dele Olajide has left
  405. Guus larma: we cannot have an ecosystem that is intentionally broken for some clients, and which is constantly waiting for the more modern clients to pick up the newer features (being broken untill they do).
  406. Dele Olajide has joined
  407. Guus we must have a decent fallback.
  408. Guus that's why it's called just that, a fallback.
  409. larma Guus, we already broke Pidgin effectively
  410. pep. Also these fallback things force any implementation to support things they wouldn't want to support
  411. Guus They don't force you to do anything
  412. pep. In a way yes. Now you're sending me that ugly RETRACTED: foo
  413. pep. Or > foo\n<reaction>, or.. some other fallback
  414. Guus I stand by my point that it is so much better to show that ugly message instead of receiving a retraction that your client completely ignores.
  415. Guus That's simply dangerous
  416. vanitasvitae has left
  417. xsf has joined
  418. vanitasvitae has joined
  419. Guus ideally, the recipient shouldn't receive the retraction at all, of course, using service discovery. But how does that work with a user that uses two different clients, of which just one supports retractions?
  420. pep. Yes the "send everything to all clients because MAM/carbons" argument
  421. xsf has left
  422. xsf has joined
  423. xsf has left
  424. Guus I need to get back to work.
  425. xsf has joined
  426. larma (completely unrelated) I started to look into issues of XEP-0385 because of Stickers. My proposed changes are now rather substantial (I'd even want to change the title), should I maybe better make a new XEP instead?
  427. pdurbin has joined
  428. calvin has joined
  429. calvin has left
  430. calvin has joined
  431. xsf has left
  432. andrey.g has joined
  433. flow larma, i'd present the "new" xep the community and potentially council and see if there is a clear opinion on that
  434. flow also maybe reach out to Tobias the xep385 author
  435. pdurbin has left
  436. Tobias larma, what kind of issues?
  437. stpeter has joined
  438. j.r has left
  439. larma Tobias, - Focus on media, not generic for any file type - Mixed content, body can not be used as a fallback - Depends on jingle file transfer for the metadata - Uses underspecified URIs - Uses XEP-0372 in underspecified fashion - Number of MUSTs that seem odd to me (must support http file upload and jingle ft, must specify description, media-type and hash)
  440. Tobias larma, media basically is any file format, not? i mean images, photos, videos, pdf, etc.. I don't see it limiting the kind of data you share...it only makes recommendations for video/images with regard to what should be supported so there is some interoperability.
  441. Tobias underspecified URIs?
  442. Tobias you mean these https://tools.ietf.org/html/rfc6920 ?
  443. larma It says "inline media sharing" which kind of implies that I can't use it to share an executable for example. The use cases literally only say how to share and receive a photo
  444. larma I was referring to the jingle pub uris which can hardly be used for file transfer because they just share a jingle session, but don't specify what those jingle sessions actually are. The client has to guess that it probably is the latest iteration of Jingle File Transfer
  445. larma (my proposal changes it to use the jinglepub element defined in XEP-0385 which allows providing a jingle description element)
  446. Tobias protocol wise there is nothing limiting the kind of things you can share, might as well share exe, zip, .iso images or whatever.... sure maybe examples are missing but i just went with the most common use case, of sharing audio/video/images.
  447. Tobias defined in 385 or 358?
  448. larma 358, sorry
  449. Tobias ah..ok
  450. larma I am not saying those can't be addresses in 385, but the changes are rather significant. Also the fact that you could use it for every file type IMO doesn't change the intention. The fact that there are SHOULDs for media codecs is an issue for a generic file transfer XEP
  451. Tobias the SHOULDs are there for interoperability in user interface
  452. larma Tobias, which are only needed for media, not for files
  453. Tobias yes
  454. larma which makes it unsuited for file transfer
  455. ralphm larma: FWIW, I didn't consider XEP-0385 to be limited to photos, videos at all. At VEON we considered it for all kinds of static media, as is mentioned in this XEP's introduction.
  456. Tobias i don't see how making recommendations for increased interop leads to it being unsuitable to share PDF, ISO, or whatever
  457. ralphm larma: On top of that, it is useful to define MTI codecs for common media you can show inline.
  458. larma Tobias, because those are SHOULD, which means I as a client SHOULD have a good reason to not implement those codecs
  459. stpeter has left
  460. larma The codecs are there because you do imply a user interface (that displays the media inline, as it says in the title). If I don't want to use this, many things in this XEP become obsolete
  461. ralphm I do have some concerns with this spec though: I'm not convinved about the 'inline' part, and its reliance on References in the way it is currently done. I think I'd rather have References optional and as a sibling. The inline nature is then also optional (for when you refer to a URL to a picture that is then included in the message, much like Twitter's media entities).
  462. larma This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f
  463. ralphm larma: but you agree that having a list of MTI codecs doesn't prevent /other/ types of media to be transferred as 'other files'?
  464. Tobias for me it's kind of obvious that if you don't support inline display at all, the MTI recoomendations don't matter
  465. larma ralphm, I am not saying it does prevent that, it's just that the overall tone of the XEP is "use this to share media that is displayed inline" instead of "use this to share files"
  466. ralphm larma: I like the example, and think that's how XEP-0385 should work. Optionally with References to mark-up the text in the body.
  467. ralphm larma: right
  468. nyco-2 has joined
  469. Daniel > This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f +1
  470. Tobias i imagined that clients either get it via HTTPS or by https://xmpp.org/extensions/xep-0234.html#requesting from some JID
  471. ralphm larma: note that I had a similar usage in my blog post https://ralphm.net/blog/2019/09/09/fastening
  472. waqas has left
  473. ralphm (scroll down to the image of a mouse)
  474. ralphm (although it is all inside in references, I don't think it has to)
  475. ralphm (although it is all inside in references, because it is referring to the previous message, I don't think it has to)
  476. jonas’ > This is what I'd like to have: https://gist.github.com/mar-v-in/48e0f3466871e6e149d166ad71728d1f +1, though a mechanism for thunbnails would be good
  477. ralphm jonas’, that example has a thumbnail?
  478. Tobias jonas’, you could just have a 2nd file-transfer element in there for the hash of the thumbnail
  479. larma jonas’, I was thinking about thumbnails. Best thing I guess would be to use something like ppm in a data uri, but unfortunately most clients probably wouldn't support ppm out of the box and I think it doesn't even have a mime type
  480. jonas’ ralphm: right.
  481. jonas’ however, having two different syntaxes for mimetype etc is weird
  482. jonas’ sibling file elements would make more sense? would also allow for alternative mime types for the same thing (embedded video for example)
  483. larma I was thinking of additional thumbnail as in blurha.sh-like thumbnails
  484. ralphm Unfortunately SIMS doesn't explicitly point to https://xmpp.org/extensions/xep-0264.html, but it is exactly what Tobias said.
  485. Tobias jonas’, kind of... but with the idea of SIMIS ( hashes of media/files + metadata + source ) it should be easy to extend it to provide sources for the hash of the thumbnail
  486. larma according to xep-0264, If the URI scheme is 'cid:' then the identifier MUST refer to a bit of binary data as described in Bits of Binary (XEP-0231) [1]
  487. larma so transport is already defined for 264 thumbnails
  488. ralphm The nice thing about XEP-0264, I think, is that it builds on Bits of Binary (XEP-0231).
  489. ralphm And then have an external storage for the actual, larger, media.
  490. j.r has joined
  491. larma The problem with bob thumbnails is that even those are pretty large for some networks (like mobile when you are throttled to 64kbit/s it can be a significant delay to fetch such image first)
  492. ralphm larma: if we'd add some kind of identifier to individual <media-sharing/> elements, then you could have a sibling references element to mark up the URL in the body, together with earlier suggestions I made with of having proper child elements in references instead of the current 'type' attribute: <reference start="0" end="100" xmlns="urn:example:reference:0"> <media id="[the id here]"/> </reference>
  493. Tobias my motivation for 285 was mostly to have a protocol describing what is shared and less so how (because there have been numerous file transfer protocols in the past). Furthermore, by making it content based (via secure hashes) you can easily cache things or have a small reference to the media in MAM where you know in a couple years that this messages includes an image with a certain hash. How you get the image is out of scope for the spec. Clients will likely have a cache of shared media, servers might help here too.
  494. larma ralphm, if we allow content in the body then we can no longer have a fallback body
  495. andy has joined
  496. ralphm larma: I looked at your example?
  497. ralphm larma: my markup just says: that (fallback) body there has a URL in that, that is actually this media object I'm describing next to me, too.
  498. larma That seems unnecessary to me, as that's already what it is supposed to be
  499. larma That's like adding <i-behave-standards-compliant /> 😀
  500. ralphm larma: I think it gives us both worlds: 1) a readable plain-text message, 2) a fully marked up thing. Compare how Tweets work: there's plain text representation with a bunch of additional meta data (Tweet Entities and more) that make it possible to show a richer version of it.
  501. ralphm You then don't "need" a fallback anymore.
  502. larma I specifically don't want this to be a complex mixed content message, it should just be a file transfer
  503. lorddavidiii has left
  504. larma The fallback in my example will be understood as a file transfer by the majority of clients already, allowing it to be anything else will cause it to no longer be displayed as such
  505. Daniel yes. i know what twitter is doing. that certainly has a place. but i also want a method to just share a file
  506. larma ^ that
  507. Daniel like we do now with xoob; but with more meta information
  508. ralphm larma: that's fine. I'm not saying you must, I'm saying you could, when you want to preserve the possibility to do 'inline' media sharing, this is how you could do it.
  509. lorddavidiii has joined
  510. xsf has joined
  511. ralphm I.e. adding the <reference/> would be optional, and not needed if you 'just' share a file.
  512. larma So that kind of concludes to: I want my proposal to be a new XEP because it does not provide what you call "inline" media sharing
  513. xsf has left
  514. xsf has joined
  515. ralphm So it a) removes the references wrapper, with a way to still optionally do references.
  516. ralphm (b)
  517. larma (I specifically don't want that as it adds a lot of complexity for a completely different usecase that I don't necessarily want to cover)
  518. ralphm And my proposal is such that XEP-0385 can be both what Tobias designed, with a slightly altered format, and what you want.
  519. ralphm The references could be left out entirely, or indeed in the References spec. The only thing you'd need is a way to refer to the media sharing element in case there are more than 1.
  520. waqas has joined
  521. larma ralphm, it's not about what the protocol can do, it's about the question what clients need to do when implementing it. I want to be able to implement file transfer in a compliant way that doesn't require me to support mixed content
  522. ralphm And you can.
  523. Wojtek has joined
  524. ralphm My proposal is basically: take XEP-0385, remove the wrapping references element, maybe add an id attribute.
  525. ralphm (instead of redoing all of this in a new spec)
  526. ralphm Tobias: does that sound right?
  527. larma So what do I do if I receive a message like https://gist.github.com/mar-v-in/fff8ff23ef8704229cb3e1dcccf79bfa but don't support mixed media? How do I display it? Just the body or just the file share?
  528. xsf has left
  529. larma In my XEP I would just display the file share because the body should only be a fallback so anything in it is expected to be lost.
  530. larma In your XEP I'd need to implement mixed media which can be rather complex in some clients
  531. ralphm That's a valid point.
  532. calvin has left
  533. ralphm I guess I assumed you'd always show the body.
  534. ralphm The thing is, if I go with what you suggest, how do we get to a place where we _do_ want a body with references?
  535. larma ah ok, that might not have been obvious from the XML I shared
  536. larma ralphm, that's why I said that it makes sense to consider this new thing (which I call SFS) something else than SIMS 😉
  537. ralphm larma: but then how do you "upgrade" from having just SFS, to something with SFS *and* a body with references?
  538. Daniel i guess we can just keep sims
  539. Daniel and do either sfs or sims
  540. larma it's two different things, there is no straight forward "upgrade" path
  541. Daniel it's just two different things
  542. ralphm Daniel, having two specifications that do exactly the same thing with different fallback behaviour seems suboptiomal, though.
  543. Daniel it's not the same thing
  544. ralphm Daniel, having two specifications that do exactly the same thing with different fallback behaviour seems suboptimal, though.
  545. Daniel one is twitter. the other one is file transfer
  546. Daniel (they can probably share their media meta data format wrapper element)
  547. ralphm Daniel: one is sharing media, and having a body that you show, two is sharing media with a body you only show when the media sharing element is not implemented.
  548. krauq has left
  549. larma two is not sharing media, two is sharing a file
  550. ralphm a file is a medium, I don't understand the difference.
  551. larma something that may be impossible to display inline
  552. adiaholic has left
  553. adiaholic has joined
  554. ralphm I'm not sure if it is that easy to make a clear division. A rich client could show PDFs or other documents "inline". Like Slack does.
  555. Daniel in any case i think it is perfectly fine to try both. if during that experiment we realize that there is a lot of overlap we can still merge one into the other
  556. jonas’ and ISOs in an inline qemu window
  557. jonas’ thanks to qemu.js or how it’s called
  558. ralphm Daniel, oh, let me be clear: I'm a firm believer in accepting proposals as XEPs and then experiment and pick a "winner" later.
  559. ralphm I cannot think of many reasons to *not* accept a specification that lands in the inbox. Other than known or suspected IPR concerns, and whatever formatting requirements Editors set.
  560. larma Oh and by the way, I think we shouldn't use references for that, but use message markup instead 😉
  561. ralphm larma: we can have a separate discussion on this, but I think message markup and references are the same thing with slightly different flavors.
  562. adiaholic has left
  563. adiaholic has joined
  564. larma XEP-0372 seems to mix markup with semantic which is very odd to me
  565. stpeter has joined
  566. larma mmh maybe semantic is the wrong word there
  567. ralphm larma: in my blog post, I altered the syntax, so that there's a <reference/> element with start and end, and then child elements that define the meta data (mention, media, message, link), so that you can do extend it independently.
  568. larma It definitely feels wrong to have markup change the routing behavior which is what the mention reference is supposed to do
  569. ralphm with message markup as I think you suggested, you also have a "thing with start and end" and "meta data about that thing" (emphasise, strike through, etc)
  570. david has left
  571. david has joined
  572. xsf has joined
  573. ralphm larma: wait huh?
  574. ralphm larma: what does "change the routing behavior" mean?
  575. larma well, as we discussed on summit we want push notifications based on mentions.
  576. xsf has left
  577. larma those are completely distinct concepts to me tbh
  578. ralphm I see mention notifications as a potential server-side side effect
  579. ralphm You can totally have mentions without notifications. References is primarily about markup.
  580. larma I don't want server side side effects based on markup, that's my point
  581. larma Also what I don't like about XEP-0372 is this "everything is a uri" concept
  582. ralphm That's ok. References doesn't specify or suggest notifications.
  583. jonas’ larma, +1 against the everything is a URI thing
  584. ralphm larma: did you look at my examples I mentioned two times now?
  585. jonas’ see also: https://mail.jabber.org/pipermail/standards/2018-March/034559.html
  586. larma ralphm, I did
  587. jonas’ re markup with side-effects: markup is inherently semantic.
  588. jonas’ or at least, Message Markup (my XEP) is, that’s the whole point
  589. ralphm larma: I intentionally moved away from the everything-is-a-URI model
  590. ralphm By having child elements with clear specific semantics
  591. larma yeah, but what is the purpose of the reference thing then? It just seems like a superfluous container element
  592. larma jonas’, Yeah, semantic is the wrong word, I just don't want markup to change how we deliver messages and I felt this was kind of the result of the discussion on summit
  593. jonas’ larma, I think it’s the right thing to do
  594. ralphm larma: my idea was that you have a common thing (start and end attributes) and a specific description of what is to be found there. If you'd like to move the start and end attributes to the 'child' element, you could, but it isn't great for later (independent) extension with other types.
  595. jonas’ mentions influence notification routing inherently
  596. jonas’ to make this transparent to the user, it is required that it’s tied to some kind of markup, IMO
  597. calvin has joined
  598. ralphm jonas’, if you want this to be tied to a specific hint, I'd not be opposed I think.
  599. larma jonas’, but I might want to change notification routing without explicitly mentioning (slack does support that) or mention someone without notifying them (I don't think slack supports *that*)
  600. ralphm larma: well, you can still mention people in one-on-ones and channels the mentionee isn't in, and then you get asked what to do in the latter case.
  601. jonas’ larma, I think the former case is a bad idea
  602. jonas’ and the latter case is too
  603. larma jonas’, I want to talk about someone without them being notified, isn't that something rather usual?
  604. jonas’ larma, then you don’t @mention them, what’s the problem?
  605. jonas’ @mention -> notification
  606. ralphm I'd say in Slack, the thing that causes the notification is not unlike the user configuring keyword mentions for themselves.
  607. xsf has joined
  608. larma I want client to correctly reference that person (e.g. display their profile on hover)
  609. ralphm (which is a different way to look at it)
  610. jonas’ larma, I suppose a mention-reference could have a silent=true thing in it, which would then also cause appropriate rendering in the recipients client
  611. larma How would it be displayed differently?
  612. jonas’ but the way it’s presented and the way it’s routed needs to be tied together to avoid confusion and intransparent behaviour
  613. jonas’ larma, probably grayed out or something?
  614. ralphm Should it be displayed differently?
  615. jonas’ I don’t know the specifics, but it needs to be distinguishable. otherwise, people wonder where their notifications went.
  616. jonas’ and then they blame the software because it doesn’t ping them when they’re mentioned
  617. jonas’ being pinged when you’re mentioned (unless you turned that off) is pretty much standard and expected
  618. j.r has left
  619. ralphm jonas’, if I implemented this, receiving side, I'd want all mentions of me to notify me, independently of what the sender suggested.
  620. larma re notify without mentioning, in slack if a message does not cause a user to be notified I can force a notification anyway. It makes sense if I want the message to be delivered in their silent hours even if I don't explicitly mention them
  621. jonas’ ralphm, that’s also an option I guess
  622. stpeter has left
  623. ralphm And you can influence the behavior with hints, maybe.
  624. larma jonas’, I think the question how to do it client side (also how the client decides if they want to add the notify=false hint or not) is completely irrelevant for the spec
  625. krauq has joined
  626. xsf has left
  627. xsf has joined
  628. larma But I personally would prefer if we just add a <notify jid="that@person.com /> hint to the message instead of having the server parse the markup. That notify also has the positive side effect that it can be used outside the e2ee so servers can actually parse it on e2ee messages
  629. xsf has left
  630. xsf has joined
  631. ralphm larma: but you agree that actual notification is the responsibility of the receiving server then?
  632. larma ralphm, it's always the receiving server to decide, the question is what the server SHOULD base it's decision on
  633. larma I'd rather do it explicit in the message rather than implicit through specific markup
  634. ralphm Well, you could also take the position that the sending client or server explicitly send a notification.
  635. ralphm I don't like that one, but you could.
  636. ralphm So I wanted to make it clear.
  637. ralphm I'd be happy with a please-notify-hint.
  638. larma nah I want the sending client to add a hint such that the receiving server (and maybe even client) don't need to parse markup. If they want to do that anyway that's another story
  639. larma It just shouldn't be the intended way to parse markup
  640. ralphm Taking into account the use case of "forcing" a notification during dnd. Not sure how to spec that, yet.
  641. ralphm larma: sounds good to me
  642. nyco Sorry for this interruption: Call for help of promotion of the newsletter! https://fosstodon.org/@xmpp/103606882304524026 https://twitter.com/xmpp/status/1225073484176543747 https://www.linkedin.com/posts/xmpp-standards-foundation_xmpp-jabber-decentralised-activity-6630841055023558656-SFhw/ https://www.reddit.com/r/xmpp/comments/ezb3tg/the_xmpp_newsletter_full_speed_xmpp_universe_04/ https://www.facebook.com/photo.php?fbid=10158047204828454&set=p.10158047204828454&type=1&theater Like and Share, if you want, what you want, how you want :)
  643. ralphm larma: a while back you asked about the use of the <reference/> wrapper. Did my explanation make sense?
  644. Wojtek has left
  645. Wojtek has joined
  646. xsf has left
  647. j.r has joined
  648. larma ralphm, I kind of see the point. But then we would still probably want to merge reference into message markup maybe?
  649. ralphm I'd be happy with a common <markup> wrapper with start/end, and then merge the markup, so you can have <emphasize/> and <mention/> next to each other.
  650. ralphm Or something similar, I'm not sure what's better, start/end on the specific element itself, or on a wrapper, in the face of distributed extensibility. In non-XMPP cases with XML, you'd use namespaced attributes, but I think I don't like that either.
  651. Nekit has left
  652. nyco <emphasize/> also <empathize/> or <ironize/>?
  653. Nekit has joined
  654. stpeter has joined
  655. ralphm yes
  656. ralphm in your own namespace
  657. waqas has left
  658. pdurbin has joined
  659. j.r has left
  660. mukt2 has joined
  661. pdurbin has left
  662. Dele Olajide has left
  663. Dele Olajide has joined
  664. mukt2 has left
  665. larma has left
  666. larma has joined
  667. lovetox has joined
  668. alameyo has left
  669. alameyo has joined
  670. vanitasvitae has left
  671. vanitasvitae has joined
  672. xsf has joined
  673. xsf has left
  674. xsf has joined
  675. mathijs has left
  676. mathijs has joined
  677. xsf has left
  678. mathijs has left
  679. mathijs has joined
  680. Daniel has left
  681. Daniel has joined
  682. Yagiza has left
  683. lovetox has left
  684. lovetox has joined
  685. mathijs has left
  686. mathijs has joined
  687. nyco-2 has left
  688. nyco-2 has joined
  689. Nekit has left
  690. mathijs has left
  691. mathijs has joined
  692. eevvoor has left
  693. Steve Kille has joined
  694. nyco-2 has left
  695. calvin has left
  696. calvin has joined
  697. sonny has left
  698. lovetox has left
  699. Steve Kille has left
  700. mathijs has left
  701. mathijs has joined
  702. mathijs has left
  703. mathijs has joined
  704. lovetox has joined
  705. Steve Kille has joined
  706. pdurbin has joined
  707. mukt2 has joined
  708. j.r has joined
  709. lovetox has left
  710. lovetox has joined
  711. lovetox has left
  712. pdurbin has left
  713. sonny has joined
  714. lovetox has joined
  715. lovetox has left
  716. eevvoor has joined
  717. lovetox has joined
  718. mukt2 has left
  719. nyco-2 has joined
  720. Wojtek has left
  721. adiaholic has left
  722. adiaholic has joined
  723. Nekit has joined
  724. nyco-2 has left
  725. nyco-2 has joined
  726. alameyo has left
  727. alameyo has joined
  728. calvin has left
  729. calvin has joined
  730. Wojtek has joined
  731. lovetox has left
  732. fippo has left
  733. fippo has joined
  734. fippo has left
  735. fippo has joined
  736. andrey.g has left
  737. mukt2 has joined
  738. andrey.g has joined
  739. Shell has joined
  740. adiaholic has left
  741. adiaholic has joined
  742. mukt2 has left
  743. mathijs has left
  744. mathijs has joined
  745. calvin has left
  746. calvin has joined
  747. moparisthebest anyone see https://snikket.org/ ? pretty neat move
  748. lorddavidiii has left
  749. lorddavidiii has joined
  750. moparisthebest what is it? messaging platform. how do I chat on it? grab this app. how can I run my own server? run this snikket docker container.
  751. moparisthebest ah, figured out who's involved now, nice work!
  752. jonas’ :D
  753. jonas’ MattJ, ^
  754. moparisthebest had to track down git repo and commits to figure it out lol, was linked to in jmp.chat muc first
  755. MattJ :)
  756. pep. moparisthebest, #old :p
  757. jonas’ pep., never too old for praise
  758. moparisthebest was it linked in here before? I could have missed it I admit
  759. jonas’ also, shaming people for re-sharing "old" news puts an odd incentive against sharing stuff at all
  760. pep. jonas’, can't joke anymore?
  761. pep. I'm not shaming anybody
  762. MattJ moparisthebest: I don't think it was linked here in particular
  763. pep. I haven't seen it here either
  764. MattJ I did publish a Prosody blog post yesterday: https://blog.prosody.im/introducing-snikket/
  765. j.r has left
  766. j.r has joined
  767. MattJ To be honest the early reaction from XMPP community members wasn't exactly encouraging :)
  768. Wojtek has left
  769. MattJ But pretty much anyone here is not the target audience
  770. jonas’ pep., sorry, I didn’t get the joke part
  771. stpeter so true :-)
  772. Wojtek has joined
  773. neshtaxmpp has left
  774. moparisthebest if XMPP is weak at one thing, it's marketing, this looks good to me
  775. MattJ But hopefully the blog post gives some background - I've heard a lot of "why another Conversations fork?!"
  776. wojtek has joined
  777. MattJ And yes, a bunch of it is simply a layer of marketing :)
  778. moparisthebest reaction in jmp.chat muc which is more users than developers/xmpp community looks promising
  779. stpeter moparisthebest: what's the chatroom for jmp?
  780. MattJ Yes, had a demo at the XMPP stand at FOSDEM this past weekend and I think it's fair to say it was a success
  781. pep. Everywhere I mentioned it outside of XMPP circles the reaction was good
  782. moparisthebest stpeter, xmpp:discuss@conference.soprani.ca?join
  783. stpeter thanks!
  784. jonas’ moparisthebest, can you hint the admins of that room that their room title isn’t particularly useful (if set at all): https://search.jabber.network/search?q=discuss%40conference.soprani.ca
  785. wojtek has left
  786. pdurbin has joined
  787. mukt2 has joined
  788. moparisthebest jonas’, thanks, they set one!
  789. Wojtek has left
  790. Wojtek has joined
  791. jonas’ moparisthebest, :+1:
  792. jonas’ (the usual delay of ~1h applies)
  793. mukt2 has left
  794. pdurbin has left
  795. debacle has left
  796. matkor has left
  797. matkor has joined
  798. calvin has left
  799. Daniel has left
  800. Daniel has joined
  801. lovetox has joined
  802. Neustradamus has left
  803. Daniel has left
  804. Daniel has joined
  805. calvin has joined
  806. ralphm MattJ: I personally think, I hoped to express, that I think the idea and execution so far for Snikket is really good.
  807. ralphm MattJ: I like that you focus on a product rather than the underlying protocol
  808. ralphm MattJ: I'm curious why you think the community wasn't encouraging. What kind of feedback did you get? Everyone I talked to at FOSDEM thought it was great.
  809. Zash Seen a bunch of things like "Why yet another Conversations fork?", "What's the point of this, we already have Prosody?"
  810. MattJ Nothing serious or surprising - I think it probably didn't click for many people (who weren't at FOSDEM) until I laid it out in the blog post yesterday
  811. MattJ Partly my fault, I'd aimed to post that sooner, but got held up by last minute demo preparation
  812. moparisthebest *personally* I see something like that, and the first thing I do is dig to see what the underlying protocol is, software is written in etc etc, I *suspect* I'm not a normal average person in that regard
  813. moparisthebest I see "XMPP" and instantly know all the advantages that provides, that are spelled out there in plain english, again I suspect the normal person does not
  814. MattJ Right, I totally get it, it's not a surprising reaction at all for a community of geeks :)
  815. sonny has left
  816. sonny has joined
  817. MattJ We are used to assessing technology, but there is very little new tech here
  818. fippo the general concern with the trend to package client+server is that it reduces the need for specs (and spec compliance). not a concern in this case i think because of a long record :-)
  819. moparisthebest and to be clear I'm meaning this as praise, to a "normal person" I think that snikket looks a lot better than "grab any XMPP client or server and join in"
  820. Zash Given the flexibility of XMPP, having clients and servers optimized for each other makes sense.
  821. MattJ moparisthebest: yeah, the FOSDEM reception was great
  822. MattJ Lots of people new to XMPP had a simple gateway in, that was easily explained as a "self-hostable WhatsApp/Telegram/Signal/..."
  823. mukt2 has joined
  824. debacle has joined
  825. stpeter Snikket: The Gateway Drug to Hardcore XMPP [tm]
  826. MattJ Time will tell :)
  827. ralphm stpeter: :-D
  828. stpeter Not the best marketing, I suppose. ;-)
  829. Daniel has left
  830. ralphm MattJ: you should have put the logo in your post
  831. MattJ Yeah, would have delayed it further though :)
  832. ralphm Eh, ok.
  833. MattJ Currently working on docker images that actually work on a Raspberry Pi like we advertised :D
  834. MattJ (current ones are x86 only)
  835. ralphm Drug dealers often lie, so there's that.
  836. mukt2 has left
  837. Daniel has joined
  838. Daniel has left
  839. Maranda has left
  840. Maranda has joined
  841. calvin has left
  842. calvin has joined
  843. Shell has left
  844. Daniel has joined
  845. lovetox has left
  846. lovetox has joined
  847. Daniel has left
  848. lovetox has left
  849. lovetox has joined
  850. j.r has left
  851. j.r has joined
  852. lorddavidiii has left
  853. gav has joined
  854. andy has left
  855. krauq has left
  856. pdurbin has joined
  857. mukt2 has joined
  858. Tobias has left
  859. Daniel has joined
  860. lovetox has left
  861. eevvoor has left
  862. calvin has left
  863. mukt2 has left
  864. pdurbin has left
  865. Daniel has left
  866. nyco-2 has left
  867. nyco-2 has joined
  868. Dele Olajide has left
  869. Daniel has joined
  870. gav has left
  871. Daniel has left
  872. krauq has joined
  873. gav has joined
  874. kuvoh has joined
  875. kuvoh has left
  876. kuvoh has joined
  877. kuvoh has left
  878. mukt2 has joined
  879. Daniel has joined
  880. Wojtek has left
  881. alameyo has left
  882. alameyo has joined
  883. Daniel has left
  884. neshtaxmpp has joined
  885. Half-Shot[m] has left
  886. Half-Shot[m] has joined
  887. mukt2 has left
  888. Neustradamus has joined
  889. karoshi has left
  890. Neustradamus has left
  891. Neustradamus has joined
  892. karoshi has joined
  893. goffi has left
  894. Half-Shot[m] has left
  895. Half-Shot[m] has joined
  896. calvin has joined
  897. paul has left
  898. Daniel has joined
  899. mukt2 has joined
  900. pdurbin has joined
  901. Daniel has left