XSF Discussion - 2019-07-18


  1. lnj has joined

  2. wojtek has left

  3. Chobbes has joined

  4. vanitasvitae has left

  5. vanitasvitae has joined

  6. waqas has joined

  7. Lance has joined

  8. Lance has left

  9. Lance has joined

  10. mimi89999 has left

  11. mimi89999 has joined

  12. ziggys has left

  13. mimi89999 has left

  14. mimi89999 has joined

  15. mimi89999 has left

  16. mimi89999 has joined

  17. alacer has joined

  18. mimi89999 has left

  19. mimi89999 has joined

  20. remko has joined

  21. ziggys has joined

  22. mimi89999 has left

  23. mimi89999 has joined

  24. debacle has left

  25. remko has left

  26. ziggys has left

  27. ziggys has joined

  28. ziggys has left

  29. ziggys has joined

  30. Douglas Terabyte has left

  31. Douglas Terabyte has joined

  32. remko has joined

  33. Chobbes has left

  34. Lance has left

  35. Lance has joined

  36. neshtaxmpp has joined

  37. remko has left

  38. ziggys has left

  39. lnj has left

  40. pdurbin has joined

  41. pdurbin has left

  42. pdurbin has joined

  43. lskdjf has left

  44. adityaborikar has left

  45. adityaborikar has joined

  46. adityaborikar has left

  47. adityaborikar has joined

  48. adityaborikar has left

  49. adityaborikar has joined

  50. karoshi has joined

  51. pdurbin has left

  52. pdurbin has joined

  53. adityaborikar has left

  54. adityaborikar has joined

  55. Nekit has joined

  56. adityaborikar has left

  57. adityaborikar has joined

  58. adityaborikar has left

  59. adityaborikar has joined

  60. david has left

  61. lee has left

  62. lee has joined

  63. wurstsalat has joined

  64. adityaborikar has left

  65. valo has left

  66. valo has joined

  67. goffi has joined

  68. goffi has left

  69. goffi has joined

  70. goffi has left

  71. goffi has joined

  72. david has joined

  73. adityaborikar has joined

  74. adityaborikar has left

  75. adityaborikar has joined

  76. remko has joined

  77. igoose has left

  78. igoose has joined

  79. moparisthebest has left

  80. moparisthebest has joined

  81. COM8 has joined

  82. alacer has left

  83. alacer has joined

  84. adityaborikar has left

  85. Mikaela has joined

  86. COM8 has left

  87. adityaborikar has joined

  88. Syndace has left

  89. Syndace has joined

  90. sezuan has joined

  91. adityaborikar has left

  92. adityaborikar has joined

  93. vanitasvitae has left

  94. vanitasvitae has joined

  95. Guus has left

  96. Guus has joined

  97. waqas has left

  98. waqas has joined

  99. valo has left

  100. valo has joined

  101. mimi89999 has left

  102. igoose has left

  103. mimi89999 has joined

  104. Yagiza has joined

  105. valo has left

  106. waqas has left

  107. igoose has joined

  108. Lance has left

  109. Lance has joined

  110. Kev has joined

  111. valo has joined

  112. Lance has left

  113. Lance has joined

  114. rion has left

  115. rion has joined

  116. adityaborikar has left

  117. adityaborikar has joined

  118. patrick has left

  119. valo has left

  120. alacer has left

  121. debacle has joined

  122. alacer has joined

  123. valo has joined

  124. larma has left

  125. larma has joined

  126. pdurbin has left

  127. Lance has left

  128. rion

    I'm planning to provide some improvements to SIMS xep. And I think this recent unique MUC occupant id xep would be useful here. Is it going to be published any soon?

  129. jonas’

    rion, I expect it to be accepted

  130. jonas’

    but that’s just me ;)

  131. jonas’

    still lacks two council votes because the respective members weren’t available for the meeting yesterday

  132. jonas’

    which means it’ll probably be dealt with next wednesday

  133. igoose has left

  134. Zash

    What kind of improvements?

  135. Ge0rG

    The biggest issue I have with the occupant-id thing is that IT'S NOT ANONYMOUS!

  136. ralphm

    Anonymity is in the eye of the beholder?

  137. Ge0rG

    it's effectively adding a pseudonym for each bare JID in a MUC.

  138. jonas’

    my sarcasmometer isn’t sure about what you’re doing

  139. Ge0rG

    I'm not saying it's bad or wrong, just that the name doesn't fit.

  140. jonas’

    my sarcasmometer isn’t sure about what you’re saying

  141. ralphm

    Ah, right.

  142. jonas’

    Ge0rG, you didn’t mention that yesterday

  143. jonas’

    but then again, MUC is pseudonymous in itself, it won’t get better than that?

  144. ralphm

    It would be better if that were more explicit.

  145. Ge0rG

    jonas’: it's a different kind of pseudonymous

  146. ralphm

    Anonymity for occupants v.s. admins, right?

  147. Ge0rG

    one could hash (muc-jid, nickname, bare-user-jid) together to allow nick changes to become identity changes.

  148. Ge0rG

    jonas’: I didn't mention it because it was not critical for what the XEP is supposed to do

  149. pep.

    Ge0rG, I think one of the goal is not to include nick in there

  150. pep.

    Ge0rG, I think one of the goals is not to include nick in there

  151. pep.

    But yeah that could be made explicit

  152. Ge0rG

    I still think that making it a proxy-JID on top of the MUC service domain would be a Good Thing™, and then just stuff it into messages and presence.

  153. jonas’

    Ge0rG, ITYM making MIX?

  154. ralphm

    This

  155. pep.

    Ge0rG, I also have something like that in mind

  156. pep.

    But it's not incompatible

  157. jonas’

    are you going to re-invent MIX in worse on top MUC?

  158. ralphm

    I think doing MIX is a much better use of time than attempting to bolt things onto MUC even further.

  159. pep.

    worse? Last time I checked proxy-JID wasn't particularly pretty in MIX, trying to fix 4 things into 3 (is that the one?)

  160. pep.

    worse? Last time I checked proxy-JID wasn't particularly pretty in MIX, trying to fit 4 things into 3 (is that the one?)

  161. Ge0rG

    pep.: yeah, it's the one

  162. jonas’

    pep., you’ll end up in the same situation with MUC, plus the additional issues from the different participant model

  163. ralphm

    Of course a MIX service could still expose a MUC interface/facade.

  164. Ge0rG

    ralphm: I'm fighting hard to keep that a thing, yes.

  165. Ge0rG

    I agree that proxy-JID is one of the uglier things of MIX.

  166. jonas’

    pep., the protoxep wants the occupant-id to be stable across rejoins. putting it on the domain then requires to make it reversible (so a simple HMAC won’t do, you eithre need to encrypt it symmetrically (not feasible) or store the mapping (ew))

  167. Ge0rG

    now that I think about it. Advertising those proxy JIDs inside of MUC will add a bunch of problems indeed, like clients trying to PM those JIDs

  168. Ge0rG

    it was a dumb idea, nevermind.

  169. igoose has joined

  170. jonas’

    Ge0rG, excellent, problem solved ;)

  171. ralphm

    Yay

  172. Ge0rG

    I just hate UUIDs for their uglyness.

  173. pep.

    jonas’, putting what on the domain

  174. Zash

    Where are there UUIDs?

  175. pep.

    Is that a remake of yesterday's discussion in programming@

  176. Ge0rG

    I suggest HMAC(server_secret, muc-JID + user-bare-JID)

  177. Ge0rG

    Zash: "UUID" is a placeholder for "long, random-looking hexadecimal string"

  178. ralphm

    Also, who cares. It is not something the user should ever see.

  179. pep.

    Ge0rG, HMAC(real_bare_jid, room_secret) is what I use in the module atm

  180. ralphm

    Someone should use emoji for hex digits

  181. Ge0rG

    pep.: that requires persisting the room_secret, whereas with a server_secret + room-JID you reduce the storage reqs

  182. pep.

    jonas’, see I said somebody would care about that :P

  183. Ge0rG

    ralphm: did you just say "usability nightmare"?

  184. pep.

    I just didn't know how to do that with prosody's API, but I don't really mind :)

  185. Zash

    Ge0rG room destruction and recreation would produce the same IDs then, which seems undesirable

  186. pep.

    ^this

  187. pep.

    ^ this

  188. Ge0rG

    Zash: is it really?

  189. alacer has left

  190. alacer has joined

  191. Ge0rG

    okay, you could also rotate the room_secret on jid visibility changes.

  192. Ge0rG

    (as if anybody would do those in practice)

  193. pep.

    what does that mean

  194. jonas’

    Ge0rG, I prefer a room secret managed by the server, because it fixes destroy/re-create use cases

  195. jonas’

    Ge0rG, plus it avoids having to have the secret configurable / have a server/domain-wide secret which needs to be managed somehow

  196. Ge0rG

    jonas’: what's the threat model in those cases?

  197. jonas’

    Ge0rG, take a destroyed room, make it full-anon to lure folks back in (clients could warn if it isn’t anon/anon-mode changed between joins), note occupant-IDs, revert to non-anon

  198. Ge0rG

    I create a MUC, invite everybody there, store the occupant-id mappings, close down the MUC and let somebody else recreate it?

  199. jonas’

    Ge0rG, take a destroyed room, re-create it becoming owner, make it full-anon to lure folks back in (clients could warn if it isn’t anon/anon-mode changed between joins), note occupant-IDs, revert to non-anon

  200. Ge0rG

    full-anon has been removed, hasn't it?

  201. jonas’

    Ge0rG, I call "occupant-id anon" "full anon"

  202. jonas’

    when we assume the path towards where the owner cannot see the real JID anymore, instead operating on the occupant-id

  203. Ge0rG

    jonas’: your naming convention needs more thought

  204. jonas’

    Ge0rG, sorry

  205. Ge0rG

    I might have mentioned it before, but none of this is actually anon.

  206. jonas’

    yes

  207. jonas’

    full-pseudonymous then ;)

  208. pep.

    That's also something I'd like to see, using occupant-id instead of real-jids to do MUC operations (even for owners)

  209. valo has left

  210. valo has joined

  211. jonas’

    Ge0rG, admittedly, I’m a bit thinking ahead here, but I think it’s valuable to do that

  212. Ge0rG

    pep.: we can hardly manage affiliation management in our clients with the existing protocol.

  213. Syndace has left

  214. pep.

    Fix your client?

  215. Ge0rG

    jonas’: what's the additional attack surface compared to "make a full-pseudo room full of people non-anon"

  216. winfried has left

  217. winfried has joined

  218. jonas’

    Ge0rG, you need to be owner to do that

  219. Ge0rG

    jonas’: yes, like in your proposed scenario

  220. pep.

    tbh if we were to start using occupant-id for more things, I'd prefer that to be a component setting and not a room setting that the owner can change

  221. Ge0rG

    pep.: what to be a component setting?

  222. rion

    The problem I see in SIMS is jingle transfer with references like this <reference xmlns='urn:xmpp:reference:0' type='data' uri='xmpp:romeo@montague.lit/resource?jingle-ft' /> While they look quite simple to handle this "resource" part makes it very temporary. While it can be intended to have a temporary share it doesn't look quite reliable anyway. So a client to download a file should try all possible resources and expect the jingle session will be rejected immediately if the resource doesn't have this file. I'm not sure how it can't be enhanced, but probably there is a way (likely something with carbons). As far as I understand Jingle session publishing suffers from the same problem. We have to send <start> request to specific resource, but which one?

  223. rion

    And with MUCs things are even more complicated.

  224. pep.

    Ge0rG, "use occupant-id for things", as said above (using it for MUC operations instead of real-jids)

  225. alacer has left

  226. alacer has joined

  227. Ge0rG

    pep.: so you want to be able to enforce occupant-id-stamping on all MUCs of your service?

  228. Kev

    > pep. 10:42 That's also something I'd like to see, using occupant-id instead of real-jids to do MUC operations (even for owners) That would be broken, wouldn't it? You would need someone to join the room first before you could ever ban them.

  229. Kev

    And you wouldn't be able to ban other than single users.

  230. tom

    what if someone is set on harassing a muc

  231. tom

    and start creating a whole bunch of free accounts on a host

  232. Ge0rG

    tom: they'll just register new accounts via IBR

  233. Ge0rG

    ...on different hosts

  234. tom

    and you can't preactively ban

  235. Ge0rG

    there's that script that will register thousands of IBR accounts on hundreds of servers for you.

  236. tom

    how can we metigate that?

  237. Ge0rG

    we can hope that the abusers won't find out

  238. tom

    so is this like an open resolvers on the internet type situation?

  239. Kev

    More or less, yes.

  240. tom

    oh no.

  241. tom

    nevermind

  242. APach has left

  243. Nekit has left

  244. frainz has left

  245. APach has joined

  246. frainz has joined

  247. lskdjf has joined

  248. Nekit has joined

  249. alacer has left

  250. pep.

    Kev, you can use mod_firewall for that. Or you can ask the server operator.

  251. pep.

    (well in both cases it's up to the server operator)

  252. pep.

    I'm not saying banning a real-jid wouldn't be possible anymore, I just don't feel the need to expose them

  253. Kev

    I don't understand the motivation, though. Suggesting mod_firewall, or other things the server operator needs to do, seems to be moving away from a functional standard mechanism, and that's kinda what we do.

  254. pep.

    handling spam is not really well spec'd tbh

  255. pep.

    And I don't think it's ever possible to do

  256. Kev

    I don't think banning people is necessarily about spam.

  257. pep.

    And that feature wouldn't go away

  258. pep.

    And this feature wouldn't go away

  259. frainz has left

  260. Syndace has joined

  261. frainz has joined

  262. Ge0rG

    we have blocking, but it doesn't work for MUCs

  263. Zash

    Technical solutions to social problems?

  264. igoose has left

  265. alacer has joined

  266. pdurbin has joined

  267. adityaborikar has left

  268. adityaborikar has joined

  269. igoose has joined

  270. ralphm

    So much this

  271. ralphm

    Unless you get really radical, technology usually doesn't solve social problems. Merely mitigates, or permanently removes the opponent from the equation. The latter is where Geneva is often mentioned.

  272. Ge0rG

    Let's give up and farm potatoes.

  273. ralphm

    You've never been in the Netherlands?

  274. Ge0rG

    ralphm: It'd be interesting to have a way to accomplish that... over the Internet.

  275. Ge0rG

    OTOH, there are underground groups with pre-made lists-of-opponents-to-be-removed, so I'm less prepared than they are, and their lists have all the wrong people on them.

  276. Ge0rG

    And without being able to properly execute, I shouldn't utter this kind of wish.

  277. ralphm

    ...

  278. pdurbin has left

  279. pep.

    Is there an xmpp logo in svg somewhere?

  280. pep.

    Ah on the main page

  281. adityaborikar has left

  282. pdurbin has joined

  283. adityaborikar has joined

  284. igoose has left

  285. pdurbin has left

  286. igoose has joined

  287. Zash has left

  288. krauq has left

  289. krauq has joined

  290. matlag has left

  291. matlag has joined

  292. kokonoe has left

  293. valo has left

  294. kokonoe has joined

  295. COM8 has joined

  296. COM8 has left

  297. lnj has joined

  298. flow has left

  299. valo has joined

  300. adityaborikar has left

  301. patrick has joined

  302. Chobbes has joined

  303. flow has joined

  304. eevvoor has joined

  305. alacer has left

  306. andrey.g has left

  307. ziggys has joined

  308. Zash has joined

  309. Chobbes has left

  310. Chobbes has joined

  311. adityaborikar has joined

  312. Chobbes has left

  313. Chobbes has joined

  314. Chobbes has left

  315. andrey.g has joined

  316. nyco

    Board meeting -10 min

  317. MattJ

    o/

  318. nyco

    time+1

  319. nyco

    where's the gavel?

  320. ralphm bangs gavel

  321. ralphm

    0. Welcome

  322. ralphm

    Who do we have?

  323. Seve says hi.

  324. MattJ

    Hey

  325. nyco

    bonjour

  326. ralphm

    Hi!

  327. Guus

    I'm on a very unreliable network

  328. ralphm

    :-D

  329. ralphm

    1. Minute taker

  330. Guus

    I might drop at any time, for any period

  331. nyco

    if nobody wants it, I'll do it

  332. ralphm

    2. Badges

  333. ralphm

    Poll results yet?

  334. nyco

    not sent yet, was waiting for more feedback: are we ok to go?

  335. nyco

    https://forms.gle/nY76DLaD6Ttyn8AV9 latest iteration, DO NOT VOTE YET

  336. ralphm

    I think so

  337. nyco

    if no red light today, I'll send it to members@ after I send the minutes

  338. edhelas has left

  339. MattJ

    sgtm

  340. edhelas has joined

  341. ralphm

    But I'm a bit confused. You didn't really add more questions per dwd's suggestion?

  342. nyco

    yes, I did, second page

  343. ralphm

    Oh!

  344. nyco

    first page is the choice + comment

  345. ralphm

    Yes, I see it now

  346. ralphm

    Looks good to me

  347. dwd

    LGTM2.

  348. nyco

    ok, thx all

  349. Seve

    Nice!

  350. ralphm

    Thanks, nyco!

  351. dwd

    So disappointed it's "badges" and not "badgers" though.

  352. ralphm

    :-D

  353. ralphm

    3. Messenger Regulation

  354. ralphm

    I'm sure it's holiday season, so nothing to report here?

  355. lee has left

  356. ralphm

    Ge0rG

  357. Ge0rG

    ralphm: I still haven't written that promised mail to members@

  358. Ge0rG

    the contact person was very much interested in e2ee btw.

  359. Ge0rG

    also promised to come back to me in the timeframe of two months, which isn't over yet.

  360. Ge0rG

    our task of determining what exactly we expect is still open

  361. Ge0rG

    or rather what we want

  362. ralphm

    I think the first goal is give them the executive summary of what XMPP is

  363. Ge0rG

    maybe one of the XSF sposors would stand up to sponsor some heavy lobbying? ;)

  364. Ge0rG

    ralphm: that I did.

  365. Ge0rG

    ralphm: we have been listed as one of the stakeholders in the process.

  366. ralphm

    Good

  367. waqas has joined

  368. edhelas has left

  369. Ge0rG

    so what is our desired outcome? put XMPP into law? put "standardized protocol" into law?

  370. nyco

    well what other protocol qualifies?

  371. nyco

    no one sane recommands SIP/SIMPLE

  372. nyco

    Matrix is in its infancy

  373. Ge0rG

    nyco: matrix has been accelerating their standardization efforts

  374. Ge0rG

    nyco: the only difference between matrix and xmpp, for an outside observer, is some rfc numbers

  375. nyco

    Telegram protocol is quite not open nor standard, although openly documented, only one server implem

  376. ralphm

    The thing I find most important in general was summarized perfectly by Google (https://developers.google.com/talk/open_communications): Freedom of Client, Service, Platform.

  377. Nekit has left

  378. Nekit has joined

  379. Ge0rG

    ralphm: from when is that? 2004?

  380. nyco

    Matrix has only one server implem, thus does not qualify as an open standard

  381. ralphm

    Ge0rG: slightly later

  382. Ge0rG

    nyco: I think you are mixing up things there.

  383. ralphm

    Ge0rG: But it is indeed timeless

  384. nyco

    to be honest, we can push open standards protocols, but only one qualifies

  385. Ge0rG

    nyco: this is a classic approach, to make the requirements appear generic but be sufficiently specific so that only your proposal matches.

  386. Ge0rG

    still, Microsoft Open Office XML is the mandatory reference here.

  387. nyco

    athough I am biaised, you gotta be honest: what other protocol qualifies? none

  388. Ge0rG

    I'm sure that if pushed by legal regulations, Facebook, Google and the others will all come up with their own "open" "standard"

  389. Ge0rG

    ...overnight

  390. nyco

    Note: have to leave exactly at 16:00

  391. pep.

    nyco, personally I wouldn't want to put a protocol name in the legislation

  392. nyco

    pep. this, I agree

  393. ralphm

    Ge0rG: indeed, the things we have going for us: standardized at IETF, many implementation, not a single entity in control

  394. MattJ

    I think we can all agree on that

  395. ralphm

    ss

  396. pep.

    Ge0rG, that will happen and I don't think there's anything you can do about this

  397. Ge0rG

    pep.: it's possible to make law that leaves the specific protocols open for a later decree.

  398. nyco

    the RGI name protocols (Référentiel Général d'Interopérabilité) in France

  399. Ge0rG

    pep.: we might have to create wording that, in the presence of malicious actors, can't be gamed too much

  400. ralphm

    Even if you'd mandate 'XMPP', what does that mean?

  401. pep.

    RFC3920!

  402. nyco

    we must then clearly define what an open standard is, and then different actors will push their agendas

  403. ralphm

    I think what you'd want is interop in features, retaining the freedoms I (Google) listed.

  404. nyco

    https://en.wikipedia.org/wiki/Open_standard

  405. Zash

    Exactly what Google deployed in 2006, no more, no less

  406. ralphm

    This will be fluid over time.

  407. ralphm

    Zash: with various notes, to be honest

  408. Ge0rG

    so how do we move forward now?

  409. nyco

    (time -5 min for me to leave)

  410. Alex has left

  411. ralphm

    Does it make sense to try to push what I wrote above, and showing how XMPP would get us there?

  412. Ge0rG

    we also should prepare an answer for E2EE over bridges.

  413. MattJ

    I think so

  414. pep.

    Ge0rG, "it doesn't work"? :/

  415. ralphm

    FWIW, full interop is never going to happen. There will always be features only certain implementations support. Establishing a baseline is not easy, but maybe our compliance suites could be a guide.

  416. pep.

    The best example of E2EE over bridges we have is OTR..

  417. Ge0rG

    which reminds me of things I need to put onto next Council's agenda.

  418. Chobbes has joined

  419. edhelas has joined

  420. Ge0rG

    pep.: OTR is also the worst example.

  421. ralphm

    Ge0rG: bridges between XMPP and other networks (e.g. Matrix)?

  422. pep.

    Ge0rG, agreed

  423. nyco

    and IRC

  424. Ge0rG

    ralphm: if you mandate open access to facebook, whatsapp etc over xmpp, it will be some kind of bridge as well

  425. nyco

    on their side

  426. Ge0rG

    even if the bridging part is hidden from us

  427. ralphm

    I'd also note that although both XMPP and Matrix have federation features, making it a single federation is hard.

  428. nyco

    gotta go, sorry, I'm off

  429. ralphm

    nyco: thanks@

  430. Ge0rG

    do we want to mandate OMEMO in all IM clients? Or rather wait for / influence MLS?

  431. Lance has joined

  432. ralphm

    Ge0rG: well, I assume that Facebook, WhatsApp would expose their services as an XMPP server.

  433. ralphm

    I.e. the interop would be XMPP s2s

  434. Ge0rG

    ralphm: this is not an answer to E2EE

  435. ralphm

    Indeed, you'd need to agreed on protocol agnostic E2EE. I don't know if that's possible.

  436. igoose has left

  437. Ge0rG

    ralphm: either that, or all providers need to implement a protocol-specific E2EE algo in all their clients

  438. Ge0rG

    which is not impossible, if properly agreed upon by all parties

  439. ralphm

    Why couldn't you specify an E2EE mechanism like how SASL is defined?

  440. Ge0rG

    ralphm: please explain

  441. ralphm

    I.e. you can do SASL over IMAP, XMPP, and others.

  442. ziggys has left

  443. ralphm

    The interactions are defined, the wire protocol framing is a specialization

  444. ralphm

    Where things get hard is encrypting more than just text.

  445. ralphm

    If whatever you encrypt needs to be distributedly extensible, you need to agree to, basically, XMPP stanzas.

  446. valo has left

  447. igoose has joined

  448. ralphm

    I think we can continue this discussion, but I'd also close the formal part of this meeting.

  449. ralphm

    5. Date of Next

  450. ralphm

    +1W

  451. ralphm

    6. Close.

  452. ralphm

    KTXBYE

  453. MattJ

    Thanks!

  454. ralphm bangs gavel

  455. Seve

    Thank you :)

  456. ralphm

    Ge0rG: is it clear what I meant?

  457. Alex has joined

  458. valo has joined

  459. Ge0rG

    ralphm: yes, thanks.

  460. eevvoor has left

  461. ralphm

    I suppose you could also define a JSON format that can then be encrypted, but if you want distributed extensibility, you need namespaces, etc., and you are basically replacing angle brackets with curly ones.

  462. Ge0rG

    I wonder if OMEMO isn't already 90% there

  463. ralphm

    I think DE is also a selling point to reluctant corps

  464. Guus

    I love this WiFi. Good meeting! Ttyl

  465. pep.

    Ge0rG, but not really appealing. I'm not sure I want to get stuck with only encrypted body in the legislation

  466. Ge0rG

    if only somebody had told the XEP authors.

  467. pep.

    And if you want more, as ralphm says, you have to have the same transport on the other side basically

  468. pep.

    Ge0rG, well OMEMO or not that's what you're saying, and that's effectively the only thing that can go over bridges (body-only)

  469. ralphm

    Guus: :-/

  470. Ge0rG

    pep.: OMEMO is what's there in XMPP land. There is also MLS of which I have no clue.

  471. ralphm

    pep.: same transport (XMPP s2s) would be ideal. For E2EE you need a common format to encrypt.

  472. Ge0rG

    pep.: and I'm sure we can easily embed XML or JSON or whatever inside OMEMO payloads

  473. pep.

    Ge0rG, and then you'd need clients to put encrypted json in body? :(

  474. ralphm

    pep.: and if you want Distributed Extensibility within that encrypted payload, then you might as well mandate XML Stanzas

  475. Ge0rG

    pep.: into the new OMEMO element.

  476. Ge0rG

    ralphm: at which point we arrive at Stanza Encryption

  477. pep.

    Ge0rG, I'm not sure I follow

  478. pep.

    You're not talking about stanza encryption yet?

  479. Ge0rG

    no idea what we are talking about

  480. ralphm

    We were talking about how E2EE might work across networks.

  481. ralphm

    E.g. Facebook, WhatsApp, 'normal' XMPP clients

  482. ralphm

    And I tried to list requisites, given that I assume both we and Facebook would want to be able to encrypt more than just plain text.

  483. Ge0rG

    I'm not sure how much the second part of that assumption holds.

  484. pep.

    At least we do, I'm not sure about Facebook

  485. pep.

    But that'S something to consider

  486. ralphm

    Well, have you seen Facebook Templated messages?

  487. pep.

    no, what are they?

  488. Ge0rG

    pep.: https://developers.facebook.com/docs/messenger-platform/send-messages/templates/

  489. ralphm

    Or using another example: Slack, which has a lot of rich stuff in messages.

  490. Ge0rG still has that tab open

  491. Zash

    Buttons?

  492. Ge0rG

    Zash: Buttons++

  493. ralphm

    If I was a company working on this, and I wanted to offer E2EE, I'd definitely want/need to include this

  494. Ge0rG

    now we are speaking of a baseline feature set

  495. Ge0rG

    this will be hard to agree upon.

  496. pep.

    Right. "What do we want to have in the legislation"

  497. Ge0rG

    because facebook needs templates, instagram needs galleries and whatsoever.

  498. ralphm

    (also caroussels, maps, link cards (url, picture, title, description), flight infor)

  499. MattJ

    Nobody said open standards were easy

  500. alacer has joined

  501. ralphm

    Ge0rG: that's why I mentioned distributed extensibility. If each vendor has the ability to add their own stuff, you are not limiting a feature set.

  502. ralphm

    Of course whether other clients can interpret all the things is another matter.

  503. Ge0rG

    ralphm: I think you just invented the XSF

  504. ralphm

    But you'd definitely need to have a baseline (probably plain text)

  505. ralphm

    Not even the XSF needs to be a single controlling entity.

  506. ralphm

    At VEON, we clearly defined all rich messaging in a way that it could have a fallback body with plain text.

  507. Ge0rG

    I wish XEP authors would consider that.

  508. ralphm

    Aren't you on the Council?

  509. Ge0rG

    Each rich messaging XEP should: - mandate a legacy body format - mandate that the body MUST NOT contain anything else, so that compliant clients can ignore it

  510. ralphm

    Make it one of your review checkboxes.

  511. Ge0rG

    ralphm: you'd be surprised, it already is

  512. ralphm

    I'd hoped so. It was definitely on mine.

  513. Ge0rG

    unfortunately I'm not aware of any XEP that follows this simple pattern

  514. Nekit has left

  515. Ge0rG

    not even EME

  516. Ge0rG

    > When a message is marked with an encryption tag and can not be decrypted, the body can safely be ignored and a localized message displayed instead. This is close, but not quite there.

  517. Nekit has joined

  518. ralphm

    No?

  519. ralphm

    XHTML-IM?

  520. ralphm

    References, and thus SIMS, also assume this.

  521. Zash

    So when are we un-deprecating XHTML-IM again?

  522. ralphm

    No, I'm saying that the way it was designed, it assumes that if you don't support it, you can still use the body.

  523. ralphm

    Without loss of information ideally.

  524. ralphm

    Also, XEP-0060, section 12.7 (and other places).

  525. Ge0rG

    ralphm: indeed, XHTML-IM is explicit in that regard. I'm not sure I would count References as it's only an annotation to <body>, not a replacement.

  526. waqas has left

  527. ralphm

    Sure, but the idea here is entirely that the common format is plain text, and that richer stuff points to it.

  528. ralphm

    (sure, you can also use References with actually referencing begin/end, but that'd mean you lose information)

  529. ralphm

    without

  530. Ge0rG

    I'm looking at XEPs that contain a fallback <body> for non-supporting clients, and that should mandate that the <body> will be superseded

  531. Ge0rG

    OOB as currently used is the best anti-pattern example to that.

  532. Ge0rG

    the new reactions proto-proto-XEP fails miserably as well

  533. Ge0rG

    and then there are things like MUC invitations (direct or mediated)

  534. adityaborikar has left

  535. adityaborikar has joined

  536. ralphm

    I haven't read that yet, but reactions should be annotations. A body might be tricky. I'm not sure how to refer to a previous message in plain text in a way that a user could understand.

  537. waqas has joined

  538. Ge0rG

    ralphm: https://github.com/jabbercat/jabbercat/issues/80#issue-304305375

  539. ralphm

    In case a body cannot convey a certain extension, maybe it could say something to that effect.

  540. Ge0rG

    I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo

  541. ralphm

    'You are invited to a chat room, but your client doesn't support this mechanism. [link-to-faq-page].

  542. ralphm

    See, literally the same thing.

  543. debacle has left

  544. ralphm

    (oh, and a closing ')

  545. Ge0rG

    ralphm: technically, an OMEMO client could insert actual text into the <body> of an OMEMO message, and it would remain unnoticed by OMEMO clients.

  546. pdurbin has joined

  547. Ge0rG

    https://xmpp.org/extensions/xep-0384.html doesn't mandate that the <body> must be throw-away content

  548. Ge0rG

    > If the decryption fails, the client MUST silently discard the OMEMO message. If it succeeds, the decrypted contents are treated as the <body> of the received message.

  549. ralphm

    Given that it is not Final, there's some room still :-D

  550. Ge0rG

    So I could troll OMEMO-enabled clients by adding a broken <encrypted xmlns='eu.siacs.conversations.axolotl'> element into all my messages.

  551. debacle has joined

  552. Lance has left

  553. ralphm

    There are so many ways to troll clients. Again, social problems.

  554. Ge0rG

    ralphm: I'm pretty sure that XEP won't move forward in the current state ;)

  555. Ge0rG

    when designing the receiving side of things, I need to make a deliberate decision on throwing away the <body>

  556. Ge0rG

    I suppose I'm way too deep in nitpicking mode.

  557. adityaborikar has left

  558. adityaborikar has joined

  559. ralphm

    :-)

  560. ralphm

    :-)

  561. pdurbin has left

  562. ziggys has joined

  563. lnj has left

  564. lnj has joined

  565. adityaborikar has left

  566. adityaborikar has joined

  567. Lance has joined

  568. curen has left

  569. nyco

    minutes sent

  570. nyco

    poll sent

  571. Ge0rG

    can I vote now? :D

  572. Lance

    MattJ: hats ping

  573. nyco

    Ge0rG only once! :)

  574. Ge0rG

    only once per split identity.

  575. nyco

    ah, this...

  576. nyco

    if these people are many contributors, then yes

  577. Ge0rG

    nyco: you forgot to add the "would you use it?" to the poll.

  578. nyco

    second page

  579. nyco

    2) If you run an XMPP project, would you use those badges? (website, repo, doc, flyer, poster, etc.)

  580. Ge0rG

    👍

  581. sezuan has left

  582. eevvoor has joined

  583. adityaborikar has left

  584. adityaborikar has joined

  585. UsL has left

  586. goffi has left

  587. UsL has joined

  588. lovetox has joined

  589. Chobbes has left

  590. Chobbes has joined

  591. Chobbes has left

  592. Chobbes has joined

  593. igoose has left

  594. igoose has joined

  595. debacle has left

  596. valo has left

  597. valo has joined

  598. igoose has left

  599. UsL has left

  600. pdurbin has joined

  601. igoose has joined

  602. waqas has left

  603. pdurbin has left

  604. jjrh has left

  605. Nekit has left

  606. moparisthebest

    jonas’: > The initiating party MUST NOT perform A/AAAA fallback as per &rfc6120; (since the service provider has already indicated that the SRV protocol is supported).

  607. david has left

  608. david has joined

  609. moparisthebest

    eh, I know what 6120 says but I can't agree with that here

  610. moparisthebest

    it's trivial for an evil attacker to insert a DNS record that tells a client/server not to fallback

  611. moparisthebest

    I see no harm in falling back anyway if you are doing TLS, does anyone?

  612. moparisthebest

    (sorry for ENOCONTEXT referencing https://github.com/xsf/xeps/pull/796/files )

  613. Nekit has joined

  614. moparisthebest

    the other bit, trying regular _xmpp-client/_xmpp-server seems fine though

  615. UsL has joined

  616. rion

    about improving SIMS... I believe Jingle Session Publishing xep should take some features from Jingle Message Initiation then it will fit well to SIMS. Like.. 1. I'm sending SIMS with published Jingle session 2. a party discovers details of the published Jingle session and if it's compatible sends a *message* (not iq) with <start> 3. the message is carbonned and my other resources not having the file from SIMS just ignore the message (or maybe just record it happened) 4. my resource which has the file sends <starting> via message to a party resource so other my resources know I'm sending a file and also know where from 5. a party initiates jingle session with file request to specific resource (where <starting> came from)

  617. ralphm

    moparisthebest: I wrote this elsewhere before, but I disagree, too. See also RFC 2782. We should totally have a fallback, so the service name should be registered with IANA with a port number.

  618. ralphm

    Elsewhere being the mailing list

  619. moparisthebest

    yep I see that in the email chain now ralphm

  620. ralphm

    rion: could you send a mail on this, with maybe some example protocol exchange?

  621. moparisthebest

    I vaguely recall conversations daniel talking about falling back to 443, clearly we can't register that with IANA though

  622. ralphm

    rion: It is a bit hard to wrap my head around it.

  623. moparisthebest

    I actually don't mind either way if the XEP recommends to fallback and/or a port, I just strongly disagree with "MUST NOT fallback"

  624. neshtaxmpp has left

  625. rion

    ralphm: yep. a little bit later. need to finish some regular work stuff first :)

  626. ralphm

    moparisthebest: I think that's not a great idea. However, one could use port 443 as an SRV target port.

  627. ralphm

    rion: 👍

  628. ralphm

    moparisthebest: right, I think we should prevent doing something special. I'd like to use existing generic SRV handlers.

  629. UsL has left

  630. moparisthebest

    especially when it's only downsides, basically just allowing a network MITM to keep you disconnected when there is a chance you could connect

  631. jonas’

    moparisthebest, an evil attacker can also insert a broken A/AAAA record

  632. jonas’

    if you assume that DNS can be meddled with, all bets are off

  633. moparisthebest

    right, should probably fallback then too

  634. jonas’

    fall back to what?

  635. moparisthebest

    everything you can

  636. jonas’

    there is nothing to fall back if your attacker spoofs A/AAAA

  637. jonas’

    you just end up with broken TLS, hopefully

  638. moparisthebest

    ah sorry I read that as 'broken SRV record' but yea

  639. ralphm

    jonas’: I don't think it is useful to think about spoofing DNS in this context.

  640. jonas’

    ralphm, indeed

  641. ralphm

    But following the RFC on SRV records seems sensible.

  642. moparisthebest

    I think it is though, you can't get around everything an evil mitm could do of course, but maybe you can get around some of them, and there is no reason to give up early

  643. Zash

    ralphm: So does that mean the "fetch both _xmpp and _xmpps SRV and merge the results" is undesirable?

  644. ralphm

    Yes

  645. Zash

    I tend to agree

  646. moparisthebest

    that is optional though

  647. jonas’

    moparisthebest, initiating connections the domain owner clearly did not intend you to do is probably not a good idea

  648. jonas’

    and this is what you’re doing in this case

  649. jonas’

    the endpoint you end up connecting to may easily be a hacked webserver for the same domain

  650. jonas’

    it may be in an entirely different trust domain. just don’t do things the domain owner asked you specifically not to do by placing SRV records.

  651. moparisthebest

    you have no guarantees that the SRV record came from the domain owner though

  652. moparisthebest

    unless DNSSEC, I'm fine with a MUST NOT if you've validated it with DNSSEC

  653. jonas’

    17:29:06 ralphm> jonas’: I don't think it is useful to think about spoofing DNS in this context.

  654. jonas’

    moparisthebest, ^

  655. jonas’

    if the attacker can spoof the SRV record, they can also spoof the A/AAAA you want to fall back to. it’s pointless.

  656. moparisthebest

    and I disagree with that :)

  657. jonas’

    what you propose does not help against an active DNS attacker, and it makes the situation worse in a non-attacked situation.

  658. moparisthebest

    because some attacker might just spoof the SRV record and not A/AAAA, or you might be getting A/AAAA over tor because that only supports them and not SRV

  659. jonas’

    (or in a situation where the attacker has control over a specific machine (A/AAAA), but not over DNS)

  660. moparisthebest

    or a million other reasons

  661. goffi has joined

  662. jonas’

    moparisthebest, if you’re connecting via a transport which does not support SRV, then obviously XEP-0386 does not apply to you

  663. Zash

    Don't worry, be happy. Make sure you validate the TLS certificate.

  664. moparisthebest

    if domain owner is running a public web server that will be hurt by attempting a funky connection to it, they need to fix that

  665. jonas’

    and neither does the SRV RFC or the parts about SRV in RFC 6120

  666. jonas’

    moparisthebest, it may not be *hurt*, but it may easily log things to plaintext logs which you (as the client/user) wouldn’t want to have there. think pipelining authentication because you "know" the domain already.

  667. igoose has left

  668. moparisthebest

    SRV RFC is more generic, it doesn't know we have a foolproof way of validating the port we connect to by guessing

  669. Zash

    validating ... by guessing

  670. moparisthebest

    we guess the port

  671. Nekit has left

  672. jonas’

    what?

  673. moparisthebest

    we have a foolproof way of validating whether it was correct or not, TLS certs

  674. jonas’

    no, that’s not foolproof

  675. jonas’

    the webserver or whatever on the A/AAAA record *will* have a TLS cert for *exactly* the domain

  676. Nekit has joined

  677. jonas’

    so you’re on the wrong port, but still connected and TLS says everything’s green

  678. moparisthebest

    right, and that's fine

  679. jonas’

    no it’s not

  680. Zash

    400 WHAT ARE THESE ANGLE BRACKETS Connection: gtfo

  681. Zash

    I still think guessing is stupid

  682. jonas’

    guessing is stupid and dangerous

  683. moparisthebest

    it absolutely is, again running a public port on the internet means you are willing to accept whatever garbage anyone throws at you

  684. moparisthebest

    and not only accept, but be happy about it

  685. jonas’

    moparisthebest, yes, and I might log that "garbage" including your SASL PLAIN password into some plaintext files for someone to investigate

  686. neshtaxmpp has joined

  687. jonas’

    which is probably very much not what you want

  688. jonas’

    or alternatively, the webserver may run in a different trust domain and may be owned by an attacker

  689. moparisthebest

    the domain owner is the one that made a decision to give them a cert valid for xmpp, and to run an xmpp and https service on the same domain

  690. moparisthebest

    so the owner already decided all that was fine

  691. jonas’

    not really

  692. jonas’

    they have told you via SRV that you should very much should not connect to that webserver machine for XMPP

  693. jonas’

    anything you do beyond that is your fault

  694. moparisthebest

    again without DNSSEC you can't know that, you can only guess

  695. jonas’

    okay, the discussion has just become a pointless loop

  696. moparisthebest

    bottom line, as a user, I want to connect by any means possible, I certainly don't want to not connect because a network is poorly configured either intentionally or accidentally

  697. moparisthebest

    if I understand correctly, you are saying a domain/server operator might not want certain connections, and while I agree, that's tough shit

  698. Nekit has left

  699. moparisthebest

    you open a public port on the internet you have to be willing to accept anything anyhow at any time, period

  700. Nekit has joined

  701. jjrh has joined

  702. Zash

    so we have the two classic camps "fail early and hard on errors" and "just make it work at an ycost"

  703. Zash

    XML vs HTML

  704. Zash

    etc

  705. moparisthebest

    I dislike being compared to HTML but otherwise sure :D

  706. Nekit has left

  707. goffi has left

  708. igoose has joined

  709. ralphm

    If you want to prevent connections, you can publish an SRV record with . as target

  710. Zash

    Ask Ge0rG how common it still is for devices to not support SRV resolution

  711. ralphm

    Well, if that's true, they are not able to have functional compliant XMPP implementations.

  712. Zash

    I imagine the fault would most likely be in DNS resolvers in cheap routers or something

  713. larma has left

  714. Holger

    Or Tor.

  715. ralphm

    But wait, how does that prevent a client device from doing SRV? Or do you mean routers blocking SRV requests?

  716. Zash

    Blocking or otherwise failing for unknown reasons

  717. moparisthebest

    because a client generally gets their DNS server from DHCP which tells it to use crap router

  718. Holger

    WiFi routers having a built-in caching DNS server that's borked.

  719. ralphm

    Well, I'm not sure if I want to be in the business of catering for such brokenness.

  720. jonas’

    there’s also some firewall appliances which filter SRV away

  721. Zash

    And fallback combined with SRV not being critical for the web or email means nobody notices or fixes them.

  722. moparisthebest

    of course DoX fixes this if you have a hard-coded ip+port for your resolver :D

  723. Holger

    On the public servers I'm involved with, we'd loose >10% of the users by not redirecting 5222 from the A/AAAA target.

  724. goffi has joined

  725. Zash

    Holger: Sounds like what Ge0rG has said about yax.im

  726. ralphm

    Holger: wow. Are those corporate users?

  727. ralphm

    Also, how can you tell.

  728. Holger

    ralphm: I don't think so; as I said, from what I've seen it's mostly crap end-user routers and Tor.

  729. ralphm

    Tor is not on my radar

  730. ralphm

    But how can you tell that users cannot use SRV?

  731. Holger

    ralphm: I just check the percentage of the connections that are redirected from the A/AAAA target.

  732. ralphm

    Oh, you publish a different host in SRV?

  733. Holger

    ralphm: Yes.

  734. ralphm

    I kinda want users to complain to their ISPs.

  735. Holger

    ralphm: Not sure about the Tor/crap-router ratio. But it's definitely not just Tor.

  736. karoshi has left

  737. Holger

    ralphm: Well they'd have to complain to their router manufacturers. At least in the cases I tracked down.

  738. Holger

    (Which was like two or three.)

  739. Holger

    A popular thing in France was/is affected, for example.

  740. moparisthebest

    also just as a data point I have what I'd call a "crap corporate network" and SRV is wide open, but it'll only allow HTTP on 80 and TLS on 443, it checks that it's actually TLS too

  741. larma has joined

  742. goffi has left

  743. goffi has joined

  744. moparisthebest

    and yea it'd be great if people complained to ISP/router manufacturers, in practice though it's just "XMPP sucks I can't even connect"

  745. Lance has left

  746. Seve has left

  747. Vaulor has left

  748. goffi has left

  749. UsL has joined

  750. ralphm

    Holger: in most cases people get routers from their ISP. If not, they have themselves to blame for broken behavior.

  751. waqas has joined

  752. Holger

    True that.

  753. Holger

    Of course neither will stop them from concluding what moparisthebest said. XMPP fails, everything else just works.

  754. Zash

    Can't have nice things

  755. ralphm

    And corporate users, well, should complain to corporate IT. There's no end to stupidity in that area.

  756. Zash

    ENTERPRISE

  757. moparisthebest

    > Star Trek Fan Accidentally Accepts Job Writing "Enterprise Software"

  758. ralphm

    When we worked on Jingle/WebRTC we had some issues with blocked UDP traffic in our office.

  759. moparisthebest

    ralphm, don't worry QUIC should fix that for you in a bit :)

  760. ralphm

    Thus wasting valuable bandwidth for calls between two people in the office.

  761. ralphm

    moparisthebest: I think QUIC has a lot going for it, but no.

  762. moparisthebest

    Zash, I think it's more like "can only have nice things if HTTP wants them first" :D

  763. Zash

    :(

  764. ralphm

    moparisthebest: not in this case, I mean. I definitely would like to see XMPP-over-QUIC.

  765. neshtaxmpp has left

  766. wojtek has joined

  767. ralphm

    And indeed if QUIC would work in the corporate environment, then calls would too, since you can use the same port for TURN/STUN.

  768. moparisthebest

    I mainly meant users will complain if websites quit working, so as websites migrate to http3/udp and break, networks should be fixing that

  769. Lance has joined

  770. debacle has joined

  771. ralphm

    I think websites will fallback to plain http for a long time

  772. rion

    QUIC+WebRTC ? I though wg abandoned this idea because all the id remapping crap for compatibility with STUN and absence of signalling ideas.

  773. rion

    thought*

  774. ralphm

    Sure, but I believe even without changes, it can still be done.

  775. ralphm

    Especially with XMPP, as hey, we have signaling.

  776. ralphm

    The conflict is with TURN mostly

  777. wojtek has left

  778. eevvoor has left

  779. frainz has left

  780. frainz has joined

  781. ralphm

    I am a bit surprised one of the arguments is that TURN is rarely used with WebRTC, though. TURN was considered a significant requirement when we were building calls in the VEON app.

  782. Lance has left

  783. ralphm

    But that's not on websites, so who cares? Right, fippo?

  784. frainz has left

  785. igoose has left

  786. frainz has joined

  787. adityaborikar has left

  788. pdurbin has joined

  789. frainz has left

  790. frainz has joined

  791. igoose has joined

  792. igoose has left

  793. pdurbin has left

  794. frainz has left

  795. frainz has joined

  796. frainz has left

  797. frainz has joined

  798. Steve Kille has left

  799. rion

    If web browsers could use our signaling out of the box that would be quite interesting.

  800. ralphm

    Hah, well! If I'm right, the webrtc library has roots in libjingle.

  801. ralphm

    Of course with all the XMPP now removed.

  802. Zash

    ralphm: I have heard that as well

  803. ralphm

    Maybe we could say XMPP caused WebRTC to happen.

  804. neshtaxmpp has joined

  805. igoose has joined

  806. UsL has left

  807. frainz has left

  808. frainz has joined

  809. Lance has joined

  810. frainz has left

  811. frainz has joined

  812. tom

    Shouldn't IPv6 fix these issues as well?

  813. frainz has left

  814. tom

    because with IPv6, if setup properly every computer on then network get's it's own unique publicly routable IPv6 address

  815. tom

    sometimes every device gets a whole range to itself

  816. jonas’

    > because with IPv6, if setup properly

  817. jonas’

    that’s the catch ;)

  818. tom

    well

  819. jonas’

    but yes, IPv6 will (hopefully) make mayn things easier

  820. jonas’

    but yes, IPv6 will (hopefully) make many things easier

  821. tom

    most corporate enviroments are going to setup PFsense or OpenWRT

  822. tom

    which sets up most of ipv6 for you ounce you give it an upstream

  823. frainz has joined

  824. igoose has left

  825. tom

    we aren't in the dark ages of proprietary router firmware ruling majority anymore, least not for professional space

  826. tom

    too many routers got turned into zombies

  827. jonas’

    ironically, the gateway thing provided by my ISP handles IPv6 just fine

  828. jonas’

    it even supports prefix delegation via DHCPv6

  829. ralphm

    I think your view on the activities or competence of corporate IT departments is extremely optimistic.

  830. tom

    maybe that's just my area

  831. Zash

    PFsense? OpenWRT? NOT ENOUGH ENTERPRISE

  832. frainz has left

  833. tom

    the only place I've really seen something not PacketFilter of NetFilter based is where it's probably not possible to route/firewall without ASICs

  834. jonas’

    ralphm, that, too

  835. tom

    like routing 400+gbps

  836. tom

    where we'd use a switch fabric backplane

  837. tom

    otherwise everything in the office areas flowed threw a PFsense box.

  838. tom

    the 1U unit they sell

  839. ralphm

    You might have been lucky.

  840. frainz has joined

  841. Seve has joined

  842. ralphm

    I've seen IT departments being understaffed, underfunded, outsourced, and misused for setting up teleconferences.

  843. goffi has joined

  844. frainz has left

  845. frainz has joined

  846. Yagiza has left

  847. moparisthebest

    tom, can you tell my corporate IT dept, they use all the proprietary blackboxes, riverbed, telari, cisco, and palo alto

  848. moparisthebest

    and those are just the ones I know about

  849. Vaulor has joined

  850. zach has left

  851. zach has joined

  852. Nekit has joined

  853. Steve Kille has joined

  854. Steve Kille has left

  855. igoose has joined

  856. zach has left

  857. zach has joined

  858. remko has left

  859. frainz has left

  860. frainz has joined

  861. ziggys has left

  862. lovetox_ has joined

  863. lovetox_ has left

  864. frainz has left

  865. frainz has joined

  866. lskdjf has left

  867. lskdjf has joined

  868. igoose has left

  869. goffi has left

  870. lumi has joined

  871. igoose has joined

  872. pep.

    "Ge0rG> Each rich messaging XEP should: - mandate a legacy body format - mandate that the body MUST NOT contain anything else, so that compliant clients can ignore it", I don't want to start a discussion right now (sleep!) but I also don't want to forget about it, so I'll say for now that I'm not sure I like this, and we can come back to it later :)

  873. ralphm

    Dude. I want to sleep.

  874. waqas has left

  875. Ge0rG

    pep.: I'm going to write that to standards in the context of reactions

  876. pep.

    Ok

  877. pep.

    I'll reply to that

  878. ralphm

    https://upload.ik.nu/upload/oQfV7r-1Xd5r9hYF/9XML-6JsSvqz0agHghjWlg.png

  879. pep.

    https://www.xkcd.com/386/

  880. ralphm

    Yes

  881. moparisthebest has left

  882. moparisthebest has joined

  883. Nekit has left

  884. waqas has joined

  885. karoshi has joined

  886. lovetox has left

  887. UsL has joined

  888. mimi89999 has left

  889. mimi89999 has joined

  890. Chobbes has left

  891. moparisthebest has left

  892. adityaborikar has joined

  893. andrey.g has left

  894. Mikaela has left

  895. ziggys has joined

  896. ziggys has left

  897. ziggys has joined

  898. debacle has left

  899. krauq has left

  900. krauq has joined

  901. UsL has left

  902. lumi has left

  903. moparisthebest has joined

  904. lumi has joined

  905. lnj has left

  906. karoshi has left