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


  93. lovetox has joined

  94. Tobias has joined

  95. zinid


  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


  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


  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


  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


  225. Martin has joined

  226. moparisthebest has joined

  227. rion has joined

  228. marc


  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


  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


  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


  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


  333. SaltyBones


  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


  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


  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


  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


  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


  504. daniel

    read what i said before

  505. SaltyBones

    Uh, assuming a well-behaved server?

  506. daniel


  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


  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


  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


  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


  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


  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


  712. Holger

    NetBSD has Lua in the kernel for years!

  713. Zash

    Dave Cridland: Heh, nice

  714. Holger


  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


  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


  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


  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


  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


  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


  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


  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


  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


  966. SaltyBones


  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


  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


  986. jonasw


  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


  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


  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


  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


  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


  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


  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


  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


  1172. zinid

    from what I understand you use timestamp+id, which means time ordering

  1173. Zash


  1174. Zash

    As I said, you lost me. I have no idea what any of us are talking about anymore.

  1175. zinid


  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


  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