XSF logo XSF Discussion - 2017-11-08


  1. SamWhited Wow, that looks cool
  2. vanitasvitae Right now there is a "math party" at my university
  3. vanitasvitae https://jabberhead.tk:5443/f0a454a3b03d017a262dfcfef56c2235742e325d/zCMPkHkA5MltD4QQtF25Lqlw4PglxRCG2zKXN5pn/ka4RoLEzQjWNyTtzwEF-VA.jpg
  4. SamWhited daniel: minor annoyance report: despite having looked at the rules in the past I am never sure why some links (like vanitasvitae 's) show up as downloadable but others (Arc's) are not.
  5. vanitasvitae SamWhited: maybe because mine is a httpupload link?
  6. vanitasvitae Ah, maybe thats not the reason...
  7. SamWhited yah, as far as my client is concerned its just a message with text in it that looks like a link (unless the MUC is also reflecting OOB metadata or something)
  8. SamWhited Not a big deal, it just "feels" inconsistent
  9. daniel SamWhited: if you use the attach button in Conversations it will add an oob tag. And Conversations will only show the button for messages which also have an oob tag
  10. daniel The muc does reflect that
  11. SamWhited That makes sense
  12. Steve Kille has left
  13. sezuan has left
  14. jjrh has left
  15. jjrh has left
  16. Tobias has joined
  17. vanitasvitae has left
  18. jjrh has left
  19. daniel has left
  20. Tobias has joined
  21. jjrh has left
  22. zinid has left
  23. jjrh has left
  24. jjrh has left
  25. Tobias has joined
  26. Arc well one's http vs https
  27. Arc is the mime being sent on each?
  28. Valerian has left
  29. Tobias has joined
  30. daniel has left
  31. jjrh has left
  32. Valerian has joined
  33. jjrh has left
  34. daniel has left
  35. Valerian has left
  36. Valerian has joined
  37. la|r|ma has left
  38. Valerian has left
  39. Valerian has joined
  40. jjrh has left
  41. jjrh has left
  42. efrit has joined
  43. jjrh has left
  44. jjrh has left
  45. Tobias has joined
  46. daniel has left
  47. daniel has joined
  48. daniel has left
  49. la|r|ma has joined
  50. daniel has joined
  51. lskdjf has joined
  52. @Alacer has left
  53. @Alacer has joined
  54. efrit has joined
  55. nyco has joined
  56. edhelas has joined
  57. daniel has left
  58. daniel has joined
  59. jere has left
  60. sonny has left
  61. sonny has joined
  62. daniel has left
  63. daniel has joined
  64. daniel has left
  65. jere has joined
  66. daniel has joined
  67. Zash moparisthebest: FWIW I've had thoughts along the same lines as you wrt encrypting things separately so that only the entity that needs one piece of data can see it. But I don't think that's XMPP.
  68. Valerian has left
  69. Valerian has joined
  70. Valerian has left
  71. Valerian has joined
  72. Valerian has left
  73. Bunneh has left
  74. Bunneh has joined
  75. Valerian has joined
  76. Bunneh has left
  77. Bunneh has joined
  78. Valerian has left
  79. Bunneh has left
  80. Bunneh has joined
  81. Bunneh has left
  82. Bunneh has joined
  83. daniel has left
  84. daniel has joined
  85. SamWhited has left
  86. uc has left
  87. uc has joined
  88. Bunneh has left
  89. Bunneh has joined
  90. Bunneh has left
  91. Bunneh has joined
  92. Bunneh has left
  93. Bunneh has joined
  94. Bunneh has left
  95. Bunneh has joined
  96. Bunneh has left
  97. Bunneh has joined
  98. Guus has left
  99. Guus has joined
  100. Bunneh has left
  101. daniel has left
  102. daniel has joined
  103. Bunneh has left
  104. Bunneh has left
  105. Bunneh has left
  106. Bunneh has left
  107. Bunneh has left
  108. Bunneh has joined
  109. daniel has left
  110. daniel has joined
  111. lumi has joined
  112. Guus has left
  113. Guus has joined
  114. daniel has left
  115. daniel has joined
  116. Ge0rG has left
  117. daniel has left
  118. daniel has joined
  119. goffi has joined
  120. @Alacer has left
  121. @Alacer has joined
  122. Ge0rG has left
  123. daniel has left
  124. daniel has joined
  125. daniel has left
  126. daniel has joined
  127. arc has left
  128. arc has joined
  129. Ge0rG has joined
  130. edhelas has joined
  131. nyco has joined
  132. Ge0rG has left
  133. Arc has left
  134. nyco has joined
  135. edhelas has joined
  136. Ge0rG has left
  137. Guus has left
  138. Guus has joined
  139. Guus has left
  140. Guus has joined
  141. edhelas has joined
  142. daniel has left
  143. daniel has joined
  144. ralphm has left
  145. nyco has joined
  146. SamWhited has left
  147. daniel has left
  148. daniel has joined
  149. Ge0rG How does the OOB tag interop with OMEMO? It's obviously leaking data, but what exactly? Is the password only contained in the body?
  150. Zash I am under the impression that it's just a special URL in the (encrypted) body, with the encryption key in the #this part.
  151. zinid leaking data my ass...
  152. zinid yet another round of bikeshedding
  153. Bunneh has left
  154. Bunneh has joined
  155. Ge0rG Zash: yes, that's how it works. But what is contained in the oob tag?
  156. daniel has left
  157. daniel has joined
  158. Ge0rG I would look up myself, but I don't have any OMEMOs
  159. Zash I don't believe there is one
  160. nyco has left
  161. nyco has joined
  162. goffi has left
  163. Ge0rG Zash: I was under the impression that Conversations needs the oob tag to display inline images
  164. Ge0rG has left
  165. daniel has left
  166. daniel has joined
  167. goffi has joined
  168. arc has left
  169. nyco has left
  170. arc has joined
  171. daniel has left
  172. nyco has joined
  173. jonasw Ge0rG: oob is safe enough for daniel, sims would not be: https://github.com/siacs/Conversations/issues/2637
  174. Ge0rG I'd probably consider the picture URL and file size to be private as well, but what do I know
  175. Zash Where's that blag that said that e2e crypto is basically just marketing fluff?
  176. intosi has joined
  177. Ge0rG Hm. of all people, I should know that.
  178. daniel has joined
  179. @Alacer has left
  180. @Alacer has joined
  181. jcbrand has joined
  182. daniel has left
  183. Steve Kille has left
  184. daniel has joined
  185. Steve Kille has left
  186. Steve Kille has left
  187. Tobias has joined
  188. daniel has left
  189. daniel has joined
  190. Tobias has joined
  191. xnyhps has joined
  192. daniel has left
  193. daniel has joined
  194. Steve Kille has joined
  195. jonasw SamWhited, so you’re arguing my proposal is bad because it’ll lead to incompatibilities among clients, but you argue that incompatibilities among clients when you change bits in yours aren’t an issue? (around 22:19Z)
  196. jonasw daniel, no, you will only get real-world feedback on the input format. nobody cares about the wire format except the devs who are then forced to implement things because of your market share (sorry to be blunt here.) (re around 22:48Z)
  197. jcbrand has left
  198. jonasw but hey, we already agree on the input format, I think that’s really nice, and it’s nice to have that standardised.
  199. Ge0rG I only wish for a way to skip formatting when typing formulas
  200. jonasw or any other content for that matter.
  201. jonasw or any other content which shouldn’t be formatted for that matter.
  202. jonasw but nobody listens to me
  203. Zash It seems weird to me to be XEPing what amounts to UI things
  204. Ge0rG Zash: because you are a server dev
  205. Ge0rG Zash: I care very much about UI things, and I want them consistent across implementations
  206. Flow I'm sure everybody already noticed that XHTML-IM/styling/markdown/bmh discussion related thing on HN: https://news.ycombinator.com/item?id=15646425
  207. Ge0rG This is the major weakness of XMPP. Every client works differently
  208. Zash But sometimes it is a strength.
  209. jonasw depends
  210. jonasw I think for each major workflow we’d need a set of clients covering each platform.
  211. Zash Altho according to some random Reddit thread I saw, none of the competition things work as they should in FOSS
  212. jonasw currently, conversations covers the "non-technical" workflow pretty well on mobile.
  213. Ge0rG Zash: yes, if you believe that you need the opportunity to differentiate on quality of implementation.
  214. Zash Well, optimally the differentiation would be on proirites, so you could find a thing that sucks in ways you don't care about.
  215. Flow jonasw, a while ago Dave suggested to have a generic extension to reference certain parts of bodytext ( https://mail.jabber.org/pipermail/standards/2016-February/030924.html ). That doesn't sound like a bad idea to me, as it could also be used in your Message Markup XEP. What do you think?
  216. jonasw Flow, I looked at References
  217. jonasw it would be a major (size) overhead to have a <reference xmlns="…"> element for each bit of markup though
  218. Flow jonasw, not reference
  219. Flow <bodytext/>
  220. Flow (see linked mail)
  221. Steve Kille has left
  222. Flow Uh wait, maybe I misunderstood Dave's mail, he was probably just talking about factoring the data into an extra element
  223. Flow not using that as generic element which can be re-used by other xeps
  224. jonasw I think so, too
  225. jonasw but now I get what you meant
  226. jonasw it also isn’t in the final XEP
  227. jonasw (<https://xmpp.org/extensions/xep-0372.html>)
  228. Flow true, but the idea is appealing. such an generic element could also specify how it's used with non-<body/> body text
  229. Flow like the text found in OMEMO messages
  230. Kev has joined
  231. jonasw I see your general point. we could reword so that it doesn’t refer to <body/> but to "text of the message". in which case OMEMO would provide the "actual" text of the message as opposed to the <body/>.
  232. la|r|ma has joined
  233. jcbrand has joined
  234. jonasw but there are different issues with combining this with OMEMO which need to be discussed in the security considerations (OMEMO won’t encrypt the markup...)
  235. Flow jonasw, i fear it's a bit more complicated than that
  236. jonasw (nor will it authenticate the markup, which is bad too)
  237. jonasw Flow, is it?
  238. ralphm has left
  239. Flow 1. there could be multiple unencrypted <body/> elements. 2. with OX there could be multiple encrypted <body/> elements. 3. with omemo it is just one body (and the markup information is not encrypted/authenticted)
  240. jonasw multiple unencrypted body elements must have xml:lang tags to distinguish them, as do <markup/> elements.
  241. jonasw I presume that this is the same for OX?
  242. Flow yep
  243. Zash What does happen if you have multiple bodies with e2e?
  244. Flow but I possibly place the xml:lang selector not in <markup/> but in the generic <bodytext/>
  245. Flow Zash, what happens if you have multiple bodies without e2e?
  246. jonasw Flow, that makes things more complex to parse and generate I think
  247. Zash I haven't a clue
  248. jonasw Flow, I think e2ee simply doesn’t allow that
  249. jonasw it’s also not a very common use-case in IM
  250. Flow OX does not forbit multiple <body/> elements
  251. Flow *forbid
  252. jonasw *currently deployed e2ee simply doesn’t allow that ;-)
  253. daniel Is there an OX implementation in smack Flow?
  254. Flow daniel, there is a branch a started a while ago
  255. Flow but nothing even prototypical
  256. Flow yet
  257. pep. jonasw: maybe you should cover the case in markups. How does it work when there are multiple bodies ATM? (Different xml:lang)
  258. Flow first ISR, then OX. that is the current order of my priorities ;)
  259. jonasw pep., it’s in the Business rules and the Internationalisation considerations.
  260. Zash has left
  261. Zash has left
  262. Zash has left
  263. Zash has left
  264. Zash has left
  265. Zash has left
  266. Zash has left
  267. pep. jonasw: also, unrelated, I'm not really fan of leaving the list/quotation characters etc., in the rendered version
  268. jonasw pep., I agree
  269. jonasw it’s tricky to avoid though
  270. jonasw I’m writing a response to standards@ about this
  271. pep. K
  272. jonasw (Goffi brought it up there)
  273. pep. Will read
  274. pep. And I need to reply as well
  275. jonasw pep., there you go
  276. daniel jonasw: aren't the > and * you use in your example kinda like markup information in the body?
  277. daniel Which the xep says you are trying to avoid?
  278. daniel has left
  279. pep. That's why I don't like them
  280. dwd daniel, It's only bad if someone else does it.
  281. jonasw daniel, it’s not required for them to be there at all.
  282. jonasw they don’t carry any meaning.
  283. lskdjf has joined
  284. jonasw however, if combined with Message Styling, I can totally see letting them in there for compatibility.
  285. pep. What's the point if you already have the meaning of your markup translated
  286. dwd pep., Fallback.
  287. jonasw you can’t stop people from typing them (I do too!), and I’m totally in favour of specifying the input format Message Styling defines
  288. Ge0rG And then we end up with a message containing a <body> with this-is-really-not-markdown-although-it-walks-like-markdown-and-quacks-like-markdown, a <body-markup-hint/>, a <markup> tree and an XHTML-IM payload.
  289. jonasw but in contrast to the Message Styling wire format, we could adapt to changing behaviours and trends in the meta-characters used by humans
  290. jonasw which is nice
  291. jonasw (I mean, adapt without breaking old archives and interop for the transition period)
  292. pep. jonasw: leaving it there defeats the point of not putting markup on the body
  293. jonasw pep., tend to agree.
  294. jonasw but some kind of fallback is needed.
  295. pep. Why?
  296. jonasw especially for quotations
  297. jonasw (not so much for lists)
  298. Kev My thoughts on this, /still/ not having had time to look at the spec. Is that we're not trying to define a new format here that adds a new feature, we're trying to render correctly what the user's intent was when they typed something. I think that changes things *significantly*.
  299. jonasw if a client doesn’t understand <markup/>, it would render the quotations as normal paragraphs.
  300. pep. Do we have a failback for every single xep out there? In case the first one isn't supported
  301. jonasw pep., I think most XEPs either specify a fallback or fail gracefully.
  302. Kev And so just documenting roughly what people are already typing in messages is both pragmatic and sensible.
  303. Kev (And people *are* already typing ascii markup in messages, and the world is definitely not falling apart, even though not all clients support rendering it)
  304. jonasw Kev, my main problem with Message Styling isn’t that it does that, but that it doesn’t have an opt-in.
  305. Syndace has left
  306. Ge0rG Kev: actually, all clients support rendering it... as ASCII
  307. pep. Ge0rG: agreed
  308. Kev Ge0rG: Potato potato :)
  309. daniel has left
  310. jonasw if we’re going to change the rendering with possibly removing charatcers (e.g. for quotations!), then it must be opt-in.
  311. Kev We should not be removing characters.
  312. jonasw and I think that it should still be opt-in even if those characters are preserved.
  313. daniel jonasw, isn't opt-in something your client should support?
  314. jonasw daniel, no, because the client can’t know if the sender intended it.
  315. Kev We should be rendering the existing characters with additional styling, or should have a local toggle.
  316. Ge0rG Kev: but it's up to the sender to decide whether they want markup for a given ASCII sequence.
  317. Kev (Which is what Swift does with emoticons - it renders by default, removing the source, but you can flip it off to go back to the as-sent. Useful if someone's pasting code sometimes)
  318. daniel i'm not really sure what you mean by opt-in then
  319. jonasw daniel, an additional element to <message/> which indicates that the body can be interpreted according to the Message Styling rules.
  320. Ge0rG I think that when copy&pasting things from the IM client, the original body should be copied with all "markup" characters present as-is
  321. Ge0rG jonasw: that would be body-markup-hints?
  322. daniel jonasw, i can get on board with that
  323. jonasw Ge0rG, exactly.
  324. jonasw daniel, I said so on the list, nobody cared :(
  325. Ge0rG the sending client could pre-render markup in the input field and offer a button to strip markup
  326. Ge0rG so you can paste code.
  327. Ge0rG but then interop.
  328. mimi89999 has joined
  329. Ge0rG You can't fix Gajim overnight
  330. jonasw Ge0rG, lovetox can :)
  331. Ge0rG So we need two hints. One for "this is markup" and another for "this is definitively not markup"
  332. daniel i'm not really sure I want Flows xep for that though. because then styling would depend on Flows xep getting accepted
  333. jonasw daniel, I think flows xep was rejected anyways?
  334. Zash has left
  335. Kev Ge0rG: Isn't this similar to the "I meant what I sent" that I was talking about with not doing emoticon rendering?
  336. dwd daniel, It needs something like Flow's BMH. Not *exactly* it.
  337. jonasw dwd, I think in fact it pretty much needs that.
  338. Kev (Although not quite the same)
  339. Ge0rG Kev: I thought you were talking about the receiving side
  340. Ge0rG I'm still annoyed by some IM clients replacing (b) and (y) with random emoji.
  341. jonasw daniel, in fact, my arguments for opt-in were dismissed with something along the lines of "edge cases nobody should care about".
  342. jonasw Ge0rG, kill trillian with fire
  343. Ge0rG jonasw: also, Gajim.
  344. daniel jonasw, i'm trying to find your email in that huge bike shadding thread to give a thumbs up
  345. jonasw Date: Yesterday 19:29
  346. jonasw (CET)
  347. jonasw if that helps
  348. Zash destroyallsoftware?
  349. daniel it does
  350. Ge0rG Kev: "I meant what I sent" could be a BMH of "text/plain"
  351. dwd Ge0rG, I don't think we need the complexity of media typing here, actually.
  352. Ge0rG dwd: right, let's just invent a new name for it.
  353. dwd Ge0rG, Would you want text/html there?
  354. jonasw I get shivers.
  355. jonasw also, note that BMH is not Content types
  356. dwd Ge0rG, If anything, we want a media type of: `text/plain; format=XYZ`, with ZYX given by a BMH-a-like.
  357. Ge0rG Okay, BMH only relates to body, so "text/" is implicitly pre-set.
  358. jonasw https://xmpp.org/extensions/inbox/bmh.html#languages
  359. jonasw there’s no media type here.
  360. Ge0rG I don't like the use of the term "Language" in there.
  361. Ge0rG </bikeshed>
  362. dwd Ge0rG, Yes, excellent point, this is veyr much a bikeshed.
  363. daniel has left
  364. jonasw BMH essentially foresaw Styling.
  365. jonasw > TODO: Shall we define your own subset of e.g. CommonMark, XMPPMark? :)
  366. jonasw (or shall I say, inspired?)
  367. dwd I think the writing was on the wall.
  368. Ge0rG dwd: as opposed to the exact BMH identifier string to be used for "this is not markup"?
  369. dwd Only we couldn't parse it properly because it turned out nobody knew what *this* meant.
  370. Ge0rG I still want code syntax highlighting.
  371. dwd Ge0rG, I'm not worried about clients heuristically doing that in ```these sections```.
  372. daniel has left
  373. Zash What about `if(what){then()}`{.c}
  374. Ge0rG like heuristically rendering /italics/ and *bold*?
  375. Ge0rG Zash: I think it's sensible to keep syntax coloring to ``` blocks, not to `spans`
  376. daniel has left
  377. Ge0rG So what about the following proposal: - messages with a BMH(*) of "Styling" get styled and the markup characters removed on display (but not on copy&paste) - messages without a BMH get rendered as markup with the markup charachters in place - messages with a BMH of "plain" get rendered verbatim with no styling applied (*) BMH or an improved version that provides the same semantical meaning
  378. dwd Ge0rG, I think that's sensible. I'm not entirely sure about the middle case, but I don't care enough to object.
  379. daniel gajims current rendering is pretty annoying btw
  380. jonasw daniel, didit boldface everything between (*) and (*)?
  381. daniel yes
  382. jonasw kill it with fire
  383. dwd jonasw, Yup. Not a huge fan of that, nor leaving the *asterisks* in place.
  384. dwd jonasw, But as a heuristic solution it's OK, and 99% of the time gets things right.
  385. jonasw Ge0rG, you can’t really remove the markup characters on display in any case, because then clients would have to be sure that the sender intended it to be that way.
  386. Ge0rG x * y - z * 3
  387. zinid easy to writer a parser they said
  388. jonasw Ge0rG, and I don’t think that’s an assumption an client operated by a human can reasonably have
  389. dwd jonasw, Ge0rG literally just outlined a way to communicate exactly that.
  390. Ge0rG jonasw: the sender needs to pre-render the markup in the input line of course.
  391. daniel zinid, the styling xep has a very straight forward parser
  392. jonasw dwd, sender as in the human operating the client, not as in the program
  393. daniel it's just about defining the rules properly
  394. jonasw Ge0rG, that’s a very complex thing not many clients will do.
  395. Guus has left
  396. Ge0rG jonasw: an easier thing would be to have a button on the sent message to "remove markup", which would send an LMC with a BMH.
  397. zinid daniel: can I use LALR(1) parser? if not, it's not simple
  398. jonasw Ge0rG, sounds like a plan!
  399. jonasw didn’t think of LMC in this context, kudos
  400. jonasw zinid, I think LALR(1) should do
  401. zinid jonasw: can I have grammar.y then? or should I write it manually because it's funny?
  402. jonasw zinid, I suggest that the XEP authors provide a formal definition of the grammer once it is accepted :)
  403. zinid jonasw: ok
  404. Ge0rG BNF FTW!
  405. zinid ABNF would be awesome, I could use ragel
  406. jonasw ABNF seems very reasonable considering that it’s the IETFs go-to representation for grammars.
  407. daniel Ge0rG, if we want to annotate i'd prefer the simpler 'opt-in' proposal jonasw had
  408. Zash Not EBNF?
  409. jonasw Zash, I always forget the exact acronym
  410. @Alacer has left
  411. daniel you could still to 'send lmc to remove style'
  412. Ge0rG daniel: the simpler opt-in mechanism requires all clients to update
  413. Ge0rG daniel: ah, LMC-based markup removal. Yeah.
  414. Zash jonasw: Looks like both ABNF and EBNF exist
  415. jonasw daniel, re-visiting BMH in the light of Styling I think BMH would be a great way to convey this and allow for richer use-cases at the same time.
  416. arc has left
  417. arc has joined
  418. daniel Ge0rG, most clients need to update anyway. because gajim doesn't support styling for example
  419. jonasw BMH still can’t cover everything XHTML-IM could, but it provides nice plain-text fallbacks. a client with strong a11y considerations would want to interpret most of those markups anyways.
  420. jonasw Ge0rG, re code blocks, by the way, a common convention is "```language\n<code here>\n```"
  421. jonasw that’s how gitlab markup does it
  422. Ge0rG jonasw: yeah, I could live with that.
  423. Zash That's how pandoc does it.
  424. @Alacer has joined
  425. mimi89999 has left
  426. Guus has left
  427. Ge0rG re "text/plain", Tobias wrote re BMH: "I wonder whether it makes sense to reuse IANA Media Types instead of starting a new registry."
  428. valo has left
  429. jonasw Ge0rG, at which point it would’ve been Content Types (<https://xmpp.org/extensions/inbox/content-types.html>) which was rejected over a year ago
  430. Ge0rG History is repeating.
  431. Ge0rG Can't we just change the message type? (I mean the 'type' attribute of the <message> stanza)
  432. jonasw Ge0rG, go away.
  433. jonasw ;-)
  434. Tobias Ge0rG, i think the RFC doesn't allow additional parameters on that
  435. Tobias or additional attributes on body
  436. jonasw namespaced attributes! (Sam is gonna shoot me)
  437. Ge0rG Tobias: we can override the RFC with an XEP. I'm sure nobody will notice.
  438. Zash jonasw: y u do this
  439. jonasw Zash, what?
  440. Zash jonasw: mention namespaced attributes :)
  441. jonasw I think they’re great.
  442. Ge0rG do they need namespace versioning as well?
  443. jonasw sure
  444. jonasw I think by now that much of this war is rooted in the confusion between "plain-text fallback" and "markup language" and that again is rooted in the fact that many modern markup languages look like plaintext fallbacks.
  445. jonasw or rather have useful plaintext fallbacks right from the beginning
  446. jere has joined
  447. nyco has left
  448. la|r|ma has left
  449. nyco has joined
  450. Kev has left
  451. Kev has joined
  452. zinid has left
  453. lskdjf has joined
  454. daniel has left
  455. Kev Well, also whether you want what people already type to be correctly handled everywhere.
  456. jubalh has joined
  457. jonasw Kev, no, that’s input conventions and should not matter for wire formats.
  458. Kev Assuming universal adoption.
  459. Kev But this 'just render what's sent with styling enhancement' has been in use for a very long time without issue.
  460. jonasw if we still had the IRC conventions with some control-characters for formatting around, you’d not argue that "what people already type" should be in wire formats.
  461. jonasw (mostly because XML can’t carry those, but also because it’s not a useful plaintext fallback)
  462. Zash I like arguments like "everyone is already doing it" and "has worked forever without issue"
  463. jonasw Kev, I doubt you can say "without issue" just 50 lines after somebody complained about how broken gajim handles that.
  464. Zash Especially when people are pointing out the times it's messy and doesn't work
  465. mathieui jonasw, which is why I’ll wirte a protoxep in order to send the poezio internal format over the wire, escaped
  466. mathieui jonasw, which is why I’ll write a protoxep in order to send the poezio internal format over the wire, escaped
  467. Kev jonasw: Gajim may do something stupid, but Psi doesn't.
  468. nyco has left
  469. Kev I'm not saying that doing other things than what I'm suggesting works without issue :)
  470. jonasw Kev, but it kind-of moots the "everyone is doing it and it works great" point
  471. mathieui "psi is doing it, and for some cases it works great" already doesn’t sound that good
  472. Kev It would certainly bring into question that point that I'm not making, yes.
  473. @Alacer has left
  474. Kev A lot of people are sending this stuff on the wire, irrespective of rendering. Some clients (at least Psi) also add styling successfully to it.
  475. nyco has joined
  476. jere has joined
  477. jonasw Kev, "without issue" is certainly wrong, but I’m not going to nitpick here (and I probably misread some statement)
  478. Kev What's the issue with what Psi's doing?
  479. jonasw I don’t know psi, but what gajim does is certanily an issue.
  480. jonasw so it’s not without issue at all.
  481. Kev It basically just turns *thing* into <b>*thing*</b>
  482. mathieui jonasw, Kev’s point is that it has been in use for a long time without issue, in psi
  483. mathieui which is not contradicted by "gajim handles things wrong"
  484. Kev I don't buy the argument that "What Kev suggests doesn't work, because someone does something different to what Kev suggests, and that doesn't work".
  485. Steve Kille has left
  486. jonasw Kev, maybe I missed what you indeed suggest :)
  487. daniel has left
  488. daniel has joined
  489. mathieui (I haven’t used psi in a very long time so I can’t argue with that)
  490. Kev Just adding styling to ** // __.
  491. jonasw Kev, well gajim does exactly that
  492. Kev (Without removing the characters)
  493. Kev If Gajim does exactly that, what's the issue?
  494. jonasw it also does that across newlines
  495. mathieui jonasw, gajim has somewhat looser boundaries
  496. mathieui I think psi only does it for words
  497. jonasw mathieui, Kev didn’t say anything about boundaries :-)
  498. mathieui e.g. the formating chars are stuck to the words
  499. @Alacer has joined
  500. goffi Kev: even by keeping the formatting characteres, I would not like to have ls `date +%Y-%m-%d`-*.xml rendered half in monospace, partly in bold. How does Psi handle that?
  501. Steve Kille has joined
  502. Kev I forget, I wrote this a decade and a half ago or so.
  503. mathieui jonasw, I mean, if Kev says it works fine, it has to be slightly more precise than what gajim does, even if I believe we can always find cases where it doesn’t do what's intended
  504. Kev I'm sure it's possible to have it do not-what-you-intend, but I don't believe ever in a way that damages the ability to understand it.
  505. Kev But none of that example should be bold, because there's only one *, and in that particular case half of it being monospace is exactly what one would usually expect.
  506. Kev But ISTR I made Psi not do word partials.
  507. jonasw FTR, I think the rules laid out by Styling are a good start, once we get rid of the escaping (which I think Sam said he would do)
  508. valo has joined
  509. Kev There *is* a definite advantage to having this out of band, BTW, which is that you can not annotate things that are pastes.
  510. Kev But I think you can achieve the same thing just by having <paste/> as a child.
  511. Kev AFK a while.
  512. Kev has left
  513. Kev has joined
  514. Kev has left
  515. jere has left
  516. jere has joined
  517. intosi has left
  518. Guus has left
  519. Alex has joined
  520. Ge0rG has left
  521. Alex has left
  522. Alex has joined
  523. Kev has joined
  524. Guus has left
  525. Guus has left
  526. ralphm has left
  527. Syndace has left
  528. ralphm has left
  529. Flow has left
  530. Flow has joined
  531. lumi has joined
  532. daniel has left
  533. jubalh has left
  534. daniel has left
  535. Alex has left
  536. la|r|ma has left
  537. intosi has joined
  538. la|r|ma has joined
  539. jonasw has left
  540. daniel has left
  541. jere has joined
  542. jere has joined
  543. la|r|ma has joined
  544. la|r|ma has joined
  545. daniel has left
  546. jonasw has left
  547. @Alacer has left
  548. @Alacer has joined
  549. Valerian has joined
  550. jubalh has left
  551. Alex has joined
  552. daniel has left
  553. bra has left
  554. moparisthebest I can see it now, 20 years from now: "daddy what caused the great XMPP fork of 2017 when half the community split off into Zimpy?" "well honey, they couldn't agree on the optimal way to bold a word in a text message"
  555. Zash /thread
  556. jonasw itym </thread>?
  557. zinid *thread*
  558. Ge0rG *italics*
  559. mathieui i*italics*
  560. intosi ["The last word should be ", {"style": "bold", "contents": "bold"}]
  561. Zash Let me tell you about `pandoc -t json`
  562. intosi Can I still say no?
  563. intosi Or rather, [{"unMeta":{}},[{"t":"Para","c":[{"t":"Str","c":"No!"}]}]]
  564. dwd I'm concerned that "No" is not semantically transmitted, and therefore may be interpreted differently in multiple clients.
  565. Guus dwd: I see that you're married.
  566. dwd We should have a markup that encapsulates the entirety of human speech, so that all clients directly interpret the semantics intended, and therefore can respond suitably without relying on humans having to guess what the sender might mean.
  567. Zash <statement><negative exclamation='true'>no</negative></statement>
  568. Ge0rG dwd: machine to machine communications?
  569. Tobias has left
  570. dwd Guus, <amusement/><agreement/>
  571. dwd Ge0rG, And from there, but a short step to eliding the communication entirely, making XMPP so much more bandwidth efficient.
  572. intosi I would propose BER, but I'm too lazy to do so.
  573. Zash B2B communication
  574. dwd intosi, PER, surely, or does David no longer get excited by that one?
  575. Zash intosi: have you considered beer instead
  576. Ge0rG dwd: that's absolutely the wrong direction. We can finally increase XMPP's popularity by populating the network with m2m semantics-capable clients
  577. intosi Zash: +1
  578. intosi dwd: I am not presently in the same room as David, he cannot complain.
  579. dwd <ironic-statement/>
  580. Ge0rG <sarcastic-retort/>
  581. dwd <assertion-of-fascism/>
  582. jonasw <godwins-law/>
  583. Zash <statement:nonsensical rel='plankton'/>
  584. moparisthebest I'm super sorry to turn the topic of conversation here, but, Zash about layers of encryption so each server only knew bare minimum
  585. moparisthebest seems like it could still be XMPP but we'd just have to wrap things in new nonzas ?
  586. jonasw moparisthebest, broadcast
  587. zinid "We can finally increase XMPP's popularity" - this will never happen
  588. moparisthebest <deliver to="otherserver.com"> (this part is encrypted blob #1)<deliver to="jid@otherserver.com">(this part is encrypted blob #2)<message from="bob@bob.com" to="jid@otherserver.com">etc</message>(/end encrypted blob #2)</deliver>(/end encrypted blob #1)</deliver>
  589. jonasw moparisthebest, what about presence broadcast, MUC?
  590. moparisthebest jonasw, not sure, maybe it only works for messaging
  591. jonasw MUC and MIX broadcasts?
  592. Ge0rG jonasw: encrypted to the MUC service
  593. Ge0rG jonasw: or multi-key-encrypted to all participants
  594. moparisthebest it might only be feasible for bare-minimum metadata for direct chats
  595. moparisthebest yea that'd work I guess, let the MUC service broadcast, idk
  596. moparisthebest just trying to throw crazy ideas out there that solve the metadata problem as much as possible
  597. jonasw I don’t think that there is a real metadata problem.
  598. moparisthebest we are OK with specs that require changes on all clients and servers to be useable already, see MIX
  599. jonasw or maybe there is, but I don’t think it’s reasonable to solve that within XMPP.
  600. moparisthebest might as well solve the metadata problem the same way
  601. Ge0rG moparisthebest: the best solution to the metadata problem is to run your own server for you and all of your important contacts
  602. SamWhited jonasw: no, I'm arguing that it's not a problem because we won't change it later. The formatting is good enough and doesn't need to be extensible after we settle on a few basic things (but I don't remember what I said about your thing with relation to compatibility)
  603. moparisthebest doesn't *solve* it, you still have 1 central service that knows everything
  604. zinid moparisthebest: solve what?
  605. Ge0rG moparisthebest: federated systems will always have metadata leakage. What you want instead is a P2P DHT chat system.
  606. jonasw SamWhited, okay
  607. moparisthebest metadata problem
  608. Ge0rG moparisthebest: or maybe you want to connect to XMPP via TOR.
  609. moparisthebest if I wanted that I'd just use tox, and have to change my phone battery every 20 minutes
  610. moparisthebest I'm just talking about leaking bare minimum metadata to XMPP servers, the bare minimum for federated chat
  611. Ge0rG moparisthebest: so what you want instead is a tox agent running on a trusted server that you connect to.
  612. moparisthebest then you are back to 1 central server with all info
  613. Ge0rG moparisthebest: yes.
  614. moparisthebest so you've got A (client) -> B (server) -> C (server) -> D (client)
  615. Ge0rG moparisthebest: with XMPP, you could hide the usernames of the people you talk to from your server. But not presence.
  616. moparisthebest an ideal scenario has each only knowing about the next hop
  617. Ge0rG moparisthebest: and then still, the receiving server would know your full JID.
  618. moparisthebest no they'd only know the server it came from, and who it's going to, not sending JID though
  619. jonasw moparisthebest, that doesn’t buy you a lot, you’d need to go full Tor essentially
  620. moparisthebest I think it does buy you a lot
  621. moparisthebest no server knows who sent it or who it's intended for
  622. moparisthebest and that's the win you are looking for
  623. moparisthebest worded that wrong, let me try again...
  624. jonasw it needs to know who sent it to be able to reply with an error
  625. Zash moparisthebest: howaboutno
  626. moparisthebest no single server knows who sent it or who it is intended for
  627. moparisthebest damnit
  628. moparisthebest no single server knows BOTH who sent it AND who it is intended for
  629. moparisthebest finally, need more coffee
  630. jonasw moparisthebest, the destination server needs to know both
  631. Ge0rG moparisthebest: then you have to filter spam at the client.
  632. jonasw it needs to be able to deliver it to the client locally
  633. jonasw and it needs to be able to reply with an erro
  634. jonasw to the original sender
  635. moparisthebest jonasw, right, to the original sender's SERVER
  636. moparisthebest who then handles it from there
  637. jonasw and how would that know where to send it?
  638. moparisthebest that's encrypted so only the senders server can decrypt it
  639. jonasw I see
  640. moparisthebest Ge0rG, yep you always have to with e2e meh
  641. jonasw moparisthebest, incorrect
  642. jonasw whatsapp and others filter spam solely based on metadata
  643. moparisthebest and here you have even less metadata
  644. jonasw email spam is also filtered based on metadata to a large extent (DNSBLs for example)
  645. moparisthebest which is in fact the entire point
  646. jonasw yes, but that’s not a property of e2ee
  647. moparisthebest you can still filter the DNSBL way, ie, blocking the whole server
  648. moparisthebest but that's it
  649. moparisthebest Zash, you don't want to implement it as a server dev or you think it won't work or you think it's a terrible idea, or all 3? :P
  650. waqas has joined
  651. Zash Insufficient context
  652. Guus I know I'm late to the party, but: <response thread="ban-opposing-sides"/>
  653. Guus threat!
  654. jonasw Zash, I guess it’s 14:16:46 Zash> moparisthebest: howaboutno
  655. moparisthebest yep
  656. Zash On phone, it scrolled out of view.
  657. Zash Anyone wanna add a in-reply-to equivalent thing to XMPP ?
  658. jonasw Zash, there are three of that
  659. Kev Zash: References. You're welcome.
  660. jonasw (1) Threads, (2) https://xmpp.org/extensions/xep-0372.html, (3) https://xmpp.org/extensions/xep-0131.html
  661. jonasw possibly more
  662. moparisthebest so the client would have to negotiate this with their server who would negotiate it with the remote server, then the client would triple encrypt everything before sending
  663. Zash Step two, bother client devs
  664. jonasw Zash, no, step 2 is to find a proper UI for that
  665. Alex has left
  666. Zash jonasw: I'd show you my irc client
  667. lumi has joined
  668. jonasw Zash, how does that do In-Reply-To?
  669. Alex has joined
  670. Zash https://www.zash.se/upload/MdiT9Ke5RKyC07wpWTErEw.jpg
  671. Zash Long press on message
  672. Zash All it does afaik is to add the nick as a prefix
  673. jonasw Zash, that only seems like a reasonable workflow on mobile :/
  674. jonasw hm
  675. jonasw desktop could have a button
  676. Zash What, isn't mobile first the thing anymore?
  677. jonasw I don’t care about mobile :)
  678. jonasw (a lotr
  679. Zash And desktop never
  680. jonasw (a lot)
  681. SamWhited >> I'm concerned that "No" is not semantically transmitted, and therefore may be interpreted differently in multiple clients. > dwd: I see that you're married. I need to stop reading Guus' comments on the bus, people look at you funny when you laugh loudly in public.
  682. Zash Maybe you can infer from nickname prefix
  683. moparisthebest sorry what's this > business in front of your messages SamWhited ? I don't understand /sarcasm /no-need-to-respond :)
  684. jonasw SamWhited, I learnt that the hard way while reading The Hitchhikers Guide to the Galaxy for the first time.
  685. Guus tips hat.
  686. SamWhited jonasw: ooh yah, I wouldn't mind reading that again, but maybe not on the bus.
  687. lskdjf has joined
  688. Ge0rG has left
  689. georg has joined
  690. Valerian has left
  691. lovetox has joined
  692. Valerian has joined
  693. mimi89999 has left
  694. Link Mauve “13:17:24 zinid> we don't have avatars working goddamit”, do you have any issue with XEP-0153 in a specific deployment?
  695. jonasw I have an issue with XEP-0153 :/
  696. jonasw it’s the whole damn thing :P
  697. lovetox yeah i dont get that, xep-0153 covers all use cases in my opinion, i dont know why we every would need more
  698. lovetox the only thing that can be said thats not so nice is, that you can request the avatar alone
  699. jonasw lovetox, notification on change?
  700. Link Mauve jonasw, it’s a thing which works, today, in every case.
  701. lovetox and also have to request whole vcard
  702. Link Mauve jonasw, presence update.
  703. lovetox jonasw, presence?
  704. jonasw oh
  705. lovetox but avatar data will always way more then vcard data
  706. lovetox so not that big of a problem
  707. jonasw I didn’t know that
  708. lovetox then you never read 0153
  709. jonasw I admit that
  710. jonasw I read the title and that it was historical and assumed it’d be polling the vcard
  711. Link Mauve Long ago I wanted to add a vCard value for 0084 too, but I never followed on that.
  712. nyco has left
  713. zinid Link Mauve: I have no problems with 0153, I have problems with 0153 and 0084 being implemented by different clients
  714. zinid Link Mauve: also 0084 doesn't work in mucs
  715. zinid and now we're doing the same weird shit with vcard-4
  716. jonasw I heard nobody uses vcard-4?
  717. zinid jonasw: MIX suggests it for example
  718. lovetox no though i plan to use it
  719. edhelas jonasw I do, over PEP
  720. edhelas works great
  721. lskdjf has joined
  722. nyco has joined
  723. zinid ok, we probably need to say good bye to vcards as well
  724. zinid so no avatars, no vcards, no private storage, no file sharing
  725. zinid that's where we are in 2017
  726. lumi has left
  727. zinid and you are discussing how to transfer bold
  728. zinid amusing
  729. mathieui zinid, I want to transfer italics, not bold!
  730. edhelas yup
  731. edhelas zinid I do agree, and bookmark is still broken and non-atomic :p
  732. zinid yes, bookmarks are broken as well because of incompatible implementations
  733. jonasw hopefully we can settle all of this if multi-item PEP lands
  734. jonasw hopefully we can settle all of this when multi-item PEP lands
  735. jonasw hopefully we can settle all of this when multi-item private PEP lands
  736. Holger We'll still have 2-3 XEPs for transmitting bold then :-)
  737. edhelas jonasw PEP could be just Pubsub on JID <3
  738. Link Mauve zinid, clients implementing 0084 instead of 0153, latest 0048 instead of previous 0048 which used to use 0049, because of some perceived superiority of PEP, are the stupid ones imo.
  739. edhelas 🦄
  740. Link Mauve vCard 4 is also something which should be replaced with vCard.
  741. Holger Link Mauve: I think we are the stupid ones in failing to agree on a solution for a given problem.
  742. Holger First step would be acknowledging this as a problem, but I'm being told that's all just the usual XEP standardization process and there's nothing fundamentally wrong with it.
  743. zinid Link Mauve: should be replaced? like in https://xkcd.com/927 ?
  744. Link Mauve I didn’t want to propose to deprecate 0084 or vCard 4 or 0223, mostly because in the future they could be better, but it seems best to ignore them currently.
  745. edhelas Link Mauve what's the issue of using PEP for everything related to JID informations ? then we have one way of getting and setting those info
  746. SamWhited Holger ++
  747. Link Mauve Holger, yes, I agree.
  748. edhelas also with Prosody having persistance and Pubsub now we will be able to use PEP for mostly everything
  749. Link Mauve edhelas, not really, no.
  750. jonasw Link Mauve, excuse me, if I am faced with a choice between a Draft and a Historical XEP, I’m going to implement Draft.
  751. Ge0rG edhelas: prosody isn't even there yet
  752. Link Mauve 0084 is still fundamentally broken, despite persistency in one specific implementation.
  753. jonasw I learnt the hard way that XEP-0084 isn’t deployed widely, and I’m super-annoyed that I had to find out the hard way.
  754. Link Mauve jonasw, yes, the state of these XEPs is sad.
  755. edhelas Link Mauve why 0084 is broken ?
  756. georg has left
  757. zinid edhelas: it doesn't work in mucs
  758. jonasw if it’s not supposed to be implemented, council should make sure that it doesn’t look like one should
  759. edhelas ah yes MUC…
  760. edhelas let's talk about vcards and avatars for Pubsub nodes as well
  761. jonasw but I firmly reject to be the "stupid one" here.
  762. Link Mauve edhelas, it’s only usable by your contacts, in your roster; if you’re in a MUC you can’t use it, if you’re just chatting with someone who isn’t in your roster you can’t use it.
  763. edhelas basically what we are trying to do with MIX
  764. Link Mauve jonasw, as Holger pointed it, it’s not users or developers who are the stupid ones, but the XSF and our current standardisation process.
  765. jonasw XEP-0048 is even worse because you can’t easily discover that the whole way to store it was changed
  766. edhelas allowing PEP for any nodes and JID would be nice
  767. Link Mauve jonasw, yes.
  768. jonasw Link Mauve, oh, I missed that :(
  769. zinid edhelas: but how? by obligating a user's server to keep MIX metadata?
  770. edhelas for example a MUC admin can set a vcard node to his MUC
  771. Link Mauve edhelas, you can already do that though.
  772. jonasw I think that the XEP-0048 should be rolled back and a new XEP should be made at some point, because this was a massive change which shouldn’t happen in draft.
  773. edhelas jonasw roled back to private-xml ?
  774. jonasw edhelas, yes
  775. edhelas hell no
  776. jonasw not becaiuse of technical superiority, because it was incredibly wrong procses-wise
  777. edhelas jonasw I'd like to manage bookmarks this way https://xmpp.org/extensions/xep-0330.html
  778. jonasw I don’t think that private-xml is a good way to store things (but PEP isn’t there yet either, due to lack of deployment), but I don’t think that we can exchange a whole XEP in a minor revision in Draft state!
  779. edhelas as I said, if PEP will be correctly implemented it would unlock many possibilities
  780. edhelas even if avatars for mucs will not be solved…
  781. edhelas Link Mauve what is missing in Prosody to have proper PEP support (persistance and pubsub stuff related) ?
  782. edhelas last time I've checked it was getting there
  783. pep. edhelas, isn't it in trunk already? just the flag that's not turned on
  784. edhelas well yeah
  785. edhelas I have some minor issues with configure on create but it was fine overall (thanks again for the work btw)
  786. edhelas I have to check again though
  787. pep. Maybe I can make that patch, I have never really looked into prosody's sources seriously. Turning on a flag shouldn't be that hard? (not right now though)
  788. Holger Different topic: The current MAM revision says the "server add an <stanza-id/> element" to live messages, and "SHOULD include the element as a child of the forwarded message when using Message Carbons". Why only SHOULD? Now the client can't rely on carbons being tagged. Wasn't the whole point of bumping the MAM namespace to make this guarantee?
  789. lskdjf has joined
  790. edhelas what about having PEP for muc resources ? when I join a MUC I still advertise to the MUC service my caps, if I have avatar+notify the service can push me the avatars of the resources of the MUC (or vcards, or even tunes, geolocation…)
  791. lovetox lol Holger, i definitly depend on that
  792. Holger So change this to a MUST and bump the namespace again? :-) mam:3 will be the one you can depend on, this time for real? :-)
  793. lovetox madness
  794. edhelas and naturally the messages containes <x> muc tags then I can differenciates vcards that are coming from resources
  795. daniel has left
  796. Guus has left
  797. edhelas could work no ?
  798. waqas has left
  799. daniel has left
  800. arc Morning
  801. arc Its meeting time apparently , anyone else here?
  802. dwd arc, You're aware of TZ changes? I don't know what Board agreed WRT handling those.
  803. arc 1600utc this is the time
  804. Guus Indeed it is: https://calendar.google.com/calendar/embed?src=64v3vs15qlalgqv0j7r99ikm1c%40group.calendar.google.com
  805. Steve Kille has left
  806. Guus (I remember to have meticulously marked that in the calendar when the scheduling timezone thingy was discussed)
  807. arc Iirc I copied guus's calendar entry to my own
  808. dwd OK. It *is* Council at this time too. Also Martin is off sick, so he shouldn't be attending.
  809. arc What tz is council meeting at?
  810. jjrh has left
  811. Guus dwd: see calendar: you guys then agreed to do that in UTC too
  812. Guus Completely not up to me to change that, but please update the calendar if you do :)
  813. daniel has left
  814. Valerian has left
  815. jere has joined
  816. daniel has left
  817. nyco has left
  818. intosi has left
  819. moparisthebest are nonzas used in other places than CSI or defined someplace?
  820. jonasw moparisthebest, there are quite a few nonzas in RFC 6120
  821. jonasw (sasl, starttls, stream features, are there more?)
  822. moparisthebest doesn't actually mention the term 'nonza' though, but yea
  823. Kev I still believe nonza isn't a helpful term :)
  824. MattJ moparisthebest, https://xmpp.org/extensions/xep-0360.html
  825. daniel has left
  826. moparisthebest ha I like how that comes *after* CSI
  827. lumi has joined
  828. Steve Kille has joined
  829. jonasw moparisthebest, careful, the term nonza is another thing where the community can be split in two halves.
  830. daniel has left
  831. lovetox has left
  832. Flow With most things you will find someone raising a voice against…
  833. Flow And of course having a well defined term for something we didn't have an unambiguously (short-)term before is very helpful
  834. moparisthebest 1. Nonzas MUST NOT be routed, i.e. they are only exchanged between the two endpoints of an XMPP stream. 2. Nonzas SHOULD NOT have a 'from' or 'to' attribute.
  835. moparisthebest hmm, so what if one wanted to introduce a new nonza-like thing but that did get routed with specific routing rules?
  836. daniel has left
  837. jonasw that’s a something-za then
  838. moparisthebest what would you call that, a rononza ?
  839. jonasw ronza?
  840. jonasw ;-)
  841. Flow moparisthebest, I'm not sure if you could introduce such a thing even if the nonza xep didn't exist
  842. jonasw frankly, with what you’re going for, I’d suggest inventing a new term, because neither nonza nor stanza is applicable
  843. jonasw (while stanza being strictly defined in RFC 6120 IIRC)
  844. SamWhited moparisthebest: that would be against 6120, if I'm not mistaken
  845. jonasw SamWhited, does RFC 6120 forbid routed elements wihch are not <iq/>, <message/> or <presence/>?
  846. Flow jonasw, not explicitly, but how is that supposed to work with federation?
  847. jonasw Flow, moparisthebest plans some negotiation
  848. SamWhited Oh, I thought it did explicitly, but maybe not
  849. Kev Flow: Same as everything else, with negotiation.
  850. moparisthebest yea it'd be opt-in
  851. Flow moparisthebest, what if the recipient is offline?
  852. Flow (it possibly would help if I knew what excactly you trying to achieve ;))
  853. moparisthebest onion xmpp, minimum-metadata xmpp, not sure, naming is one of the hard problems
  854. Flow but even then, if you do negotiation anyway you could just use an IQ or an extension element, which you probably should do anyway because those things get SM ack'd
  855. moparisthebest don't those have to have a from and to ?
  856. moparisthebest I guess maybe you could still hack it in
  857. Flow no
  858. moparisthebest <deliver to="otherserver.com">(this part is encrypted blob #1)<deliver to="jid@otherserver.com">(this part is encrypted blob #2)<message from="bob@bob.com" to="jid@otherserver.com">etc</message>(/end encrypted blob #2)</deliver>(/end encrypted blob #1)</deliver>
  859. moparisthebest that's something like what I'm thinking
  860. moparisthebest each server only knows the hops next to it, no single server knows which 2 clients are talking
  861. jjrh has left
  862. Flow Nice idea
  863. moparisthebest hopefully in that way things like carbons/mam/offline/sm etc etc all work the same
  864. dwd moparisthebest, That's how Tor works, indeed. More or less.
  865. jonasw moparisthebest, wrapping everything in <message/> addressed to the next hop would probably work
  866. moparisthebest yea and from the one it can know probably
  867. marc has left
  868. Flow and would give you SM greatness
  869. daniel has left
  870. jonasw ack
  871. jonasw (pun not intended)
  872. Guus has left
  873. Valerian has joined
  874. moparisthebest <message to="otherserver.com">(this part is encrypted blob #1)<message to="jid@otherserver.com">(this part is encrypted blob #2)<message from="bob@bob.com" to="jid@otherserver.com">etc</message>(/end encrypted blob #2)</message>(/end encrypted blob #1)</message>
  875. dwd Where do you put the security label?
  876. jcbrand has left
  877. moparisthebest well you'd have to put those in a new tag inside message of course
  878. moparisthebest but that's the general idea
  879. jonasw that’ll be some nice overhead right there, base64 on every iteration :)
  880. Flow moparisthebest, I think the destination server should see the sender address
  881. moparisthebest and I think you get the key for otherserver.com from DNS
  882. moparisthebest well that's what you are trying to avoid Flow
  883. Flow you can possibly safely disguise the recipient from the senders server, but if the destination server doesn't know the sender address then it becomes easy to drain your mobiles battery
  884. moparisthebest would also have an odd side-effect, today you run 1 server for you and all contacts to minimize servers with full metadata
  885. moparisthebest this would only give you extra security with different servers
  886. Flow But that's a discussion from when the first wild ProtoXEP appears
  887. Flow *for
  888. moparisthebest Flow, yea and probably the only solution is 'would you like to recieve onion messages from someone at otherserver.com'
  889. Guus has left
  890. Flow mayben even not that, because that would also cause your mobile radio to power up
  891. moparisthebest your server would only ask you once
  892. daniel has left
  893. moparisthebest or, once every X when it already had an active connection or whatever
  894. Flow that could work
  895. jonasw hm, right, you can’t even filter by roster on the server side
  896. nyco board meeting?
  897. jonasw except if you put some keys into the roster, too
  898. moparisthebest nope no roster or precense or anything here
  899. moparisthebest and you'd never want to send other stanzas to each other
  900. jonasw moparisthebest, right
  901. jonasw I don’t like that
  902. Guus has joined
  903. jonasw I don’t see how you can have this in a sane manner.
  904. moparisthebest it would involve a super extra level of opt-in :)
  905. jonasw which doesn’t push all the validation load on the client
  906. moparisthebest but also, precense isn't important anymore remember? :)
  907. moparisthebest conversations doesn't display it normally, for instance, and with offline/mam etc all working, no one cares
  908. jonasw moparisthebest, presence isn’t, but being able to filter messages by sender server-side is.
  909. jonasw spam filtering essentially
  910. moparisthebest yep you can only do by whole server this way
  911. jonasw yes, which is bad
  912. moparisthebest not really if it's opt-in
  913. jonasw I frankly don’t see this finding a serious user base
  914. Flow nyco, doesn't look like board meeting :(
  915. nyco indeed
  916. Guus Arc was here an hour ago
  917. nyco yep
  918. moparisthebest jonasw, when has that ever stopped a xep or code :)
  919. arc Nyco we're on UTC
  920. daniel has left
  921. nyco this changes the hour of availability
  922. dwd While daylight savings time is indeed daft, I don't think ignoring it is the solution - Council basically had to move because a UTC-pinned meeting ends up clashing for me (at least, every other week).
  923. nyco for me too
  924. nyco let's remove timezones already, one planet, one time
  925. SamWhited In the interest of making small, incremental changes let's remove DST first, then we can consider timezones.
  926. dwd Swatch Internet Time in Beats?
  927. nyco meanwhile we still have no board meeting...
  928. nyco ok, gotta go ;-)
  929. dwd nyco, As noted earlier, Martin's off sick so cannot (or rather should not) attend.
  930. jonasw you’re not his mom!kk
  931. Syndace has joined
  932. daniel has left
  933. dwd jonasw, True, but I can get Laura to say the same.
  934. dwd (For the avoidance of doubt, Laura is not Martin's mum either)
  935. Steve Kille has left
  936. arc has left
  937. arc has joined
  938. waqas has joined
  939. Steve Kille has joined
  940. daniel has left
  941. efrit has joined
  942. jubalh has left
  943. daniel has left
  944. lumi has left
  945. daniel has left
  946. Steve Kille has left
  947. Steve Kille has left
  948. efrit has left
  949. jubalh has joined
  950. Kev has left
  951. Valerian has left
  952. jjrh has left
  953. jubalh has left
  954. jubalh has joined
  955. ralphm has left
  956. efrit has joined
  957. Guus has left
  958. Ge0rG has left
  959. waqas has left
  960. waqas has joined
  961. waqas has left
  962. Guus has joined
  963. jjrh has left
  964. Steve Kille has left
  965. jubalh has joined
  966. Ge0rG has left
  967. jjrh has left
  968. Ge0rG has left
  969. Valerian has joined
  970. Steve Kille has left
  971. jjrh has left
  972. jjrh has left
  973. Ge0rG has left
  974. jjrh has left
  975. jjrh has left
  976. jjrh has left
  977. la|r|ma has joined
  978. jjrh has left
  979. jjrh has left
  980. daniel has left
  981. matlag has joined
  982. Ge0rG has left
  983. lskdjf has left
  984. lskdjf has left
  985. Guus has left
  986. Guus has joined
  987. daniel has left
  988. lskdjf has left
  989. Guus has left
  990. Guus has joined
  991. Ge0rG has left
  992. efrit has left
  993. lumi has joined
  994. goffi has left
  995. zinid has left
  996. efrit has joined
  997. Valerian has left
  998. Ge0rG has left
  999. ralphm has left
  1000. Guus has left
  1001. Valerian has joined
  1002. Guus has joined
  1003. arc has left
  1004. Ge0rG has left
  1005. arc has joined
  1006. jere has left
  1007. jere has joined
  1008. Ge0rG has left
  1009. tux has joined
  1010. zinid has left
  1011. Tobias has joined
  1012. goffi has joined
  1013. Ge0rG has left
  1014. ralphm has left
  1015. Kev has joined
  1016. Tobias has joined
  1017. Ge0rG has left
  1018. Guus has left
  1019. Guus has joined
  1020. Ge0rG has left
  1021. nyco has left
  1022. arc has left
  1023. arc has joined
  1024. Kev has left
  1025. Ge0rG has left
  1026. lovetox has joined
  1027. Valerian has left
  1028. Ge0rG has left
  1029. sonny has left
  1030. sonny has joined
  1031. goffi has left
  1032. tux has left
  1033. lskdjf has left
  1034. lskdjf has left
  1035. lskdjf has left
  1036. Alex has left
  1037. Ge0rG has left
  1038. Valerian has joined
  1039. la|r|ma has left
  1040. Kev has joined
  1041. Ge0rG has left
  1042. Ge0rG has left
  1043. Valerian has left
  1044. Valerian has joined
  1045. Tobias has joined
  1046. Valerian has left
  1047. ThurahT has left
  1048. efrit has left
  1049. ThurahT has joined
  1050. jubalh has joined
  1051. Ge0rG has left
  1052. efrit has joined
  1053. nyco has left
  1054. Ge0rG has left
  1055. marc has left
  1056. jubalh has left
  1057. marc has left
  1058. daniel has left
  1059. Ge0rG has left
  1060. daniel has left
  1061. arc has left
  1062. arc has joined
  1063. lovetox has left
  1064. arc has left
  1065. arc has joined
  1066. arc has left
  1067. arc has joined
  1068. arc has left
  1069. arc has joined
  1070. Valerian has joined
  1071. arc has left
  1072. arc has joined
  1073. arc has left
  1074. arc has joined
  1075. Ge0rG has left
  1076. Kev has left
  1077. valo has joined
  1078. valo has joined
  1079. Ge0rG has left
  1080. jere has joined
  1081. efrit has left
  1082. arc has left
  1083. arc has joined
  1084. Ge0rG has left
  1085. efrit has joined
  1086. arc has left
  1087. arc has joined
  1088. efrit has left
  1089. arc has left
  1090. arc has joined
  1091. arc has left
  1092. arc has joined
  1093. arc has left
  1094. arc has joined
  1095. Ge0rG has left
  1096. efrit has joined
  1097. moparisthebest has joined
  1098. la|r|ma has left