XMPP Summit - 2020-01-31

  1. Zash has left
  2. zash has left
  3. lsdlfjljuie has left
  4. thdouk has joined
  5. thdouk has left
  6. SubPub has joined
  7. lsdlfjljuie has joined
  8. thdouk has joined
  9. debacle has left
  10. thdouk has left
  11. SubPub has left
  12. SubPub has joined
  13. Alex has left
  14. Alex has joined
  15. thdouk has joined
  16. adiaholic has left
  17. adiaholic has joined
  18. adiaholic has left
  19. adiaholic has joined
  20. thdouk has left
  21. Zash has joined
  22. thdouk has joined
  23. thdouk has left
  24. adiaholic has left
  25. adiaholic has joined
  26. Zash has left
  27. thdouk has joined
  28. thdouk has left
  29. SubPub has left
  30. SubPub has joined
  31. thdouk has joined
  32. kusoneko has left
  33. kusoneko has joined
  34. kusoneko has left
  35. kusoneko has joined
  36. thdouk has left
  37. Kev has joined
  38. Tobias has joined
  39. thdouk has joined
  40. vanitasvitae has left
  41. vanitasvitae has joined
  42. Kev has left
  43. thdouk has left
  44. winfried has left
  45. winfried has joined
  46. Martin has joined
  47. MattJ Might not make the 9:30 train...
  48. eevvoor has joined
  49. winfried The others are meeting at 9:00 in the hotel lobby....
  50. kusoneko has left
  51. kusoneko has joined
  52. kusoneko has left
  53. kusoneko has joined
  54. winfried has left
  55. winfried has joined
  56. thdouk has joined
  57. Zash has joined
  58. eevvoor has left
  59. thdouk has left
  60. pep. ok we just missed this train..
  61. MattJ I made it
  62. Alex has left
  63. Alex has joined
  64. winfried has left
  65. winfried has joined
  66. Alex has left
  67. Alex has joined
  68. kingu has left
  69. kingu has joined
  70. lsdlfjljuie has left
  71. lsdlfjljuie has joined
  72. winfried has left
  73. winfried has joined
  74. SubPub has left
  75. SubPub has joined
  76. winfried has left
  77. winfried has joined
  78. Kev has joined
  79. winfried has left
  80. winfried has joined
  81. pep. ETA 10:20
  82. MattJ K
  83. MattJ Most people just this minute arrived, so getting drinks and setting up stuff, I doubt we'll get much into anything before you get here
  84. winfried has left
  85. winfried has joined
  86. Holger But we need your power!
  87. vanitasvitae has left
  88. vanitasvitae has joined
  89. vanitasvitae Do we have a pad for day 2?
  90. vanitasvitae Or is https://etherpad.wikimedia.org/p/XMPPSummit24Day1 being reused?
  91. MattJ Let's make a new one, but link both to each other?
  92. vanitasvitae sure
  93. MattJ They probably won't live here permanently, we can move them over to the wiki at the end
  94. vanitasvitae yeah
  95. vanitasvitae Are you opening a new one or should I?
  96. MattJ Go for it
  97. vanitasvitae https://etherpad.wikimedia.org/p/XMPPSummit24Day2
  98. dwd@dave.cridland.net has joined
  99. goffi has joined
  100. Guus is there anyone (trying to) join remotely?
  101. alameyo has left
  102. alameyo has joined
  103. goffi Guus: I'm trying now
  104. Guus It should be up and running.
  105. goffi sorry I had an emergency, trying now
  106. goffi yes it's fine
  107. goffi I'm in
  108. Zash <hacker voice> I'm in
  109. Zash Yes hello
  110. Martin has left
  111. Martin has joined
  112. pep. Oh you did hear me!
  113. vanitasvitae to be sure, IM NG was the next iteration of "Message Routing", right?
  114. vanitasvitae Like, the plans to ditch full jid routing from last years summit?
  115. MattJ vanitasvitae, correct
  116. vanitasvitae alright.
  117. vanitasvitae And the reason for wanting IM NG is exactly?
  118. MattJ https://xmpp.org/extensions/xep-0409.html is the initial proposal
  119. vanitasvitae What does it solve?
  120. vanitasvitae ah, thanks
  121. MattJ The routing rules in RFC 6121 were made before Carbons, MAM, etc.
  122. jonas’ vanitasvitae, several things
  123. MattJ We layered Carbons and MAM on top of them to try to fix the gaps with e.g. having multiple devices, sometimes offline
  124. jonas’ 1. if you have IM-NG, clients are kind of responsible for declaring if their message needs to be broadcast and archived (by sending to bare JID), and servers are left with less to guess
  125. jonas’ 2. it removes some "undefined behaviour" wiggle-room from RFC 6121 regarding handling of bare and full-JID messages. specifically, full-JID messages will never be re-routed to a different full-JID under IM-NG, and bare JID messages will always be received by all (online + MAM-capable) resources
  126. MattJ They solved 80% of the problems, and added complexity for servers (and clients) that have to handle all the interactions between these different things
  127. vanitasvitae alright, thanks for the clarification 😉
  128. jabberjocke has joined
  129. MattJ IM-NG is essentially and XMPP 2.0 thing without throwing away all the good bits
  130. MattJ It will make life easier for developers
  131. dwd@dave.cridland.net Yeah. Just listen to how much easier this is.
  132. vanitasvitae I can tell 😛
  133. Zash Just YOLO flag day it!!!eleven
  134. thdouk has joined
  135. pep. (I'm a bit lost around that re minutes)
  136. vanitasvitae Yeah, me too 😀
  137. vanitasvitae So basically the discussion is about uncertain rules for routing of error messages, right?
  138. vanitasvitae Like, edge case handling?
  139. dwd@dave.cridland.net You're welcome to speak aloud. More voices would be useful here I think.
  140. MattJ The current rules are not uncertain - error messages for e.g. delivery errors simply go to the sending device only
  141. vanitasvitae makes sense to me.
  142. debacle has joined
  143. pep. I'd appreciate if somebody(tm) with a bit more understanding of the situation could have a look at minutes on this topic
  144. MattJ The reason it's complex is purely because we need backwards compatibility with all the existing clients and servers
  145. thdouk has left
  146. MattJ Once we phase out Carbons and the various hacks around it, things will be a lot simpler
  147. pep. *shocked*
  148. jabberjocke has left
  149. jabberjocke has joined
  150. debacle has left
  151. debacle has joined
  152. hantu.sc has joined
  153. Intosi 6121 SP2
  154. pep. Service Pack 2 ?
  155. vanitasvitae "Redstone Update"
  156. larma Something unstable you probably don't want to start using for the first year?
  157. hantu.sc has left
  158. vanitasvitae Strange, today there are so many people named "Angie" around...
  159. vanitasvitae Kev keeps repeating "I am Angie too" for some reason...
  160. vanitasvitae Pretty sure he is lying
  161. Kev sighs
  162. Intosi inserts GIPHY of Picard facepalm
  163. hantu.sc has joined
  164. jabberjocke has left
  165. jabberjocke has joined
  166. thdouk has joined
  167. vanitasvitae The internet is asking if there are any plans to "secure metadata".
  168. vanitasvitae I guess apart from e2ee there is maybe the sender-less messaging on the agenda, right?
  169. goffi I've been to Froscon already, it's open to non german, and very nice meeting
  170. goffi (and nice food)
  171. vanitasvitae I found it less community oriented and more business focussed than FOSDEM.
  172. MattJ vanitasvitae, my personal opinion is "no" - there are other solutions that already do a better job at hiding metadata
  173. MattJ They make a certain set of compromises to achieve that
  174. thdouk has left
  175. adiaholic has left
  176. flow I think we can, besides taking care of the low hanging fruits right now, only start consider securing metadata after the majority of messages exchanged in xmpp is encrypted. One step after another
  177. MattJ flow, and how will the server know where to deliver messages, presence?
  178. flow MattJ, I am not sure if I expressed myself where well as I think you may misunderstood me
  179. flow *very well
  180. flow *after the majority of the payload of messages exchange in xmpp
  181. vanitasvitae you could at least hide the recipient from the sending server
  182. MattJ vanitasvitae, and how would it know where to deliver to?
  183. Kev https://xmpp.org/extensions/xep-0430.html https://xmpp.org/extensions/xep-0386.html https://xmpp.org/extensions/xep-0388.html https://xmpp.org/extensions/xep-0198.html
  184. vanitasvitae well, it obviously has to know the domain jid, but not the exact recipient
  185. vanitasvitae better than nothing
  186. vanitasvitae 😛
  187. MattJ vanitasvitae, which goes against the "it's good to run your own server" model that I'm pushing for :)
  188. flow I think it is not productive to put much effort into metadata encryption while we do not even encrypt a majority of the payload
  189. MattJ because you'll never guess who a message to the domain "matthewwild.co.uk" may be destined for!
  190. vanitasvitae 😛
  191. MattJ You /can/ hide metadata, but it requires a drastically different protocol architecture to achieve that (e.g. something like a gossip protocol)
  192. flow Also if you are afraid that metadata is an issue, then you probably should not use XMPP at all. That said, if we can protected metadata easily, we sure should consider it.
  193. dwd@dave.cridland.net You could do onion routing over XMPP, of course.
  194. MattJ You can *already* do XMPP over onion routing
  195. dwd@dave.cridland.net Yes, the other way aorund.
  196. Intosi So a hyper onion?
  197. flow I think you lay every other protocol over xmpp, like vuvuzela.io, how interoperable that would/could be is another question
  198. jabberjocke has left
  199. jabberjocke has joined
  200. hantu.sc has left
  201. jabberjocke has left
  202. jabberjocke has joined
  203. jabberjocke has left
  204. jabberjocke has joined
  205. kusoneko has left
  206. kusoneko has joined
  207. kusoneko has left
  208. kusoneko has joined
  209. jabberjocke has left
  210. jabberjocke has joined
  211. COM8 has joined
  212. COM8 has left
  213. thdouk has joined
  214. COM8 has joined
  215. COM8 has left
  216. COM8 has joined
  217. COM8 has left
  218. thdouk has left
  219. hantu.sc has joined
  220. pep. https://upload.bouah.net/upload/9-alObjSJAkgMdDF/R-XEUGHJTb6uBMfnLNL5Yg.jpg
  221. pep. this is day2 topics
  222. adiaholic has joined
  223. pep. oh MattJ did it already :p
  224. pep. Wait no
  225. pep. Missing the pink dots!
  226. eevvoor has joined
  227. eevvoor has left
  228. winfried And now something totally different... Sunday morning I will be presenting on the XMPP extensions. What extensions do you think I definitely should mention to the Fosdem audience?
  229. pep. What kind of extensions are you presenting? What's the goal?
  230. pep. Funny XEPs? Unused XEPs? Useful XEPs?
  231. pep. (And what for)
  232. vanitasvitae Compliance Suite 2020 😉
  233. pep. Yeah I was gonna say
  234. winfried My goal is that I discovered that developers considering XMPP find the idea of a modulair standard hard to grasp, so I want to do 2 things: explain how the extensions work (as process, idea, not technically) and I want to mention some nice examples on the way.
  235. winfried Compliance suite will definetly be mentioned, because it is a good starting point for many usecases
  236. MattJ winfried, there are three things that people who vaguely know XMPP are concerned about: 1) too many XEPs 2) stuck in the past 3) fragmentation (different clients implement different XEPs)
  237. MattJ So answers are: 1) C Suites / deprecation of old XEPs 2) new XEPs are being submitted and implemented almost every week 3) C Suites aim to solve this
  238. jabberjocke has left
  239. jabberjocke has joined
  240. pep. (of which 3) is definitely a feature of XMPP.. just that these people don't get it :x)
  241. pep. Sorry mismatching parentheses
  242. MattJ winfried, heh, someone just linked to your talk in a different MUC :)
  243. vanitasvitae I'd also point out that even if you do some centralized service, XMPP is a good choice as there is already a tried and tested codebase + implementations and building on top of that with custom stuff is very easy.
  244. vanitasvitae Not that I'd suggest doing centralized stuff, but still
  245. vanitasvitae many devs want to
  246. thdouk has joined
  247. winfried MattJ: good points, I'll make the C-suites more dominant in my talk
  248. winfried MattJ: what MUC?
  249. MattJ winfried, conversations@conference.siacs.eu
  250. adiaholic has left
  251. winfried MattJ: thanks, can't join... ;-)
  252. jabberjocke has left
  253. jabberjocke has joined
  254. winfried vanitasvitae: yeah, I would also like to mention some specific usecases, like real time text (which is very useful for communication with deaf people)
  255. vanitasvitae yeah nice idea
  256. winfried So this is your chance to upvote your great but very specialist XEP for a great exotic usecase ;-)
  257. thdouk has left
  258. moparisthebest vanitasvitae, I've thought about the "hiding metadata" thing a bit, the problem being it's only easy 1 way (hiding the recipient from your own server), hiding your JID from the recipients server requires something totally different and much harder, and then there is the roster problem :'(
  259. moparisthebest I still think it's likely worth doing
  260. winfried moparisthebest: it would be quite trival to make an onion routing component for XMPP and turn the XMPP network in a onion routing system....
  261. moparisthebest that might be the way to go to solve both ways the same, then you just have to hide the roster from your own server and you've got yourself a complete system :)
  262. jabberjocke has left
  263. jabberjocke has joined
  264. vanitasvitae Coffee break after this?
  265. flow Is there any reason why we should give up the possibility to implement bind2 or sasl2 indepentently from each other?
  266. jabberjocke has left
  267. jabberjocke has joined
  268. hantu.sc has left
  269. vanitasvitae coffee!!!
  270. Syndace If someone knows how to get fresh air into this room, please make it flow
  271. pep. (ha ha?)
  272. nyco yes, it stinks
  273. vanitasvitae yeah flow, go for it!
  274. hantu.sc has joined
  275. flow I have opened the window in my office, does that help?
  276. vanitasvitae You have to also open the <stream/>
  277. Kev Could you take some of the fresh air and publish it to pep. please?
  278. thdouk has joined
  279. thdouk has left
  280. Kev Are the "IC" trains any different to the "S" trains for my train ticket I bought at the station machine?
  281. Daniel since the ticket machine doesn’t let you choose between the two i always assumed the same ticket is fine for both
  282. Kev Ta.
  283. jabberjocke Any plans for evening?
  284. MattJ Sleeeeeeeeep
  285. Intosi Food as well. There will also be drink, I suspect.
  286. eevvoor has joined
  287. Kev has left
  288. goffi Movim has its own sticker sets already
  289. MattJ goffi, bundled? hosted somewhere?
  290. goffi Initially I think it was shared with BoB, but I'm not sure nowadays, maybe SIMS
  291. nyco yes, goffi based on XHTML-IM?
  292. goffi nyco: Initially, but I think it's SIMS now
  293. goffi not sure, to be checked with edhelas
  294. Zash But does it have a sticker store?
  295. goffi also about file size and directories, we have already all that with Jingle, I have a component doing this for file sharing
  296. nyco and themed emojis for announcers
  297. Link Mauve No, Movim ships them and it’s AFAIK not extensible.
  298. goffi Zash: no store I think they are bundled with the software
  299. Link Mauve He sponsored the drawing of the packs it ships.
  300. goffi most of those problems are the same as with avatar
  301. goffi so it would be nice to have some kind of factorisation there
  302. goffi (different sizes, image formats, etc)
  303. vanitasvitae A Security Consideration would be that sticker sets are external data, so the processing must be secure
  304. Daniel Yes. Also either leaking your ip or your jid everywhere
  305. Daniel That's why having your server copy them over might be interesting
  306. Tobias has left
  307. Tobias has joined
  308. goffi I think that we actually need a server side HTTP proxy that user can request with some kind of identifier, instead of something specific to stickers or anything else.
  309. jonas’ I think mastodon-ish-things have something similar
  310. moparisthebest I get the impression other protocols don't really care about leaking private data all over the place
  311. ivucica has joined
  312. thdouk has joined
  313. vanitasvitae well, centralized systems dont have this issue at all
  314. moparisthebest (not saying XMPP should be like that, the opposite)
  315. goffi About (X)HTML, please take into account that Movim and SàT are doing blogging, and we already manage a large set of HTML (i.e. not only XHTML-IM). We should probably have a XEP describing good security practive with that.
  316. zash has joined
  317. Syndace I think immutable sets and and copying the set to your own server is the way to go
  318. Syndace but happy to discuss that later/on list
  319. vanitasvitae for privacy yes
  320. vanitasvitae for flexibility no 😀
  321. goffi I don't get everything that MattJ is saying :-/
  322. jabberjocke Intosi: > Food as well. There will also be drink, I suspect. At hotel or other place? Just arrived to Brussels
  323. MattJ goffi, the words or the meaning?
  324. nyco goffi : 3rd point, he forgot :)
  325. ivucica Server-provided stickers would be awesome. Well-known/discoverable pubsub node for sticker collection which lists pubsub nodes containing individual stickers?
  326. goffi MattJ: I don't get all the words ^^.
  327. goffi Are we willing to do a XHML only for IM, or something also used for blogging?
  328. MattJ goffi, my words were saying that 1) clients need to sanitize stuff already anyway 2) XHTML-IM v1 was harder to sanitize because it allows and heavily uses CSS
  329. thdouk has left
  330. goffi oh no, here comes markdown again :(
  331. goffi MattJ: OK, thx
  332. adiaholic has joined
  333. goffi Mardown is not a wire format, it's handy and should be use in client, but we should use a real wire format for sharing the content.
  334. goffi Markdown*
  335. jonas’ oh dear
  336. jonas’ message markup all over again?
  337. jonas’ what goffi says is true
  338. moparisthebest goffi, why is XHTML better as a wire format than, say, CommonMark ?
  339. goffi what's wrong with https://xmpp.org/extensions/xep-0394.html? I really love this one?
  340. vanitasvitae Regarding stickers: The internet notes that Zom (the XMPP version) also supported stickers and may be worth a look.
  341. goffi moparisthebest: well, first it's XML, and XMPP is XML
  342. moparisthebest that's probably not a reason
  343. Intosi goffi: agreed on 394.
  344. goffi but I don't say that XHTML-IM is necessarily the best way, I really love XEP-0394, it clean, elegant, and extensible
  345. goffi it's*, sorry for the typos
  346. moparisthebest you still need some specialized parser/display logic to display both XHTML and CommonMark, neither of which comes by default with XML or XMPP
  347. Daniel moparisthebest: is this an encumbrance?
  348. moparisthebest :D
  349. goffi Does anybody takes blogging into consideration, as there are only 2 clients with blogging, I have the feeling it's always ignored.
  350. Daniel so we want something like message styling but make it explict that message styling is being used?
  351. vanitasvitae *.*
  352. jabberjocke has left
  353. jabberjocke has joined
  354. goffi Just for the record, here are the complains I've made about markdown in the past (cc moparisthebest): https://mail.jabber.org/pipermail/standards/2017-October/033592.html
  355. moparisthebest goffi, those are all correct as a criticism against "markdown" because it's not specified, but "CommonMark" is specified
  356. pep. goffi, I don't like 394 for what larma just said. It's leaving 393-like info in body without saying that these characters can be removed
  357. pep. And then we're back to parsing body
  358. pep. https://lab.louiz.org/poezio/poezio/issues/3455#note_7769 < what Link Mauve is talking about
  359. larma pep., `<span start="9" end="15" fallback="*"><emphasis/></span>`
  360. larma ^ solves the issue of knowing if it's fallback or not
  361. goffi pep.: I don't get what is left in body with XEP-0394? it's all in <markup> isn't it?
  362. vanitasvitae no
  363. vanitasvitae the original message in in <body>
  364. adiaholic has left
  365. adiaholic has joined
  366. vanitasvitae <markup> only contains markers where certain formatting starts and ends
  367. goffi vanitasvitae: yes the message in <body> and markup in <markup>, that's the point
  368. vanitasvitae okay, I only followed with half an eye, maybe I missed something 😛
  369. larma goffi, the problem is that you may want to have fallback (using 393) in <body> but not display that when 394 is supported
  370. goffi pep.: vanitasvitae: I was meaning what markup is left in the <body>?
  371. goffi larma: why do I want a fallback as long as the message body is visible by everybody? Compatible client add style, not others, what's wrong with that?
  372. moparisthebest whenever you send the same thing in 2 different formats/languages/whatever that opens up all those security issues that aren't practically solvable :/
  373. goffi moparisthebest: that's an issue with legacy XHTML-IM I agree, but not with XEP-0394, the message content is only in <body>, or am I missing something?
  374. pep. Sorry I'm not taking much notes atm as I'm taking part in the discussion actively :x
  375. moparisthebest yep that's right goffi
  376. goffi no worries pep., and thanks a lot (and to the other) for those notes, it helps a log to understand when you're not there.
  377. larma goffi, the "formatting" might be an emphasize that is required to transfer the message
  378. larma loosing this emphasizing might change the message in some cases
  379. goffi Sorry to insist about blogging, but I think we need a XEP to explain best practices to sanitize HTML, and probably a different markup for IM
  380. alameyo has left
  381. alameyo has joined
  382. goffi larma: yes, but in this case fallback can cause trouble too, be can go far with that.
  383. larma goffi, that's why it's complicated 😉
  384. moparisthebest larma, true, like if I'm quoting hitler I likely would not like anyone to think I said it directly instead :/
  385. goffi OK so we're talking only about IM markup there, I wanted to be sure, thanks
  386. nyco thx goffi
  387. goffi (blogging is part of XMPP, even if not IM)
  388. adiaholic has left
  389. goffi the issue also with markdown, is that there are billions of more or less (in)compatible parser, and developer will use the available one
  390. adiaholic has joined
  391. goffi so rendering may be different because markdown_js is not exactly the same as markdown_rust or markdown_js
  392. moparisthebest goffi, and that's not an issue if you specify CommonMark, right?
  393. moparisthebest https://commonmark.org/ that one
  394. Daniel i think we can at least make some improvements to the current situation by having clients that use 393 make it explicit that they are doing this
  395. goffi moparisthebest: if you are 100% sure that all libs used are commonmark compatible, I guess this would not be an issue, but I highly doubt that we'll have something rendered identically everywhere.
  396. moparisthebest goffi, so like HTML then? :D
  397. goffi Daniel: yes please make it explicit, that one of the main issue I have with XEP-0393
  398. Daniel i mean that's a very easy fix
  399. pep. goffi, that's not enough to me, saying explicitely you do 393
  400. goffi moparisthebest: We have only 2 HTML rendered left, so it's not an issue anymore ;)
  401. Daniel that has no huge side effects
  402. goffi renderer*
  403. pep. Parts of your message could not be markup
  404. goffi maybe 3 with servp
  405. goffi servo
  406. moparisthebest goffi, I'm saying there are plenty of HTML parsers/renderers, and none render quite the same
  407. moparisthebest even though HTML is a standard, same situation with CommonMark
  408. moparisthebest 393 just documents what all XMPP/IRC/email clients have been doing since forever, it never removes characters, it's fine as-is imho
  409. goffi pep.: I agree with that, and I was thinking that putting everything in <body> was not necessary anymore with OMEMO now that we have XEP-0420
  410. goffi moparisthebest: Again, I'm not saying that (X)HTML is the best option, I'm pushing more for XEP-0394
  411. moparisthebest also to clarify cramming CommonMark in <body> without any indication would be awful I think everyone agrees, but as far as a specified transport, it's just as valid as XHTML or any other standard
  412. goffi I just need XHTML for blogging (specially when importing external sources like RSS/Atom).
  413. moparisthebest also CommonMark doesn't solve any problems with regard to sanitization, it's a XHTML super-set, so all sanitization rules still apply (any valid XHTML is valid CommonMark)
  414. pep. goffi, agreed, putting everything in body is not a requirement for future work
  415. vanitasvitae I think Marking up messages is a non-problem 😛
  416. goffi We should do like with stickers: a syntax server where everybody can upload a syntax parser in a home made language, so everybody can use it favorite one :D
  417. vanitasvitae 😀
  418. hantu.sc has left
  419. vanitasvitae markup as a service
  420. goffi Thanks a lot for the video which was pretty good this year, and live report on etherpad, here and activityPub
  421. moparisthebest Just upload and download webasm binaries goffi ? :D
  422. goffi moparisthebest: great :)
  423. moparisthebest Secure! Flexible! Trustworthy!
  424. moparisthebest Pick only the middle one
  425. jonas’ so not commonmark or anything like it?
  426. jonas’ sounds like a plan!
  427. pep. And in 5 years everybody wants to do BBCode again
  428. pep. markup fallback is going to be tricky
  429. goffi except with XEP-0394
  430. pep. But then maybe clients will finally understand that they have to translate the input :p
  431. vanitasvitae The internet notes "I think it is important to announce to a client that the text is markdown styled. Similar to how OMEMO messages are announced as such. "
  432. pep. goffi, 394 + fallback yes, still the same issue
  433. jonas’ goffi, '394 is meh though. I’d prefer to go back to a restricted XHTML-IM subset.
  434. moparisthebest 394 isn't bad, but yet-another markup format that no one uses etc etc, specify something like CommonMark where all the hard work is done and call it a day
  435. adiaholic has left
  436. adiaholic has joined
  437. goffi the big difference with XEP-0394 is that markup is separated from body content and meaning, no other solution offers that.
  438. goffi so if you don't support it, you still have the plain text body, without having to clean it yourself or to use any kind of fallback.
  439. moparisthebest which has it's own set of problems
  440. thdouk has joined
  441. dwd@dave.cridland.net has left
  442. goffi moparisthebest: which ones exactly? I still don't get what's wrong with that.
  443. moparisthebest > we should kill all $race_here because they are worthless subhumans
  444. moparisthebest except your client doesn't support 394, so it's not rendered like a quote
  445. moparisthebest it's rendered like I said it
  446. moparisthebest that's... less than ideal
  447. pep. I'm stuck outside, nothing at the front, can somebody open? :p
  448. pep. all good
  449. winfried has left
  450. winfried has joined
  451. goffi moparisthebest: well you have usually have context, and you'll have this issue with any markup fallback
  452. moparisthebest it's possibly less of an issue if you just display raw CommonMark ? :/
  453. moparisthebest maybe raw CommonMark in <body> with a flag stating it's CommonMark, then if it is, you can safely parse/display it as intended, and if not the fallback is just to display it directly?
  454. goffi moparisthebest: you're going with XEP-0393 then
  455. moparisthebest there is no perfect solution here I think
  456. winfried has left
  457. winfried has joined
  458. goffi seing that we're all arguing with that for years, I guess the perfect solution if it exists is not obvious :)
  459. winfried has left
  460. winfried has joined
  461. jabberjocke has left
  462. jabberjocke has joined
  463. Kev has joined
  464. moparisthebest I just suspect there can never be a perfect solution here: 1. same message, multiple formats/languages - no way to tell if they are different 2. standard non-plaintext format (XHTML/CommonMark/394) - if not supported, plaintext fallback could change meaning or be unreadable for any number of reasons 3. no plaintext fallback - well, no plaintext fallback :)
  465. moparisthebest I *think* that about covers all the options?
  466. MattJ Why did you italicize 'think'?
  467. moparisthebest did I? :)
  468. MattJ Oh, you're right, it's underlined in my other client
  469. MattJ j/k of course :)
  470. moparisthebest bold for me haha
  471. moparisthebest man if we can solve "derive meaning from text messages" we'll really have it made
  472. Kev has left
  473. adiaholic has left
  474. adiaholic has joined
  475. Kev has joined
  476. Kev has left
  477. Kev has joined
  478. moparisthebest I guess we do have a standard already to transfer thoughts/intent/meaning over XMPP https://xmpp.org/extensions/xep-0183.html
  479. kusoneko has left
  480. kusoneko has joined
  481. kusoneko has left
  482. winfried has left
  483. winfried has joined
  484. kusoneko has joined
  485. debacle has left
  486. eevvoor has left
  487. thdouk has left
  488. kusoneko has left
  489. kusoneko has joined
  490. kusoneko has left
  491. kusoneko has joined
  492. alameyo has left
  493. alameyo has joined
  494. Kev has left
  495. Kev has joined
  496. adiaholic has left
  497. adiaholic has joined
  498. Syndace Oh, I forgot trading the taxi receipt for money today, shall we do that at fosdem tomorrow?
  499. Syndace Oh, I forgot to trade the taxi receipt for money today, shall we do that at fosdem tomorrow?
  500. Daniel In the past I think I just emailed them to Guus or something
  501. pep. ah right I'll do that as well
  502. Syndace ok thanks, will do that
  503. Martin has left
  504. Martin has joined
  505. Kev has left
  506. eevvoor has joined
  507. jabberjocke has left
  508. jabberjocke has joined
  509. jabberjocke has left
  510. adiaholic has left
  511. Guus has left
  512. Guus has joined
  513. alameyo has left
  514. alameyo has joined
  515. winfried has left
  516. winfried has joined
  517. debacle has joined
  518. thdouk has joined
  519. winfried has left
  520. eevvoor has left
  521. Kev has joined
  522. winfried has joined
  523. winfried has left
  524. winfried has joined
  525. thdouk has left
  526. Guus has left
  527. Guus has joined
  528. winfried has left
  529. winfried has joined
  530. winfried has left
  531. nyco has left
  532. winfried has joined
  533. nyco has joined
  534. winfried has left
  535. winfried has joined
  536. Kev has left
  537. eevvoor has joined
  538. SubPub has left
  539. winfried has left
  540. winfried has joined
  541. thdouk has joined
  542. thdouk has left
  543. winfried has left
  544. eevvoor has left
  545. eevvoor has joined
  546. nyco has left
  547. Guus has left
  548. Guus has joined
  549. nyco has joined
  550. winfried has joined
  551. Martin has left
  552. eevvoor has left
  553. eevvoor has joined
  554. winfried has left
  555. winfried has joined
  556. winfried has left
  557. winfried has joined
  558. winfried has left
  559. winfried has joined
  560. winfried has left
  561. winfried has joined
  562. nyco has left
  563. winfried has left
  564. winfried has joined
  565. Martin has joined
  566. winfried has left
  567. winfried has joined
  568. Guus has left
  569. Guus has joined
  570. eevvoor has left
  571. Kev has joined
  572. Kev has left
  573. adiaholic has joined
  574. nyco has joined
  575. winfried has left
  576. winfried has joined
  577. winfried has left
  578. winfried has joined
  579. winfried has left
  580. winfried has joined
  581. winfried has left
  582. winfried has joined
  583. debacle has left
  584. winfried has left
  585. debacle has joined
  586. thdouk has joined
  587. winfried has joined
  588. debacle has left
  589. debacle has joined
  590. nyco has left
  591. nyco has joined
  592. nyco has left
  593. thdouk has left
  594. nyco has joined
  595. lsdlfjljuie I'm somewhat unhappy to see that people just post fotos of other summit participants on social media. I would have expected to be in an environment where people would at least ask beforehand...
  596. adiaholic has left
  597. adiaholic has joined
  598. kusoneko has left
  599. kusoneko has joined
  600. kusoneko has left
  601. kusoneko has joined
  602. kingu has left
  603. dwd I can see arguments both ways on that. I would expect the summit itself to be public, and in the record.
  604. winfried has left
  605. winfried has joined
  606. moparisthebest the video stream was public
  607. zash Don't you need permission to publish pictures from people in the picture?
  608. moparisthebest do we need an opinion from a lawyer in every jurisdiction again?
  609. zash Yes
  610. zash At least in the EU it should be somewhat unified.
  611. zash Also see the "Note Well" thing the IETF does.
  612. Martin > Don't you need permission to publish pictures from people in the picture? In germany you don't have the right on your picture anymore when you attend public events like concerts, summits and so on. I guess it's more or less the same in other European countries.
  613. moparisthebest I don't think anyone would object if you attended the summit wearing a facemask, if you want your privacy
  614. thdouk has joined
  615. Martin has left
  616. Martin has joined
  617. thdouk has left
  618. adiaholic has left
  619. adiaholic has joined
  620. lsdlfjljuie has left
  621. Martin has left
  622. Martin has joined
  623. alameyo has left
  624. alameyo has joined
  625. kingu has joined
  626. thdouk has joined
  627. thdouk has left
  628. jabberjocke has joined
  629. Martin has left
  630. Martin has joined
  631. Kev has joined
  632. zash has left
  633. Zash has left
  634. zash has joined
  635. Kev has left
  636. Zash has joined
  637. dwd has left
  638. dwd has joined
  639. goffi has left