XSF Discussion - 2018-02-12

  1. jubalh has left
  2. jubalh has joined
  3. remko has joined
  4. Dave Cridland has left
  5. Dave Cridland has joined
  6. Dave Cridland has left
  7. Dave Cridland has joined
  8. lskdjf has joined
  9. la|r|ma has joined
  10. jubalh has joined
  11. jubalh has joined
  12. la|r|ma has left
  13. la|r|ma has joined
  14. Guus has joined
  15. remko has joined
  16. jubalh has left
  17. jubalh has joined
  18. nyco has left
  19. Guus has left
  20. remko has joined
  21. moparisthebest has left
  22. Dave Cridland has left
  23. Dave Cridland has joined
  24. Dave Cridland has left
  25. Dave Cridland has joined
  26. moparisthebest has joined
  27. Zash has left
  28. remko has joined
  29. moparisthebest has left
  30. moparisthebest has joined
  31. efrit has joined
  32. @Alacer has left
  33. @Alacer has joined
  34. remko has joined
  35. lskdjf has joined
  36. lskdjf has joined
  37. Kev has left
  38. lskdjf has joined
  39. lskdjf has left
  40. remko has joined
  41. uc has joined
  42. andy has joined
  43. efrit has left
  44. Guus has joined
  45. remko has joined
  46. SamWhited has left
  47. Guus has left
  48. la|r|ma has joined
  49. lskdjf has joined
  50. Ge0rG has left
  51. andy has left
  52. remko has joined
  53. andy has joined
  54. rion has joined
  55. jubalh has joined
  56. remko has joined
  57. jubalh has joined
  58. Syndace has left
  59. Syndace has joined
  60. jubalh has left
  61. jubalh has joined
  62. jubalh has left
  63. andy has left
  64. jubalh has joined
  65. suzyo has joined
  66. zinid has left
  67. zinid has joined
  68. suzyo has left
  69. jjrh has left
  70. jjrh has left
  71. Guus has joined
  72. Guus has left
  73. Guus has joined
  74. Guus has left
  75. Guus has joined
  76. Seve daniel, Matrix already does that. http://mirror.onet.pl/pub/mirrors/video.fosdem.org/2018/H.1309%20(Van%20Rijn)/matrix_webvr.webm
  77. zinid has left
  78. daniel has left
  79. Guus has left
  80. Guus has joined
  81. Guus has left
  82. Guus has joined
  83. rion looks cool
  84. Guus has left
  85. Guus has joined
  86. suzyo has joined
  87. Guus has left
  88. tux has joined
  89. zinid daniel: Psi gets crazy when it receives muc self-presence, it renders "empty" participant in muc roster
  90. goffi has joined
  91. goffi has joined
  92. rion O_o
  93. lovetox has joined
  94. Tobias has joined
  95. zinid yeah
  96. rion What server should I install to have such a self-presence? ejabberd?
  97. zinid rion, no, it's on local machine
  98. rion in any case last two day I rewrote muc roster. so it won't happen anymore. not commited yet
  99. zinid good
  100. zinid the problem is that now I'm not sure if other clients don't break though
  101. zinid rion, Psi requests MUC vCard on every join?
  102. rion yep
  103. rion I think with self-presence and caps I'll change this too
  104. rion and I have to improve avatars caching for mucs too as well as their requesting algo. otherwise it's a lot of traffic on join.
  105. Tobias has joined
  106. zinid yeah...
  107. lovetox has left
  108. zinid poezio has the same problem wrt avatars 😉
  109. mimi89999 has joined
  110. remko has joined
  111. tim@boese-ban.de has left
  112. nyco has left
  113. Dave Cridland has left
  114. Dave Cridland has left
  115. tim@boese-ban.de has joined
  116. zinid gajim seems doing fine, doesn't render anything strange
  117. Dave Cridland has left
  118. Dave Cridland has left
  119. Dave Cridland has left
  120. Dave Cridland has left
  121. daniel has joined
  122. Dave Cridland has left
  123. Dave Cridland has left
  124. SaltyBones has left
  125. uc has joined
  126. remko has left
  127. remko has joined
  128. bra has joined
  129. zinid has left
  130. zinid has joined
  131. SaltyBones has joined
  132. Steve Kille has left
  133. Steve Kille has joined
  134. Steve Kille has left
  135. jubalh has joined
  136. Dave Cridland has left
  137. Steve Kille has joined
  138. Guus has joined
  139. daniel has left
  140. daniel has left
  141. daniel has left
  142. Guus has left
  143. Guus has joined
  144. Martin has joined
  145. daniel has left
  146. Guus has left
  147. Guus has joined
  148. Guus has left
  149. andy has joined
  150. nyco has left
  151. bra has left
  152. bra has joined
  153. andy has left
  154. Guus has joined
  155. rion has left
  156. rion has left
  157. hannes has joined
  158. rion has left
  159. jubalh has joined
  160. rion has left
  161. rion has left
  162. Zash has joined
  163. @Alacer has left
  164. @Alacer has joined
  165. Guus has left
  166. Guus has joined
  167. jubalh has left
  168. rion has left
  169. rion has left
  170. jubalh has joined
  171. Alex has joined
  172. jubalh has left
  173. ralphm has left
  174. Guus has left
  175. rion has left
  176. jubalh has joined
  177. jubalh has left
  178. jjrh has left
  179. rion has left
  180. daniel has left
  181. Seve By the way, regarding the email I sent to JUser, is there a better mailing list for that, please?
  182. jonasw I still haven’t subscribed to juser :/
  183. Seve That's why I would like to send it somewhere else too, seems not many people are subscribed there
  184. jonasw Seve, I think operators would be more fitting, maybe
  185. rion has left
  186. jonasw possibly with a cross-post to members@
  187. jonasw I’m also not sure if a separate MUC for this is a good idea
  188. Zash Posted something to some KDE list?
  189. rion has left
  190. rion has left
  191. jonasw frankly, I’m not sure XMPP can fulfil the requirements at this instant in time
  192. jonasw > Stickers are available
  193. jonasw we doomed
  194. Zash Find out which are requirements and which are wishlist
  195. jonasw Zash, they don’t even know that yet
  196. rion has left
  197. jonasw > Requirements are not prioritized (incl. must-have vs. nice-to-have), that comes at a later step.
  198. rion has left
  199. Martin has left
  200. jubalh has joined
  201. rion has left
  202. daniel has left
  203. Zash jonasw: All are wishlist. There's online one requirement, that everyone you care about is already using it. :)
  204. andy has joined
  205. tim@boese-ban.de has left
  206. rion has left
  207. Seve jonasw, the point of the MUC is to discuss this topic with people interested in helping out. Almost everybody here would find this discussion annoying here.
  208. jonasw Seve, I’m running out of screen space for more MUCs.
  209. rion has left
  210. rion has joined
  211. tim@boese-ban.de has joined
  212. rion has left
  213. andy has left
  214. marc Ge0rG, jonasw can you review https://git.zapb.de/xeps.git/commit/?h=fix_xep_0401&id=52725e993987f205dc253cc5a4e6937fe3955d81 and merge please?
  215. uc has joined
  216. moparisthebest has joined
  217. jonasw marc, EBUSY right now
  218. jonasw marc, if you refuse to make a github PR (which would really be the most useful thing for me), please send an email with the first line of the commit message as subject to editor@xmpp.org
  219. marc jonasw, I can do a GitHub PR if you like
  220. jonasw marc, that would be much appreciated, thanks
  221. jubalh has left
  222. marc jonasw, you're welcome
  223. jonasw gotta run now, see you
  224. marc bye
  225. Martin has joined
  226. moparisthebest has joined
  227. rion has joined
  228. marc done
  229. Alex has left
  230. jjrh has left
  231. Zash has left
  232. rion has left
  233. rion has joined
  234. rion has left
  235. jubalh has joined
  236. valo has left
  237. valo has joined
  238. jubalh has left
  239. rion has joined
  240. andy has joined
  241. suzyo has joined
  242. Zash has joined
  243. hannes has joined
  244. daniel has left
  245. hannes has joined
  246. remko has left
  247. remko has joined
  248. jubalh has joined
  249. andy has left
  250. jubalh has left
  251. andy has joined
  252. jonasw zinid, regarding the server capabilities invalidation, how about a message?
  253. jonasw server changes caps -> server sends <message/> to local clients. for server-to-server links, it could simply close the link so that the peer re-opens it, thus getting new stream features
  254. Alex has joined
  255. remko has joined
  256. zinid jonasw, closing and opening thousands of s2s will create avalanche effect
  257. jonasw right
  258. zinid we see this on jabber.ru for examlpe
  259. zinid so I just think about nonza
  260. zinid stream-level element
  261. jonasw zinid, thanks for your input, I’ll post a few suggestions to the mailing list and I hope you’ll comment on them :)
  262. zinid sure 😉
  263. suzyo has joined
  264. intosi has left
  265. andy has left
  266. moparisthebest has joined
  267. Dave Cridland has left
  268. moparisthebest has joined
  269. Dave Cridland has left
  270. Dave Cridland has left
  271. SaltyBones Is there a good resource on the problems with message ids?
  272. jonasw zinid, replied, happy to hear from you d)
  273. jonasw zinid, replied, happy to hear from you :)
  274. jonasw SaltyBones, I’m not sure
  275. SaltyBones I'm looking at XEP-0359 but the problems mentioned at the summit are not in there.
  276. jonasw maybe the summit notes as first starting point
  277. hannes has joined
  278. jubalh has joined
  279. andy has joined
  280. jubalh has left
  281. Syndace has left
  282. Syndace has joined
  283. suzyo has joined
  284. SaltyBones 1.2 Stable IDs Discussion on entropy ensues. dwd: <stanza-ids> don't work for unique addressing because we don't trust clients to do them properly. Kev: lots of possible attacks with spoofable stanza IDs.
  285. SaltyBones Not verbose enough.
  286. jonasw SaltyBones, I think the gist of that is: we need to generate stanza IDs on the server because weak/constructed stanza IDs are a problem. but the client needs to know the stanza ID for archive operations and possibly other things
  287. zinid jonasw, well, dunno, for me message looks too complex
  288. Martin has left
  289. zinid can't we just send <c/> as a nonza?
  290. jonasw zinid, I think RFC 6120 would slap you in the face for that ;-)
  291. jonasw really, it needs negotiation
  292. jonasw it’s a shame that we have no way for a client to send stream features :(
  293. zinid yeah, because some implementation may close a stream if they receive unrecognized nonzas
  294. jonasw yupp
  295. jonasw I know at least one.
  296. zinid however, I tried to implement such behaviour (closing a stream) and got lots of problems and left the idea
  297. jonasw never had issues so far; did you encounter things which sent unsolicited nonzas?
  298. zinid alas, I've already forgotten what that was exactly 😕
  299. jonasw zinid, the best we could do is probably say "okay, if the client sent a presence update with caps, we can send a nonza with a caps update"
  300. jonasw and similarly for servers ("offered caps in stream feature -> send nonza")
  301. jonasw but I don’t know enough about s2s to be sure that this works
  302. jonasw this would definitely need a namespace bump though
  303. zinid well, we're talking about new caps xep?
  304. zinid we can do it there
  305. jonasw yeah, it requires a namespace bump there too ;-)
  306. zinid can't we just negotiate this feature?
  307. Dave Cridland has left
  308. zinid not sure how
  309. jonasw negotiation will add a round-trip
  310. jonasw which people will react very adversely to
  311. zinid ah
  312. jonasw but please comment on-list, hoping to get more input on that
  313. zinid I don't know what to say
  314. Dave Cridland has left
  315. jonasw what you said here, essentially?
  316. la|r|ma has joined
  317. lskdjf has joined
  318. andy has left
  319. Dave Cridland has left
  320. remko has joined
  321. Dave Cridland has left
  322. Dave Cridland has left
  323. Dave Cridland has left
  324. Dave Cridland has left
  325. Dave Cridland has left
  326. Dave Cridland has left
  327. Dave Cridland has left
  328. SaltyBones There are stanza-id and origin-id in XEP-0359. Somebody at the summit also mentioned "message-id" is that defined somewhere?
  329. MattJ They were probably referring to the id attribute, I guess?
  330. Dave Cridland has left
  331. SaltyBones MattJ, this https://tools.ietf.org/html/rfc6120#section-8.1.3 ?
  332. MattJ Yes
  333. SaltyBones thx
  334. MattJ The reason XEP-0359 exists is because the id attribute is controlled (and can only be trusted by) the original sender of the stanza
  335. MattJ It's really just designed for tracking errors, though a couple of XEPs have re-used it for other purposes
  336. Dave Cridland has left
  337. suzyo has joined
  338. Martin has joined
  339. Dave Cridland has left
  340. suzyo has joined
  341. remko has joined
  342. Dave Cridland has left
  343. SaltyBones The id-attribute you mean?
  344. jonasw yes
  345. SaltyBones So, I guess, stanza-id is used by MAM and origin-id is used to detect MUC reflections (that's what 0359 says anyway). And id-attribute is used for errors but the error will have the same id-attribute iiuc, right?
  346. jonasw yes, pretty much
  347. jonasw except that origin-id won’t work with all MUCs
  348. SaltyBones Why?
  349. andy has joined
  350. jonasw because not all MUCs may be able to reflect that ID for whatever implementation specific reason
  351. jonasw (just like not all mucs can reflect the message @id)
  352. Zash has left
  353. MattJ There is only one implementation I'm aware of that doesn't (didn't?) reflect @id, and I'm not even sure of the current status of that
  354. SaltyBones Okay, so why does the standard not just mandate that it be reflected?
  355. MattJ Simple oversight I suspect
  356. Dave Cridland SaltyBones, Non-MUC things pretending to be MUC, in part.
  357. Dave Cridland SaltyBones, Also by the time people had noticed this was a problem, enough implementations didn't.
  358. SaltyBones So, could this be fixed by changing the standard and requiring that origin-ids be reflected?
  359. Dave Cridland has left
  360. SaltyBones Dave Cridland, what do you mean by "non-muc things pretending to be muc"?
  361. jonasw SaltyBones, changing the standard doesn’t fix the implementations magically
  362. MattJ Dave Cridland, enough = 1? Also in the case of bridging to non-MUC, isn't it as simple as 1) if the non-MUC supports acks, wait for the ack and reflect the id or 2) reflect the id immediately?
  363. jonasw SaltyBones, IRC transports are "non-muc things pretending to be MUC" for example
  364. SaltyBones jonasw, not magically but ...
  365. Dave Cridland MattJ, More than one, I think. One classic MUC implementation, but quite a few transports.
  366. uc has joined
  367. Dave Cridland FWIW, I've gone back and forth over whether MUC ought to reflect ids. It's a special case of maintaining the id on bradcast, which is itself both useful in some cases and bad in others.
  368. SaltyBones Why is this reflection necessary?
  369. Dave Cridland SaltyBones, Reflection isn't - we could add in a subelement which indicated the original id.
  370. Dave Cridland SaltyBones, Broadcast ids are harder to work around - there's a few protocols which use id as reference.
  371. Dave Cridland This all said I *really* dislike having a zillion ids as subelements of stanzas when we already have an id attribute.
  372. Kev has left
  373. SaltyBones Well, what is the subelement necessary for? Is this just as an ACK to the client?
  374. SaltyBones What do you mean by broadcast-id?
  375. Dave Cridland has left
  376. MattJ SaltyBones, if you're asking why MUC reflects messages to the sender in the first place (some systems, e.g. IRC don't) - it has a few benefits
  377. MattJ Such as ensuring everyone in the room sees the same messages in the same order
  378. jonasw it also is natural as soon as multiple clients are in the play, somewhat like message carbons
  379. Dave Cridland SaltyBones, So the id attribute in the message stanza for a groupchat message sent to the MUC can be reused in the reflected message, and/or the broadcast messages to other participants in the group.
  380. MattJ In IRC if two people send a message at the "same time", the messages will be shown in a different order on both their clients
  381. MattJ and yes, multiple clients from one user in the room
  382. jonasw it allows MUCs to do fancy things to messages and still have everyone see the same thing
  383. Dave Cridland (As a side-note, Matrix achieves a similar goal by a complex hash chain)
  384. andy has left
  385. MattJ SaltyBones, and also servers modifying messages (e.g. in the Prosody MUC we automatically convert long multi-line messages to a pastebin link). The reflection allows the sending client to see what everyone else sees.
  386. remko has joined
  387. andy has joined
  388. jonasw (in contrast to IRC, where you don’t see that your message was truncated)
  389. SaltyBones Okay, pretty convincing...
  390. MattJ Dave Cridland, and as many people at FOSDEM noted, much RAM
  391. Dave Cridland MattJ, Yes but BLOCKCHAIN.
  392. jonasw #bingo #triggered
  393. SaltyBones 🔲‍⛓️
  394. Dave Cridland I hope there's a ZWJ there.
  395. moparisthebest has joined
  396. SaltyBones *Yes, there is.*
  397. Dave Cridland has left
  398. SaltyBones Okay, so we want reflected messages. Sounds fair. Let's suppose for a second that we can just make them mandatory in the standard and people would add them.
  399. jonasw they *are* mandatory
  400. jonasw the issue is with message IDs
  401. jonasw clients need to be able to recognize the reflection
  402. SaltyBones You mean id-attribute?
  403. jonasw or any ID really
  404. jonasw id attribute would be easiest
  405. Dave Cridland We could indicate in disco if ids were stable.
  406. andy has left
  407. jonasw wasn’t that proposal rejected-ish?
  408. SaltyBones Okay, 1. is the origin-id used for anything else and 2. is the whole point of origin-id not to detect reflection?
  409. moparisthebest has joined
  410. jonasw speaking of MUC, I think the vote on https://github.com/xsf/xeps/pull/559 expired, didn’t it?
  411. Ge0rG I've attemtped to fix MUC reflected IDs some years back, not even in the normative language but merely by fixing the examples
  412. Ge0rG And got significant flack for it.
  413. Ge0rG I also attempted to make origin-id == message-id, but it was refused by the XEP author.
  414. SaltyBones groans.
  415. Ge0rG Now I'll just sit and wait, and ocassionaly proclaim: *I told you so!*
  416. SaltyBones So, is the point of origin-id to be used for reflection or is there something else?
  417. Flow SaltyBones, that is one use case
  418. lumi has joined
  419. SaltyBones Ge0rG, great, if you could also occasionally chime in with reasons for things and explanations that would be awesome.
  420. SaltyBones Flow, like?
  421. Ge0rG SaltyBones: it's mainly for reflection, except that MUCs are not guaranteed to keep non-body elements in the reflection
  422. Flow other use cases include finding your own messages in a archive
  423. Ge0rG SaltyBones: https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Matching_Your_Reflected_Message
  424. SaltyBones Flow, MAM uses stanza-id, right?
  425. Flow SaltyBones, it does
  426. Ge0rG SaltyBones: yes, but you don't know the stanza-id for the messages you sent
  427. SaltyBones Ge0rG, would you say this is a requirement by nature or just a problem with implementations?
  428. daniel i agree that the xep should specify that the sender should set origin-id=message-id
  429. Ge0rG SaltyBones: what?
  430. Ge0rG daniel: MUST set.
  431. SaltyBones Ge0rG, the fact that MUCs don't reflect non-body attributes.
  432. daniel yes
  433. Ge0rG because anything different is just a path into insanity
  434. daniel (i didn't mean SHOULD)
  435. SaltyBones Ge0rG, also, why do I need the stanza-id for a message I sent?
  436. Ge0rG SaltyBones: have a look at biboumi, a modern IRC transport. It doesn't reflect your message ID, it doesn't reflect any non-body elements and it mangles multi-line messages
  437. Ge0rG Welcome to message tracking hell.
  438. daniel i think thinks will already break if some client doesn't do that and then expects a delivery reciept or something
  439. Ge0rG SaltyBones: because when you ask for a MAM sync, you'll get yout sent messages copied to you as well
  440. daniel when sending messages to Conversations i mean
  441. Ge0rG Yes, message correction, delivery receipts and anything else that references IDs is a mess already.
  442. SaltyBones Ge0rG, and why is that a problem? They should have their origin-id and be recognizable, right?
  443. Ge0rG SaltyBones: you can't rely on origin-id being there, and you can't rely on it matching the message-id.
  444. SaltyBones daniel, what breaks when a client does what?
  445. Ge0rG SaltyBones: but yes, you can match MAM archives based on origin-id
  446. daniel if an origin id is set Conversations will use that as a reference in the receipt
  447. daniel so if your client doesn't do id=origin-id and expects the receipt for the id it won't work
  448. daniel same with everything else that references ids
  449. SaltyBones So, there seems to be consensus at least in this MUC right now that attribute-id should be the same as origin-id?
  450. daniel i'd argue there is no good reason not do make this a MUST
  451. daniel i mean most client would naturally do this anyway
  452. SaltyBones Ge0rG, who was the xep-author who was against this and do you remember why?
  453. jonasw SaltyBones, Flow
  454. daniel because why would you generate a second id if you can reuse the existing one
  455. zinid Who is generating origin-id? A client?
  456. Ge0rG SaltyBones: https://mail.jabber.org/pipermail/standards/2017-September/033415.html
  457. jonasw zinid, the original sender
  458. daniel zinid, yes
  459. jonasw i.e. most of the times a client
  460. jubalh has joined
  461. daniel note that muc rewrites a irrelevant to the scenerio described above
  462. Dave Cridland jonasw, #559 expired, yes.
  463. zinid This is to track its own messages?
  464. daniel zinid, yes
  465. daniel or references to that
  466. Dave Cridland jonasw, But with no veto and the rest are +1, so apply it.
  467. Dave Cridland has left
  468. SaltyBones jonasw, what is this ID-rewriting MUC shit? :)
  469. daniel some mucs are known to change the 'attribute' id
  470. Ge0rG SaltyBones: have a look at examples 44 and 45 in https://xmpp.org/extensions/xep-0045.html#message
  471. daniel so tracking your own message are parsing references don't work
  472. zinid daniel: why, you can rely on origin-id in this case
  473. Ge0rG If we have a MUC that rewrites message IDs, can we mandate that it also MUST rewrite references in all XEP payloads that reference message IDs, please?
  474. Ge0rG zinid: https://wiki.xmpp.org/web/XEP-Remarks/XEP-0045:_Multi-User_Chat#Matching_Your_Reflected_Message
  475. daniel zinid, in the case of muc? because most mucs won't remove child elements from the stanza
  476. zinid I'm lost
  477. zinid daniel: but that's exactly what's needed
  478. daniel now i'm lost :-)
  479. zinid So you can fetch origin-id and check if this is your id
  480. Kev has joined
  481. jjrh has left
  482. zinid Why do you need to rely on message-id if you inject origin-id
  483. daniel i just said the sender should set id=origin-id
  484. SaltyBones zinid, I think there was a sub-discussion about forcing message-id = origin-id
  485. daniel and/or deal with delivery receipts that reference the origin-id instead of the id
  486. daniel which is made easier if you id=origin-id
  487. zinid Ok, I don't get it 🤔
  488. daniel doesn't matter. that client to client stuff anyway :-)
  489. la|r|ma has left
  490. la|r|ma has joined
  491. remko has joined
  492. zinid From what I understand we just need to ditch IRC transports
  493. zinid 😃
  494. jjrh has left
  495. zinid That's really their problem
  496. daniel oh yeah. or make irc transports track the messages themselves and re-add origin-id and stuff on reflection
  497. daniel it's probably better if the irc transport does the right thing(tm) than letting each and every client figure it out
  498. zinid daniel: agreed, nobody said writing transport is simple
  499. daniel irc transport should also reassemble the message if they previously split it and stuff like that
  500. daniel because they know best if they did
  501. SaltyBones Hm.
  502. SaltyBones Okay, are there any actual problems with the current state of three IDs except that we don't like having so many?
  503. daniel yes
  504. daniel read what i said before
  505. SaltyBones Uh, assuming a well-behaved server?
  506. daniel yes
  507. daniel my argumentation has nothing to do with servers
  508. jonasw daniel, IRC doesn’t even reflect
  509. jonasw so the transport generates the reflections on its own
  510. SaltyBones Okay, can you please point out what you are referring to then?
  511. jonasw biboumi however decided to reflect the split version of the message, and there’s some argument to doing that
  512. daniel assume i sent: <message id="1"><body>hi</body><request/><origin-id="2"></message> and then i will receive from conversations: <message><receipt id="2"></message>
  513. zinid who cares about IRC, really, are we designing a protocol for old nerds?
  514. daniel but we are talking about two different things. the how should irc transports behave has noting to do with the problem i'm describing
  515. daniel this applies to 1:1 chats as well
  516. jonasw daniel, yes, I don’t argue that
  517. jonasw I’m just replying to your message from "13:49:15Z" because I was away from keyboard.
  518. remko has left
  519. daniel the irc transport with the name i can not pronounce or remember does a few things that i don't like :-)
  520. zinid daniel: if we don't care about IRC then we probably don't need origin-id and thus there is no the problem you just described
  521. daniel there are non transport mucs which also rewrite the id
  522. Ge0rG daniel: https://lab.louiz.org/louiz/biboumi/issues/3283
  523. daniel zinid, if it weren't only for transports i wouldn't care
  524. daniel Ge0rG, is that an issue to change the name to something i can remember?
  525. daniel or pronounce?
  526. zinid daniel: if they are abandoned, then I personally give zero fucks
  527. Ge0rG daniel: no, it's about maintaining IDs on reflection
  528. Ge0rG zinid: everything in XMPP is abandoned. Now stop giving fucks.
  529. daniel i should probably write my own irc transport
  530. edhelas biboumi is not good ?
  531. Ge0rG daniel: you should just patch biboumis two or three warts.
  532. daniel i haven't used irc though ever since counterstrike 1.6 came out
  533. zinid Ge0rG: not everything, so I still have a few fucks to give
  534. daniel there are a number of things i don't like that seem to be design decisions rather than bugs
  535. andy has joined
  536. daniel so i'm not sure if they even want me to change them
  537. SaltyBones daniel, so regarding your example, what you are saying is that the read receipt might reference the message-id or the origin-id and it is not properly specified which?
  538. zinid Ok, whatever, so what do you guys think about muc subscriptions?
  539. SaltyBones Or are you getting at the fact that origin-id requires "by=" and is therefore sometimes not applicable?
  540. daniel > daniel, so regarding your example, what you are saying is that the read receipt might reference the message-id or the origin-id and it is not properly specified which? This
  541. daniel not just read recepits but everything that references something
  542. daniel but yes
  543. jubalh has joined
  544. zinid daniel: isn't there a place in the xep which says you should copy the message-id?
  545. daniel zinid, no.
  546. zinid Really?
  547. daniel that's what Ge0rG and I want to add to the XEP
  548. daniel that's pretty much what the entire discussion is about :-)
  549. zinid So add it 😀
  550. daniel i can't without permission of the author
  551. zinid No shit?
  552. SaltyBones So, there is some problem that I am still not aware of....
  553. SaltyBones Flow, why is the by attribute in the origin-id?
  554. zinid Who's the author?
  555. SaltyBones The one that causes the privacy problems...
  556. Kev Not entirely true, BTW, that it's impossible to do things without the author. But it's the path of least resistance.
  557. daniel i don't think there is a by attribute in the origin id
  558. SaltyBones Ah, sorry that is only for stanza IDs. origin-id does not have by.
  559. zinid Peter is the author
  560. SaltyBones That might almost always be correct buy 0359 is Florian Schmaus
  561. SaltyBones That might almost always be correct but 0359 is Florian Schmaus
  562. zinid > In addition, it SHOULD include an 'id' attribute that echoes the 'id' attribute of the content message.
  563. zinid And you want this SHOULD to be a MUST?
  564. lskdjf has joined
  565. SaltyBones zinid, what some people here want is that origin-id = message-id
  566. SaltyBones Ge0rG, you had an objection to that in https://mail.jabber.org/pipermail/standards/2017-September/033415.html but I don't quite understand it. Why do you want to know if somebody creates strong message-id?
  567. zinid SaltyBones: but the sender controls this itself, so what is a problem to set them equal?
  568. daniel zinid, we want wording that tells the client developer to do this
  569. daniel there is no 'problem'
  570. efrit has joined
  571. Ge0rG SaltyBones: I thought it would matter, but it doesn't, because there always can be malicious entities
  572. zinid daniel: if they don't then they only harm themselves, I guess
  573. Ge0rG zinid: no, they harm the other participants
  574. zinid Ge0rG: ah
  575. SaltyBones How?
  576. zinid Yeah, how?
  577. Ge0rG zinid: also, it's well possible that stanza ids are generated by the xmpp library, and origin ids by the client, causing a mismatch
  578. Ge0rG By making all message references break
  579. Ge0rG We had that above already.
  580. SaltyBones Before we move to stanza-ids....
  581. SaltyBones There is nothing wrong with requiring origin-id = message-id?
  582. Martin has left
  583. zinid If we require this then why origin-id is needed, wtf?
  584. SaltyBones zinid, it's possible that it was a mistake
  585. SaltyBones daniel, does requiring origin-id = message-id actually solve your problem or are there cases when stanza-id might be used to refer to a message instead??
  586. daniel It solves my problem
  587. andy has left
  588. andy has joined
  589. SaltyBones daniel, wouldn't it be better to just mandate that clients always use the origin-id to avoid the problem of dealing with id-rewriting MUCs?
  590. SaltyBones I mean, certainly removing an unnecessary id would also be desirable but this might be a good intermediate step.
  591. Martin has joined
  592. SaltyBones Would everything be better if clients would generate proper stanza-ids?
  593. SaltyBones For ...uh...some definition of proper that makes them UUIDish.
  594. zinid they should be strictly monotonically increasing, so we don't need XEP-0198
  595. SaltyBones And by "would everything be better" I specifically also mean, wouldn't that allow us to ditch the other IDs?
  596. zinid and not UUIDs
  597. jonasw zinid, "strictly monotonically increasing" is not gonna happen
  598. zinid because?
  599. SaltyBones zinid, would increasing IDs really solve all the same problems as stream management? Seems unlikely?
  600. jonasw zinid, also, increasing IDs have security implications
  601. jonasw or rather: predictable IDs
  602. zinid SaltyBones, it solves in data replication, but of course XMPP is too unique
  603. zinid version vectors are based on such ids
  604. zinid jonasw, what security implications?
  605. jubalh has left
  606. jonasw zinid, I think there were some IQ response injection attacks based on predictable IDs
  607. jonasw even though in that case you probably already made the mistake of not verifying the sender of the response
  608. jonasw error injections would most likely work though because errors can come from entities different than the original recipient
  609. zinid jonasw, this can be fixed by adding routing information
  610. SaltyBones jonasw, maybe this is too much of an assumption for all of XMPP but don't we have transport encryption?
  611. zinid we anyway need this functionality already
  612. jonasw SaltyBones, that doesn’t stop me (jonas@zombofant.net) from sending an iq type="error" id="whateverIguessed" to="you" to break whatever you were doing
  613. SaltyBones zinid, I agree, if this is a problem I don't see why it cannot be exploited right now by somebody who randomly sees the message first
  614. jonasw SaltyBones, if I can guess the ID, I can attack you from off-path
  615. jonasw I can’t do that when I can’t guess the ID
  616. jonasw if I’m on path, you’re right, everything is lost already in XMPP.
  617. zinid but if you cannot match incoming errors against requests you sent then you should really consider to change the job
  618. jonasw zinid, how’d you match incoming errors against requests other than the ID?
  619. jonasw you can’t really use from, because as I said, it might come from an entity you didn’t know about yet
  620. MattJ jonasw, no?
  621. zinid jonasw, you can use (from, ID) I think
  622. MattJ errors come from the original recipient that you addressed
  623. jonasw MattJ, even if an s2s error causes an error?
  624. MattJ Yes
  625. jonasw oh okay
  626. MattJ Otherwise it would be a nightmare
  627. Dave Cridland jonasw, There's a "by" attribute, if I remember right, that tells you the generator/reporter of the error.
  628. Dave Cridland has left
  629. SaltyBones So, I assume that if I run a h4xx0r server and try to send replies to messages that were not directed to me to some other server they will be discarded?
  630. SaltyBones And the same happens between client and server...?
  631. MattJ SaltyBones, by "replies", you mean error replies?
  632. SaltyBones Whatever magical interferring replies that jonasw was referring to :)
  633. SaltyBones yes, errors ;)
  634. MattJ For that to work you would have to know the original sent message id, and the original sender's full JID
  635. SaltyBones But if I did, I could?
  636. MattJ and then yes, you could send them whatever you wanted - it would be up to their client to match it up (or not) to one of its outgoing messages
  637. SaltyBones So, the statement that predictable IDs would allow me to spoof responses remains correct?
  638. MattJ so as said above, the client should use (from, id) to identify error responses, not just the id
  639. SaltyBones Because I cannot spoof "from"?
  640. MattJ Correct
  641. SaltyBones Yes, okay...
  642. SaltyBones That's what I was looking for. :)
  643. remko has joined
  644. MattJ id "abc123" from userA@domainA is different from "abc123" from userB@domainB
  645. SaltyBones And servers only accept s2s with from=...@domainA if they know that the other server is in charge of domainA?
  646. Dave Cridland SaltyBones, That's what they're supposed to do, yes.
  647. remko has left
  648. SaltyBones ^^
  649. MattJ SaltyBones, yes, they do
  650. Dave Cridland MattJ, No, they don't, but I love your optimism.
  651. MattJ If they don't, it's a bad bug or not an XMPP server
  652. Dave Cridland SaltyBones, So Metre (my S2S proxy mad thing) does this very strictly, and as a result I can't join this chatroom from my personal server.
  653. Dave Cridland SaltyBones, Not sure if MattJ is saying that's a bad bug in this server, or if he's saying it's not an XMPP server. :-)
  654. MattJ Dave Cridland, for what reason?
  655. jubalh has left
  656. andy has left
  657. SaltyBones Dave Cridland, so which messages do you get that don't pass?
  658. Alex has left
  659. SaltyBones Bunneh, version xmpp.org
  660. Bunneh SaltyBones: xmpp.org is running Prosody version 0.9.12 on Linux
  661. Dave Cridland MattJ, It's sending a response down the stream obtained by reversing the stream to/from, and not by reversing the stanza to/from. I forget the details, Zash knows.
  662. Dave Cridland MattJ, I don't know if Prosody would accept that or not. Metre doesn't, Openfire does (but because it knows it's multiplexed on the outbound, so weirdness.)
  663. Dave Cridland MattJ, For maximum fun, Openfire used to do similar "implicit" auth on outbound, but I stopped that as from 4.2.0.
  664. MattJ I don't really understand, but maybe Zash will enlighten me
  665. Dave Cridland MattJ, Metre sends traffic for d.c.n -> muc.xmpp.org over a stream for d.c.n -> xmpp.org (after adding that domain via dialback).
  666. Zash How far back should I read to have any idea what you are talking about?
  667. SaltyBones 15:58 should suffice
  668. MattJ SaltyBones, and a time machine
  669. Dave Cridland MattJ, Prosody (0.9) responds to the traffic on the reverse stream, xmpp.org -> d.c.n - which it hasn't requested authorization for yet.
  670. SaltyBones Do you mean a timezone machine or a MAM machine?
  671. Alex has left
  672. Zash No MAM here
  673. Dave Cridland SaltyBones, For your amusement and mild confusion, XMPP authorizes streams by a 3-tuple of (from-domain, to-domain, direction).
  674. Zash Page up button tho
  675. Dave Cridland SaltyBones, Well. One or more of those 3-tuples anyway.
  676. MattJ Dave Cridland, who hasn't requested authorization for what? You mean Prosody connects to d.c.n as 'xmpp.org' and sends stanzas from 'muc.xmpp.org'?
  677. Dave Cridland MattJ, Yup, that.
  678. dwd has joined
  679. Zash The thing
  680. Dave Cridland MattJ, Like this: DEBUG 2018-02-12T15:14:35 /home/dwd/src/Metre/src/xmlstream.cc:95 : NS296914 - G ot [399] : <?xml version='1.0'?><stream:stream xmlns:db='jabber:server:dialback' xmlns:stream='http://etherx.jabber.org/streams' version='1.0' from='xmpp.org' t o='dave.cridland.net' xml:lang='en' xmlns='jabber:server'><iq id='472-452048' ty pe='error' to='dave.cridland.net' from='xsf@muc.xmpp.org/tim@boese-ban.de'><erro r type='cancel'><not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></e rror></iq>
  681. dwd This time I'm joined. Timing, I guess.
  682. Zash Uh, what was the thing with that again?
  683. Dave Cridland Zash, The bug itself? Responding to inbound traffic on a multiplexed stream by reversing the wrong domain pair.
  684. MattJ dwd, I don't see how timing would play a part
  685. Zash Dave Cridland: Do you remember where we discussed this?
  686. Dave Cridland MattJ, I think whether I can join is dependent on what streams are open, which is dependent on the session lifetime and activity.
  687. Dave Cridland MattJ, Not timing as in a race condition, mind.
  688. Dave Cridland Zash, Erm. 1:1 messages, I think, until we figured out it definitely wasn't a security issue.
  689. Dave Cridland Zash, Possibly some discussion in jdev.
  690. dwd FWIW, I have to put in something similar to an implicit auth for X2X, anyway. So this may provide a workaround.
  691. suzyo has joined
  692. Alex has joined
  693. Martin has left
  694. Zash MattJ: https://hg.prosody.im/trunk/file/0de0018bdf91/plugins/mod_s2s/mod_s2s.lua#l203
  695. MattJ Zash, exactly where I ended up
  696. Zash stanza from/to may differ from the stream to/from in case of dialback multiplexing
  697. Alex has left
  698. Alex has joined
  699. pep. has left
  700. Alex has left
  701. Martin has joined
  702. jubalh has joined
  703. jubalh has left
  704. jubalh has joined
  705. Dave Cridland MattJ, You switching to FreeBSD?
  706. Dave Cridland MattJ, https://svnweb.freebsd.org/base?view=revision&revision=329166
  707. Holger has left
  708. zinid svn o_O
  709. edhelas gitis too mainstream
  710. zinid capitalist pigs use git!
  711. Zash gititis
  712. Holger NetBSD has Lua in the kernel for years!
  713. Zash Dave Cridland: Heh, nice
  714. Holger https://www.phoronix.com/scan.php?page=news_item&px=MTMwMTU
  715. Holger And it has CVS :-)
  716. zinid damn, I only get used to svn...
  717. Dave Cridland Holger, Can you download NetBSD yet, or is it still only available on tape?
  718. zinid Holger, cool stuff btw
  719. SamWhited More importantly, once I download it can I run it on any machines made after 1995? (this is always the problem I had trying to run NetBSD; a few of the ops people at work run it, but they all use *very* old machines)
  720. Dave Cridland gets prepared to explain "tape" to the younger readers.
  721. Dave Cridland SamWhited, Sure! It runs pretty well even modern machines like the Amiga 4000.
  722. nyco has left
  723. Dave Cridland (Sorry, that was 1993).
  724. SamWhited Exactly.
  725. Holger Well yes it's about as dead as XMPP :-P
  726. SamWhited I would like to use at *least* a P3.
  727. Holger But it always worked okay-ish for me on non-recent ThinkPads.
  728. Holger I no longer do that though.
  729. Holger cpu0 at mainbus0 apid 0: Intel(R) Core(TM) i3-2120T CPU
  730. Holger ... is the one box I still run NetBSD on.
  731. Zash Uh, was NetBSD the one being difficult, or OpenBSD?
  732. Holger Difficult?
  733. SamWhited Actually, jokes aside, that might be a nice thing to do with my broken old thinkpad; doesn't work very well as a laptop anymore, but it could be a {Free,Net,Open}BSD or Illumos "desktop".
  734. Holger Zash: Isn't all computers difficult except for Apple?
  735. SamWhited This is true… ⤴
  736. Dave Cridland has left
  737. Zash Et Apple, Holger
  738. Dave Cridland I find Apple incomprehensibly difficult to use, I must admit.
  739. Dave Cridland I've yet to figure out how to go up a directory consistently in file dialogs.
  740. Kev cd ..
  741. Kev Happy to help.
  742. Holger Managing FreeBSD feels more or less like Debian to me, the two others feel a bit more basic but not really harder to use. All dead simple compared to the dances you had to go through when partitioning hard disks or getting X11 to run 20 years ago with any Linux or BSD.
  743. Dave Cridland Holger, Ah, X11. Kids these days don't know they're born.
  744. Dave Cridland Kev, Don't get me started on the antiquated command line tools Apple foists upon you.
  745. remko has joined
  746. Holger Yes, we're horribly old.
  747. Dave Cridland Holger, We're very experienced. I'm sure that's what you meant.
  748. Zash I'm sure wayland will bring back the good old times for those who miss configuring Xorg
  749. Holger Precisely.
  750. SamWhited The only thing I want out of a machine is to sync an old ipod without Rhythmbox crashing…
  751. Dave Cridland SamWhited, Rhythmbox never crashes.
  752. Dave Cridland SamWhited, At that speed it's called "parking".
  753. SamWhited Rhythmbox is one of those people who parallel parks by backing up until they hit the car behind them, then driving forward until they hit the car in front.
  754. efrit has left
  755. jubalh has joined
  756. Alex has joined
  757. SaltyBones So, why is it that a client cannot create the stanza-id?
  758. SaltyBones Is this a thing about malicious clients or what's going on there?
  759. Dave Cridland has left
  760. jonasw SaltyBones, no, unaware clients are sufficient; colliding IDs would lead to interesting issues with MAM
  761. SaltyBones jonasw, but if the client is only unaware the server could just return an error informing the client that this ID has been used.
  762. Dave Cridland SaltyBones, But we could use, say, stream-id + attribute-id to form a stable, non-colliding reference identifier.
  763. jonasw SaltyBones, that’d be annoying to handle in the client, and the server would need an O(1) (or similar) way to determine that the ID has been used already...
  764. SaltyBones Yeah, or we could hash things and god knows what else...it seems very solvable...
  765. Dave Cridland SaltyBones, I mean, unless the client isn';t generating unique ids within its stream, in which case it's presumably not going to be fixed to use some other identifier.
  766. jonasw Dave Cridland, stream id + sm-counter?
  767. jonasw that’s verifiable by the server
  768. jonasw and predictable for both
  769. Dave Cridland jonasw, True. But I think we had some ideas on predictability outside the stream?
  770. SaltyBones throw a hash on top to avoid privacy issues, done
  771. SaltyBones Dave Cridland, I thought we dicussed those into oblivion earlier? :)
  772. Dave Cridland SaltyBones, Really I've lost track.
  773. jonasw Dave Cridland, hmmm ... hmac(stream-id, sm-counter)?
  774. Dave Cridland SaltyBones, I have the feeling that nobody quite knows the entire picture here.
  775. SaltyBones I almost lost track and I basically didn't work at all today and just discuss here. :p
  776. Dave Cridland jonasw, HMAC() requires a secret to be of any use.
  777. jonasw Dave Cridland, stream-id.
  778. SaltyBones Seems reasonable on first sight...
  779. jonasw (post-TLS obviously...)
  780. Dave Cridland jonasw, Is that secret? And why HMAC over a hash?
  781. SaltyBones Oh, that would leave out the hash...
  782. jonasw Dave Cridland, I’m fine with hash(stream-id || sm-counter) too, but that’s nearly an hmac ;-)
  783. SaltyBones hmac basically IS a hash
  784. SaltyBones yeah :)
  785. Dave Cridland jonasw, I'm pretty sure it's not. :-)
  786. SaltyBones I am very sure it is. :)
  787. jonasw that’s why I said "nearly"
  788. jonasw I think the concat is slightly different
  789. SaltyBones (yes, nearly)
  790. SaltyBones https://wikimedia.org/api/rest_v1/media/math/render/svg/4edcf0bd8b403c93564b8d7ea91338b3208dea03
  791. jonasw doesn’t matter anyways
  792. Dave Cridland jonasw, An HMAC is two nested hashed with concats and masks, yes.
  793. SaltyBones Okay, so we only disagree on our definition of nearly. ;)
  794. Dave Cridland jonasw, But the security properties are distinct.
  795. jonasw Dave Cridland, I don’t argue that
  796. jonasw (and I’m aware)
  797. SaltyBones Anyway, the suggestion of HMAC(key=stream-id, msg=sm-counter) seems good, doesn't it?
  798. Dave Cridland In any case, given a stanza with a known id on a given stream, we clearly want to be able to predict the MAM id.
  799. SaltyBones I mean, I am also fine with SHA-*(stream-id || counter-sm)
  800. SaltyBones Dave Cridland, but mam-id = stanza-id which is what I am proposing to set to this...
  801. Dave Cridland Question is, do we think the MAM id is likely to become public, and if so, can someone relatively easily figure out the next (or previous) value, and then do Something Bad?
  802. SaltyBones Dave Cridland, that might be the question bit if it only costs us a hash per message to not answer it might also not be...
  803. SaltyBones Dave Cridland, that might be the question but if it only costs us a hash per message to not answer it might also not be...
  804. SaltyBones Dave Cridland, that might be the question but if it only costs us a hash per message to not answer it, it might also not be...
  805. Dave Cridland What I'm wondering, you see, is whether we give clients an algorithm to generate attribute-id and then let them signal to the server that they're going to use globally-unique attribute-ids and the server is allowed to call them out if they don't.
  806. jonasw Dave Cridland, okay, right, this is about the MAM ID. this *probably* doesn’t matter, but if the goal is to consolidate all IDs at some point, choosing a way where the ID can become public is safer
  807. zinid has left
  808. Dave Cridland jonasw, That's roughly my thought, yes.
  809. jonasw and at that point, HMAC(…) seems like a sane choice.
  810. Dave Cridland jonasw, Well, that and "But we *HAVE* stanza ids - right there in the stanza!"
  811. Kev How would the server know that they didn't use a globally unique id?
  812. SaltyBones Kev, if the server can simply re-run the generation algorithm and compare results..?
  813. jonasw Kev, if the ID doesn’t follow the algorithm for a globally (predictable, for the server and client only) unique ID
  814. Dave Cridland Kev, Well, it'd know if they used no id at all, and if it saw a collision within a stream.
  815. Kev If we only cared about collisions within a stream, we could trivially solve all issues already.
  816. SaltyBones And that is how you can tell that Kev is a VIP
  817. SaltyBones when he says something three people reply!
  818. Dave Cridland Kev, Well, we care about collisions for a user's account for MAM, and no further.
  819. Kev But having a useful id to refer to a message would be jolly useful, and I don't see how we can get there yet.
  820. SaltyBones Okay, so you're saying when two servers federate and you assume one of them is malicious how can the other make sure he doesn't get duplicate IDs?
  821. Kev Or non-malicious server with a malicious client.
  822. Dave Cridland SaltyBones, Do they care? ANd if not, should they?
  823. jonasw SaltyBones, you don’t use other servers stanza-ids in your own MAM
  824. SaltyBones Well, the malicious client would be detected by the server.
  825. Kev jonasw: Bloody useful if you could, though, no?
  826. Kev SaltyBones: How would the server know it's malicious, if it doesn't know all globally generated ids?
  827. Alex has left
  828. SaltyBones Kev, it can simply check if the client generates their IDs correctly...
  829. Dave Cridland Kev, Again, why would a server care?
  830. Kev Without exploding the size of IDs, at least.
  831. jonasw (we should mandate the use of shakespeare-inspired adjectives in each bloody sentence in this room, by the way)
  832. jonasw Kev, how would it be useful?
  833. Kev I'd like to send a reference to a stanza, where the reference makes sense in my archive, the MUC/MIX archive, and the user's archive.
  834. Dave Cridland jonasw, I don't think "bloody" is Shakespeare. "Submarine" is, though, as far as I remember.
  835. SaltyBones Kev, you simply make it a hash or hmac of something that both the client and the server know and the server can check the calculation.
  836. Kev "simply" :)
  837. SaltyBones Kev, but doesn't that only involve you, the muc/mix server and $other_client? i.e. only one server...?
  838. Dave Cridland Kev, Is the (from, id) attributes of the stanza sufficient? If not, why?
  839. Zash If this is for MAM purposes, then I will cry if I can't stick some time based bits into the ID
  840. Kev Dave Cridland: No, because the from gets rewritten.
  841. Dave Cridland Kev, When?
  842. SaltyBones Zash, what?
  843. Kev In a MUC or a MIX.
  844. Zash My MAM ids are basically yyyy-mm-dd-random
  845. jonasw Kev, those are different use-cases I think.
  846. Kev jonasw: If we cherry-pick the trivial use cases, it's going to be trivial to solve them :)
  847. jonasw Kev, this is where origin-id makes more sense. It is generated by the client. If the client doesn’t ensure that there’s enough entropy in there, references to their message won’t work.
  848. SaltyBones Zash, and this is important because?
  849. Dave Cridland Kev, Ah, so given a message from a MUC fanout, do you want to be able to identify the originating id? I'm not actually sure you always want to allow that.
  850. Alex has joined
  851. jubalh has joined
  852. SaltyBones I still don't get it. Why does from get rewritten?
  853. SaltyBones And what does that have to do with anything? :D
  854. jonasw SaltyBones, when you send a message from saltybones@yourdomain.example/client-resource to this MUC, we see the message from xsf@muc.xmpp.org/SaltyBones
  855. jonasw so the from is being rewritten.
  856. jonasw and if references are based on (from, id) pairs, you can’t use the same reference we all can use for your message
  857. jonasw (simplified, of course we could still refer to the reflection of the message, but that would break down with MIX, too, I think)
  858. Dave Cridland has left
  859. Kev jonasw: Well, no, because if you can fake someone else's id, suddenly you can maliciously change the target of a reference.
  860. jonasw Kev, good point. so we indeed need something like (from, id) :(
  861. SaltyBones Wait what?
  862. zinid lol
  863. SaltyBones How can you now fake stuff again?
  864. jonasw but given that all our fanouts and from-rewriting things do actually do reflections, I’m not sure if that’s so bad, Kev?
  865. jonasw your local archive woudl still be able to resolve everything
  866. Kev jonasw: Well, it enforces a round-trip before you can refer to or correct anything, which isn't ideal.
  867. jonasw Kev, you normally know the "from" you’ll be having.
  868. jonasw and since you set the origin-id yourself, you already know everything you need
  869. jonasw (meh, races with server-enforced nickname changes in MUC)
  870. Kev Point.
  871. jonasw (but I guess those will be rare enough for us not to care)
  872. SaltyBones halp! :(
  873. Dave Cridland has left
  874. Kev SaltyBones: Because there are potentially malicious entities.
  875. tim@boese-ban.de has left
  876. daniel has left
  877. SaltyBones Are these only clients or servers as well?
  878. Kev jonasw: Still doesn't help where a user generates the same id twice, I think, and you're left with ambiguous references/corrections/whatever.
  879. Kev SaltyBones: Both.
  880. SaltyBones So why do you connect to a malicious server and expect things to work?
  881. SaltyBones Maybe that's not a good approach.
  882. jonasw Kev, that’s not an issue. put 256 bits of entropy in there and you are officially allowed to not care
  883. Kev Ah, if you have a mechanism for identifying malicious intent on the Internet, you could be a very famous person.
  884. jonasw Kev, and if we want to have defined behaviour in that case, always assume the most-recent message
  885. ralphm has left
  886. Kev jonasw: That only works for accidents, rather than manipulation, no?
  887. marc has left
  888. SaltyBones Kev, but you cannot manipulate as long as the server is checking.
  889. jonasw Kev, indeed
  890. jonasw but if you manipulate your own origin-ids, it’s your own fault?
  891. SaltyBones Of course if we have malicious servers now a bit more work is required. :)
  892. Kev And I'm concerned that 'most recent' falls apart if you can manage different people receiving different subsets.
  893. jonasw can one inflict harm by producing duplicate origin-ids?
  894. jonasw I’m not convinced that this is actually an issue.
  895. Kev Most likely.
  896. Kev If I can cause the 'wrong' message to get corrected.
  897. jonasw maybe with something like Reactions based on (from, origin-id) references.
  898. Kev Or a like to apply to the wrong message.
  899. Kev If I can manipulate you into liking a Godwin instead of something sensible, that's not ideal.
  900. andy has joined
  901. jonasw meh
  902. SaltyBones But messages aren't authenticated anyway, if you are a malicious server you can claim to have received whatever likes from me...
  903. jonasw Kev, then the only way is a MUC/MIX stanza ID generated by the MUC/MIX and waiting for a round-trip before references can be done.
  904. Kev SaltyBones: Other way around.
  905. jonasw SaltyBones, all it needs for now is a malicious client though
  906. jonasw SaltyBones, or a malicious client+server pair if we do the hmac-stanza-id thing for origin-id
  907. jonasw I can still run my own server and make it fake origin-ids
  908. daniel has left
  909. andy has left
  910. andy has joined
  911. zinid your own malicious server?
  912. jonasw Kev, I’d however argue that actively, from a client/own server side, make participants in a MUC/MIX receive only parts of the conversation would be rather trikcy
  913. jonasw and targeted parts even
  914. jonasw and that without them suspecting that things are broken in funny ways and thus not trusting the system anymore
  915. Kev jonasw: Ah, that's ok then, no exploits have ever involved doing anything tricky :)
  916. jonasw Kev, I see your point, but I’m not sure this is actually something which is reasonably exploitable.
  917. jonasw but yes
  918. jonasw unless we let the ID be generated by the fanout service, there’s no way to be sure I’m afraid
  919. jonasw I mean, I don’t have an issue with that, I’m fine with that even.
  920. Kev Yes. I don't see a way of solving this, which was why I brushed it under the carpet at the Summit.
  921. jonasw complicates things though
  922. Guus has joined
  923. jjrh has left
  924. marc has left
  925. jonasw Kev, I’m having a really hard time constructing a successful attack which wouldn’t be seen by the victim in the MUC case
  926. jonasw even when I omit arbitrary messages
  927. jonasw to only some participants
  928. jonasw (which would be really really tricky to achieve targetedly I think)
  929. jonasw ah, now I have it
  930. jonasw this is the scenario: 1. user A, "bad statement", origin-id=1 2. user A, "good statement", origin-id=1 3. user B, like (from=user A, origin-id=1) if (2) isn’t seen by all users, they see user B liking "bad statement" instead of "good statement"
  931. tux has joined
  932. jonasw with an arbitrary amount of messages between (2) and (3), it is also not too difficult to make people not see (2) in a MAM-less MUC.
  933. Kev Indeed.
  934. Dave Cridland has left
  935. jonasw I don’t think there’s a way unless the MUC does things there
  936. jonasw (i.e. if the MUC generates the ID?)
  937. SaltyBones But, all it requires to prevent that is for the MUC to check that the ID is unique just like the assumed-non-malicious server did in our previous discussionn...
  938. jonasw (i.e. if the MUC generates the ID)
  939. jonasw SaltyBones, but that is a rather expensive check to do
  940. jonasw you need to record IDs for all eternity, or have a defined way to generate the ID which can be executed by clients
  941. jonasw the latter would be tremendously tricky to get to work synchronously
  942. jonasw but possible...
  943. SaltyBones Which is a little more tricky because there is no obvious common "secret" like the stream-id but a simple Hash("counter") would do
  944. jonasw something like hash(message-counter || presence-id), where presence-id is an ID assigned to the client on join
  945. SaltyBones Kev, not that in this case I used the word simple again but I was totally lying...
  946. SaltyBones Kev, note that in this case I used the word simple again but I was totally lying...
  947. jonasw hash counter doesn’t really work with multi-session nicks I think, it would lead to collisions or races
  948. SaltyBones jonasw, yeah it was just to get the idea. Indeed you would at least need some salt.
  949. SaltyBones But if the server gives you the salt on join and you use that to generate the IDs it should be good again.
  950. jonasw that would be verifable by the MUC and the MUC would drop stanzas which do not adhere to this schema
  951. jonasw (or rather, reject)
  952. SaltyBones and since the counter can be per-muc there is no issue with having it
  953. jonasw per client even
  954. SaltyBones I think :p
  955. jonasw Kev, ^
  956. SaltyBones well, yes per client and per muc
  957. SaltyBones just saying it doesn't seem to be a privacy issue
  958. jonasw SaltyBones, yeah
  959. remko has joined
  960. jonasw so origin-id = one-way-function(presence-id, message-counter), where presence-id is assigned on MUC join
  961. andy has left
  962. jonasw only need to define what happens when message-counter wraps around or becomes large or something
  963. jonasw (same thing for SM by the way, SM has wraparound semantics)
  964. efrit has joined
  965. SaltyBones O_o
  966. SaltyBones Y U SEND SO MANY MESSAGES!?!!
  967. ralphm has joined
  968. jonasw SaltyBones, itym "y u have so long sessions"
  969. andy has joined
  970. SaltyBones still, if this is defined somewhere we can probably renegotiate the salt at that point...
  971. jonasw while wrapping around a 64bit counter in a single session is sure challenging, we need to be prepared if this is to be solid :)
  972. jonasw yeah
  973. Maranda has joined
  974. zinid I hear counter?
  975. zinid sorry, I don't track the discussion
  976. jonasw zinid, I’m not going to repeat everything you can read in the backlog :)
  977. zinid as you wish
  978. zinid not that I care
  979. SaltyBones counter works in this case because you can restart counting when rejoining the muc
  980. zinid whatever you will end up will be shit anyways, so
  981. Maranda has left
  982. zinid you already created 4 fucking ids: stanza-id, origin-id, attribute-id and SM id
  983. zinid maybe it's time to stop and think?
  984. jonasw what is an sm ID?
  985. zinid h
  986. jonasw right
  987. jonasw zinid, all of this is about reducing the number of IDs, so I thnik this is kinda what we’re doing?
  988. zinid jonasw, from what I see you want to add yet another counter
  989. jonasw zinid, to generate origin-ids, yes
  990. jonasw for MUCs and MIXes
  991. jonasw to make them verifiable by the service
  992. jonasw zinid, or rather, we’re replacing origin-id by some one-way-function(counter)
  993. zinid how this will cover sm id?
  994. waqas has joined
  995. SaltyBones We haven't discussed sm-id, yet. Only the other three.
  996. SaltyBones I actually have no clue what sm-id is. :)
  997. zinid SaltyBones, then I need to wait while you recognize the problem 😉
  998. SaltyBones zinid, so reducing 4 -> 2 is not enough, eh? :p
  999. jonasw zinid, sm-id stays, but stanza-id (and attribute-id) could potentially become one-way-function(stream-id, sm-id)
  1000. zinid 2 is enough, however I think first should be counter and second should be routing information, and not an ID
  1001. jonasw stanza-id being used for the archive only, origin-id being used throughout the network together with the sender address for refernecing a specific message
  1002. lovetox has joined
  1003. zinid what ID will be used to sync?
  1004. ralphm has joined
  1005. zinid with SM IDs you just create a pointless queue in c2s state
  1006. Ge0rG has left
  1007. SaltyBones Okay, I think we are trying to solve a problem that is very orthogonal to stream management. But we have only discussed this a bit and it might very well not work even for what we want it to do.
  1008. zinid SaltyBones, I don't think SM should be separated from archive
  1009. zinid it's pointless
  1010. SaltyBones Why?
  1011. jonasw zinid, stanza-id is used for ysnc
  1012. jonasw (for MAM sync that is)
  1013. zinid SaltyBones, because why you need this separation?
  1014. zinid SaltyBones, you keep messages in MAM and then put them in c2s SM queue
  1015. zinid why can't you just inc(counter), store in MAM and send via c2s?
  1016. SaltyBones Why are you asking me that? I am 100 % sure that you know more about SM than I do!
  1017. zinid what I know about SM is that I need to maintain stupid queues inside c2s processes, which sucks as hell
  1018. zinid even though a client can request those messages via MAM
  1019. zinid if you receive an ID out of order, you just reconnect and ask everything started from the ID you received
  1020. zinid and server will send you this from archive
  1021. zinid and vice versa
  1022. SaltyBones But SM-IDs are per-stream not per-message, right?
  1023. andy has left
  1024. SaltyBones At least that's what it looks like in https://xmpp.org/extensions/xep-0198.html
  1025. zinid when you connect a server, you provide last seen ID and it will resend you everyting what's greater than this ID
  1026. zinid SaltyBones, yes, they are totally separated instances
  1027. SamWhited What if the thing you missed was an IQ or a presence that isn't stored in MAM?
  1028. SamWhited If you temporarily disconnect and miss something, SM acks allow you to find out. Doesn't help as much if it only covers messages.
  1029. zinid SamWhited, I think we can drop them
  1030. ralphm has joined
  1031. zinid SamWhited, we already don't care about IQs with Push, so why would we start care?
  1032. zinid try to make jingle call when I'm in "push" mode
  1033. SamWhited Does that not work? That does seem like something we need to care about to me
  1034. zinid SamWhited, but we don't and we cant with push stuff
  1035. jonasw shouldn’t an IQ trigger a push? :-O
  1036. zinid SamWhited, what if I want to receive your software version and you're in push mode?
  1037. SamWhited That seems like a problem that needs fixing then, not an example of something being done right that we should copy.
  1038. Steve Kille has left
  1039. zinid anyway, you can keep IQs in MAM if you prefer
  1040. zinid you need to keep subscription requests for sure there
  1041. zinid we keep them already, but in a separate database due to historic reasons only
  1042. Martin has left
  1043. andy has joined
  1044. Steve Kille has joined
  1045. jonasw IQs (which are inherent request-response, with exactly one response) in MAM sounds like a terrible idea.
  1046. SamWhited yah, now you have to try and figure out which IQs are time sensitive, which are important to store, etc. it seems like a comlicated way to work around having a stanza counter.
  1047. zinid SamWhited, but you have to decide now too: for example, after 5 minutes of inactivity (by default) a server just bounce all IQs from SM queue
  1048. zinid *bounces
  1049. SamWhited I'm not saying it's perfect, just that this doesn't seem like a good fix.
  1050. zinid a fix? the behaviour is the same
  1051. SaltyBones has left
  1052. zinid but we let a client to decide which IQ to reply
  1053. SamWhited Except now you have to store all stanzas in MAM, or not store some stanzas and risk those being the ones that are dropped and you don't know you missed something. The point of SM is to make sure you know if you lose something, which is often important.
  1054. andy has left
  1055. zinid do you really want to loose incoming call?
  1056. zinid that's how it works now: if somebody calls you and you're not connected you loose any track
  1057. SamWhited As I said, I'm not claiming that the current solution is good; just that this makes it worse.
  1058. zinid no, it makes it better
  1059. zinid you just need to define what to store and what not, well, it's too much to redesign, yes
  1060. SamWhited If you don't store everything you now lose the ability to detect connection drops though
  1061. zinid sigh
  1062. Dave Cridland has left
  1063. Guus has left
  1064. Guus has joined
  1065. zinid not sure how will you address missing call though
  1066. zinid with your approach
  1067. SamWhited I do not have an approach; I agree that is a problem that needs solving though.
  1068. Dave Cridland has left
  1069. Dave Cridland has left
  1070. Dave Cridland has left
  1071. Dave Cridland has left
  1072. SaltyBones It seems like we need storage for management messages and storage for actual messages. I don't see why these should be mixed up.
  1073. Guus has left
  1074. rion has left
  1075. Dave Cridland has left
  1076. Guus has joined
  1077. remko has joined
  1078. zinid we need to decide what to store and what not
  1079. Dave Cridland has left
  1080. SaltyBones hm..that distinction was wrong, yeah
  1081. SaltyBones there should be a storage until delivered and an optional long term storage
  1082. Dave Cridland has left
  1083. SaltyBones users might not even want mam :p
  1084. zinid if you don't want mam then just lose messages
  1085. SaltyBones Okay, let me rephrase, some users might not want long-term storage of messages...
  1086. zinid not sure why this should be specific to any approach
  1087. SaltyBones Because I think that's what MAM is intended for and that's why using it for all messages as you suggest is strange and might have unexpected results if people built it under the assumption that it is for long term storage...
  1088. bra has left
  1089. bra has joined
  1090. zinid servers can drop MAM archives on reconnect for example, what's the problem?
  1091. SaltyBones Okay...
  1092. zinid or later, when it's delivered
  1093. SaltyBones this is just me confusing MAM and the other thing again...
  1094. SaltyBones for the one-millionth time...
  1095. Ge0rG What if I want my messages both on my pc and my mobile? I can't just drop MAM when my pc is online
  1096. zinid you can if everything is delivered
  1097. zinid anyway, what you are trying to say is a partial replication, and this problem is very hard to resolve
  1098. SaltyBones what is the other thing again, server side archiving?
  1099. ralphm has joined
  1100. SaltyBones zinid, does MAM know if everything was delivered?
  1101. Seve/SouL has left
  1102. Ge0rG had a very concerning realization about guessable IDs and packet filters in smack earlier today.
  1103. zinid SaltyBones, well, no, I think you cannot know that in general case
  1104. SaltyBones zinid, but that is what SM does, right?
  1105. zinid SaltyBones, well, if you introduce acks, then yes
  1106. SaltyBones Hm.... :)
  1107. Holger All this is orthogonal to the question whether having two separate stanza/message queues is sane. I agree with zinid that it isn't.
  1108. Zash Two whatnow
  1109. Ge0rG I'm saying for many years now that we need to replace 0184, 0198, 0280 and 0313 with one single proper message syncing thing.
  1110. Holger SM is already mostly just an optimization, and I think we should fix the remaining issues to make stream management superfluous.
  1111. SaltyBones I just want to point out that this is orthogonal to our earlier discussion about IDs :)
  1112. zinid SaltyBones, I said "no" in general case because we have Bysantine General Problem, it's unresolvable, what we can gurarantee is sequential consistency
  1113. Dave Cridland has left
  1114. Ge0rG SaltyBones: please show your ID before being allowed into this room :P
  1115. Tobias has joined
  1116. SaltyBones Holger, does anybody already know what those issues are?
  1117. daniel has left
  1118. Guus has left
  1119. Guus has joined
  1120. Zash Ge0rG: Kidnap some server devs and lock yourself in a room until that one single proper message syncing thing to rule them all is properly implemented and XEP'd
  1121. Holger SaltyBones: Syncing of outgoing messages (in a sane way) and maybe avoiding some round trips during session startup.
  1122. zinid Zash, and watch them die 😉
  1123. Ge0rG Zash: I'll lock you and zinid up in that room, and watch the live stream
  1124. SaltyBones Holger, so, can we just turn off stream management and leave MAM and see what happens to find out?
  1125. Holger Sure you can :-)
  1126. SaltyBones Or do you think fixing up MAM is a bad idea and something new is required?
  1127. Zash SaltyBones: That's what I did, actually. Haven't died from SM-lessness yet.
  1128. Holger SaltyBones: I think you can already implement proper sync with MAM as-is. But something new is required to let clients implement this in a sane way, without having to de-duplicate and whatnot.
  1129. zinid that's my point: what we need is to store messages and some other restricted stuff and call it a day
  1130. SaltyBones Holger, so would unique message IDs solve this?
  1131. SaltyBones I mean, at least de-duplication would be reasonably easy then, I guess.
  1132. jjrh has left
  1133. SaltyBones Of course some sort of counter makes more sense in this case...
  1134. Zash SM has counters. MAM has server-issued, guarante to be unique message ids.
  1135. ralphm has joined
  1136. SaltyBones Why are IDs not a counter?
  1137. Holger Not sure what sort of uniqueness we need to solve what problem. Didn't read the backlog, sorry :-) The thing missing for proper sync of outgoing messages is an algorithm to compute the MAM IDs of outgoing messages.
  1138. SaltyBones I mean the MAM-IDs....or is that the same as the stanza-ids?
  1139. Holger (Sorry, typed this before reading the last few messages.)
  1140. zinid Zash, now answer the question "get me last messages I didn't receive" with current SM and MAM approach 😉
  1141. SaltyBones Holger, what do you mean by outgoing? Messages that we sent?
  1142. Holger Yes.
  1143. zinid if you say "time", then no
  1144. Zash zinid: query after = id of last message I saw
  1145. SaltyBones Okay, that should be solved by the hash idea....if it works :p
  1146. Zash cry over outgoing messages sent after that
  1147. Holger SamWhited: I need to know their IDs so I can tell the server "give me all messages since $id".
  1148. SaltyBones But indeed if we want to query MAM by a "point in time" or "counter" unique IDs are not really the best thing :)
  1149. remko has joined
  1150. SaltyBones Holger, but then the server still has to search the MAM archive for that ID and give you everything after it....
  1151. zinid Zash, define after in distributed system 😉
  1152. SaltyBones So a counter would be much better.
  1153. Holger SaltyBones: Sure?
  1154. Zash zinid: MAM archive ids on incoming messages
  1155. SaltyBones Right?
  1156. Zash zinid: after is a MAM term
  1157. zinid Zash, but you need some ordering
  1158. pep. has left
  1159. Zash zinid: huh
  1160. Zash zinid: XMPP streams are ordered
  1161. zinid yes, but you need to maintain a timestamp index in the database
  1162. Zash You've lost me
  1163. Dave Cridland has left
  1164. Guus has left
  1165. Guus has joined
  1166. zinid well, you're probably right that if we assume timestamp ordering then we don't need counters and SM at all
  1167. Zash Huh?
  1168. Zash In a MAM query, 'after' is a field that carries a MAM archive ID
  1169. zinid so, what's the ordering? 🙂
  1170. andy has joined
  1171. zinid ID+1?
  1172. zinid from what I understand you use timestamp+id, which means time ordering
  1173. Zash Ordering?
  1174. Zash As I said, you lost me. I have no idea what any of us are talking about anymore.
  1175. zinid ok
  1176. vanitasvitae has left
  1177. lskdjf has left
  1178. Guus has left
  1179. Tobias has joined
  1180. Dave Cridland has left
  1181. remko has joined
  1182. la|r|ma has joined
  1183. daniel has left
  1184. rion has joined
  1185. Dave Cridland has left
  1186. suzyo has joined
  1187. Dave Cridland has left
  1188. andy has left
  1189. ralphm has joined
  1190. Dave Cridland has left
  1191. rion has left
  1192. Syndace has left
  1193. Syndace has joined
  1194. Dave Cridland has left
  1195. blabla has left
  1196. blabla has joined
  1197. remko has joined
  1198. Dave Cridland has left
  1199. ralphm has joined
  1200. Dave Cridland has left
  1201. Ge0rG https://summerofcode.withgoogle.com/organizations/?sp-page=5 no xsf?
  1202. zinid BEAM community is there 😛
  1203. andy has joined
  1204. jjrh has left
  1205. remko has joined
  1206. ralphm has joined
  1207. andy has left
  1208. moparisthebest SaltyBones: like 98% of what you were talking about is here https://github.com/moparisthebest/xmpp-ircd
  1209. Dave Cridland has left
  1210. Dave Cridland has left
  1211. Dave Cridland has left
  1212. moparisthebest Basically it works if IRC users don't want nickserv or chanserv but they do and I never got back to it :)
  1213. SaltyBones moparisthebest, you mean of a way to connect to a muc using the irc protocol?
  1214. moparisthebest Yes
  1215. moparisthebest Running that makes a muc look like an IRC server to an IRC client
  1216. Dave Cridland has left
  1217. SaltyBones I'm pretty sure nobody wants that. At least I don't! :D
  1218. SaltyBones But I think it might provide an excuse for people who have to convince irc users ;)
  1219. Dave Cridland has left
  1220. moparisthebest SaltyBones: yesterday you said
  1221. moparisthebest Hm...maybe the transport should be the other way round. Offer an IRC server that connects to MUCs.
  1222. moparisthebest That's what I was referring to
  1223. vanitasvitae Ignite didnt make it into GSoC
  1224. vanitasvitae :(
  1225. jubalh has joined
  1226. Dave Cridland has left
  1227. daniel has left
  1228. jubalh has left
  1229. jubalh has joined
  1230. SaltyBones moparisthebest, I know, I said that regarding the discussion of the KDE folks looking for an IM solution
  1231. andy has joined
  1232. Flow `> * Ge0rG had a very concerning realization about guessable IDs and packet filters in smack earlier today Care to share?
  1233. marc has joined
  1234. jubalh has left
  1235. Flow Or is it just something in the ancient smack library yaxim uses?
  1236. Dave Cridland has left
  1237. remko has joined
  1238. moparisthebest SaltyBones, right so they could use a MUC, but also have an IRC server that IRC users could use
  1239. Dave Cridland moparisthebest, I like this, BTW.
  1240. moparisthebest and everyone would end up in the same place, but it'd be a muc
  1241. Dave Cridland moparisthebest, Is the GPLv3 your addition or from telepaatti?
  1242. ralphm has joined
  1243. lskdjf has joined
  1244. Dave Cridland Anyone know what servers support XEP-0288 these days?
  1245. Dave Cridland Does this Prosody instance, for example?
  1246. moparisthebest Dave Cridland, looks like the original telepaatti is gone, but GPLv3 goes back to at least the next fork looks like
  1247. andy has left
  1248. andy has joined
  1249. moparisthebest honestly I kind of abandoned it because I like rust so much more than python nowadays but can't be asked to rewrite everything yet haha :)
  1250. Flow -xep 288
  1251. Bunneh Flow: Bidirectional Server-to-Server Connections (Standards Track, Draft, 2016-10-17) See: https://xmpp.org/extensions/xep-0288.html
  1252. moparisthebest I still run an IRC server I would love to rm -rf
  1253. SamWhited > I need to know their IDs so I can tell the server "give me all messages since $id". I know, apparently I wasn't clear about something, sorry. I'm not suggesting we get rid of MAM or leave everything exactly as it is today, just that MAM doesn't cover some important parts of SM and probably can't be made to cover it without significant downsides.
  1254. Ge0rG Flow: it's affecting the old smack for sure, I'll have a look into smack 4 and let you know
  1255. SamWhited (sorry for the long delay, got pulled into a meeting and then was AFK for a bit)
  1256. Dave Cridland greps his logs
  1257. Dave Cridland has left
  1258. Dave Cridland So there's actually only one server I talk to that does bidi. That's scary.
  1259. Dave Cridland has left
  1260. moparisthebest has left
  1261. Dave Cridland has left
  1262. winfried has left
  1263. Flow Ge0rG, let me know if you didn't just re-discover CVE-2014-0364
  1264. Dave Cridland has left
  1265. Syndace has left
  1266. Syndace has joined
  1267. jubalh has joined
  1268. Dave Cridland has left
  1269. Dave Cridland has left
  1270. Ge0rG Flow: it's related but different
  1271. Zash Dave Cridland: Is it mine? :)
  1272. marc has left
  1273. Dave Cridland Zash, No, Lance's. Although actually grep might have gone into Annoying Binary Mode.
  1274. SaltyBones -I ?
  1275. Dave Cridland has left
  1276. Dave Cridland -a, but yeah.
  1277. Dave Cridland has left
  1278. Syndace has joined
  1279. Dave Cridland has left
  1280. Dave Cridland has left
  1281. Dave Cridland OK, so that's actually lots of servers doing bidi. Happy bunny, now. I've been putting the support into Metre.
  1282. Zash Oh? Hm, feeling up for doing a survey?
  1283. Dave Cridland Zash, What sort of survey?
  1284. Zash "How many servers do 288?"
  1285. Zash Hooooold on now
  1286. Zash Is that the same number as ...
  1287. Zash https://www.youtube.com/watch?v=azEvfD4C6ow !!!
  1288. Dave Cridland has left
  1289. tux has left
  1290. Dave Cridland Zash, Looks like it's PSYC and Prosody.
  1291. Zash Prosody doesn't do it out of the box, you need to go a bit out of your way to install a community module.
  1292. Dave Cridland has left
  1293. Dave Cridland Really? Quite a few people have, then.
  1294. Dave Cridland has left
  1295. Zash Dave Cridland: Question is, how much self-selection bias is there among people that have you in their roster? :)
  1296. Dave Cridland Zash, Lots.
  1297. ralphm has joined
  1298. remko has joined
  1299. Dave Cridland has left
  1300. Dave Cridland has left
  1301. winfried has joined
  1302. winfried has joined
  1303. jubalh has left
  1304. andy has left
  1305. blabla has left
  1306. daniel has left
  1307. daniel has left
  1308. blabla has joined
  1309. moparisthebest has joined
  1310. Dave Cridland has left
  1311. jubalh has left
  1312. remko has joined
  1313. Dave Cridland has left
  1314. zinid has left
  1315. Dave Cridland has left
  1316. Dave Cridland has left
  1317. daniel has left
  1318. Alex has left
  1319. Dave Cridland has left
  1320. Dave Cridland has left
  1321. remko has joined
  1322. bra has left
  1323. bra has joined
  1324. daniel has joined
  1325. SamWhited has left
  1326. Alex has joined
  1327. marc has joined
  1328. Tobias has joined
  1329. Tobias has joined
  1330. Dave Cridland has left
  1331. remko has joined
  1332. bra has left
  1333. bra has joined
  1334. daniel has left
  1335. dwd has joined
  1336. dwd has joined
  1337. bra has left
  1338. bra has joined
  1339. daniel has joined
  1340. Dave Cridland .
  1341. Zash ,
  1342. Dave Cridland has left
  1343. moparisthebest has left
  1344. andy has joined
  1345. Kev M-Link does bidi, but we disabled it because of bug reports from Prosody about us not accepting stanzas down the right streams. Some of which I'm starting to question :)
  1346. Dave Cridland :-)
  1347. mimi89999 has joined
  1348. Dave Cridland has left
  1349. Dave Cridland has left
  1350. bra has left
  1351. bra has joined
  1352. Kev has left
  1353. moparisthebest has joined
  1354. remko has joined
  1355. bra has left
  1356. bra has joined
  1357. tux has left
  1358. jubalh has left
  1359. pep. has left
  1360. moparisthebest has joined
  1361. vanitasvitae has left
  1362. Dave Cridland has left
  1363. dwd has joined
  1364. blabla has left
  1365. tux has left
  1366. marc has left
  1367. SaltyBones has left
  1368. andy has left
  1369. remko has joined
  1370. vanitasvitae has left
  1371. daniel has left
  1372. dwd So, Metre now does Bidi.
  1373. daniel has joined
  1374. marc has left
  1375. lumi has left
  1376. dwd OK, this is weird. Metre is successfully negotiating Bidi with various Prosody servers. OK, great. But absolutely nothing ever tries to negotiate bidi with it, despite it offering the feature.
  1377. jjrh has left
  1378. Dave Cridland has left
  1379. Holger has left
  1380. dwd has left
  1381. Neustradamus has left
  1382. valo has joined
  1383. Dave Cridland has left
  1384. daniel has left
  1385. nyco has left
  1386. Neustradamus has joined
  1387. lskdjf has joined
  1388. daniel has joined
  1389. moparisthebest has joined
  1390. remko has joined
  1391. daniel has left
  1392. daniel has joined
  1393. blabla has left
  1394. jjrh has left
  1395. jjrh has left
  1396. jjrh has left
  1397. jjrh has left
  1398. Dave Cridland has left
  1399. remko has joined
  1400. lovetox has left
  1401. jjrh has left
  1402. Dave Cridland has left
  1403. SamWhited has left
  1404. Dave Cridland has left