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


  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


  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


  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


  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


  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


  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


  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.


  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.


  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


  347. jonasw

    if that helps

  348. Zash


  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


  359. jonasw

    there’s no media type here.

  360. Ge0rG

    I don't like the use of the term "Language" in there.

  361. Ge0rG


  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


  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


  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


  556. jonasw

    itym </thread>?

  557. zinid


  558. Ge0rG


  559. mathieui


  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


  580. Ge0rG


  581. dwd


  582. jonasw


  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


  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


  654. jonasw

    Zash, I guess it’s 14:16:46 Zash> moparisthebest: howaboutno

  655. moparisthebest


  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


  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


  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


  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


  729. mathieui

    zinid, I want to transfer italics, not bold!

  730. edhelas


  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


  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


  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


  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


  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


  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


  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


  916. Guus

    Arc was here an hour ago

  917. nyco


  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