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