XSF Discussion - 2019-07-20

  1. mimi89999 has left
  2. mimi89999 has joined
  3. mimi89999 has left
  4. mimi89999 has joined
  5. adityaborikar has left
  6. adityaborikar has joined
  7. mimi89999 has left
  8. mimi89999 has joined
  9. Douglas Terabyte has joined
  10. mimi89999 has left
  11. mimi89999 has joined
  12. mimi89999 has left
  13. mimi89999 has joined
  14. mimi89999 has left
  15. mimi89999 has joined
  16. mimi89999 has left
  17. mimi89999 has joined
  18. mimi89999 has left
  19. mimi89999 has joined
  20. david has joined
  21. lumi has left
  22. valo has left
  23. valo has joined
  24. andy has left
  25. lskdjf has left
  26. benne has left
  27. benne has joined
  28. valo has left
  29. valo has joined
  30. alacer has joined
  31. benne has left
  32. pdurbin has joined
  33. pdurbin has left
  34. neshtaxmpp has left
  35. neshtaxmpp has joined
  36. valo has left
  37. valo has joined
  38. igoose has left
  39. igoose has joined
  40. pdurbin has joined
  41. adityaborikar has left
  42. david has left
  43. david has joined
  44. patrick has left
  45. patrick has joined
  46. UsL has left
  47. patrick has left
  48. zach has left
  49. zach has joined
  50. patrick has joined
  51. waqas has joined
  52. igoose has left
  53. adityaborikar has joined
  54. adityaborikar has left
  55. pdurbin has left
  56. karoshi has joined
  57. pdurbin has joined
  58. igoose has joined
  59. alacer has left
  60. alacer has joined
  61. adityaborikar has joined
  62. igoose has left
  63. lnj has joined
  64. Mikaela has joined
  65. andy has joined
  66. goffi has joined
  67. waqas has left
  68. wurstsalat has joined
  69. lovetox has left
  70. Nekit has joined
  71. debacle has joined
  72. curen has joined
  73. valo has left
  74. mimi89999 has left
  75. valo has joined
  76. mimi89999 has joined
  77. UsL has joined
  78. Lance has left
  79. rion has left
  80. rion has joined
  81. benne has joined
  82. benne has left
  83. benne has joined
  84. debacle has left
  85. rion has left
  86. rion has joined
  87. matlag has left
  88. matlag has joined
  89. eevvoor has joined
  90. igoose has joined
  91. lskdjf has joined
  92. lskdjf has left
  93. lskdjf has joined
  94. lumi has joined
  95. Andrew Nenakhov has left
  96. Andrew Nenakhov has joined
  97. krauq has left
  98. krauq has joined
  99. Andrew Nenakhov has left
  100. curen has left
  101. Andrew Nenakhov has joined
  102. adityaborikar has left
  103. adityaborikar has joined
  104. Andrew Nenakhov has left
  105. rion has left
  106. rion has joined
  107. eevvoor has left
  108. tom has left
  109. igoose has left
  110. Lance has joined
  111. lovetox has joined
  112. APach has left
  113. APach has joined
  114. Mikaela has left
  115. Andrew Nenakhov has joined
  116. larma has left
  117. Mikaela has joined
  118. igoose has joined
  119. larma has joined
  120. pdurbin has left
  121. adityaborikar has left
  122. adityaborikar has joined
  123. eevvoor has joined
  124. igoose has left
  125. Andrew Nenakhov has left
  126. adityaborikar has left
  127. Andrew Nenakhov has joined
  128. pep. To what <message/> should <origin-id/> be added? All?
  129. pep. Now that is was ruled out that LMC must refer to the original message, does it make sense to include an origin-id tag in it? As it will most likely not be referenced. (Same applies for other payloads I guess)
  130. adityaborikar has joined
  131. alacer has left
  132. alacer has joined
  133. XSF has left
  134. balu_der_baer has left
  135. edhelas has left
  136. nyco has left
  137. madhur.garg has left
  138. edhelas has joined
  139. nyco has joined
  140. matlag has left
  141. matlag has joined
  142. DebXWoody has left
  143. DebXWoody has joined
  144. eevvoor has left
  145. pdurbin has joined
  146. pdurbin has left
  147. DebXWoody has left
  148. DebXWoody has joined
  149. rion has left
  150. rion has joined
  151. Lance has left
  152. waqas has joined
  153. dele2 has joined
  154. typikol has joined
  155. Lance has joined
  156. dele2 has left
  157. dele2 has joined
  158. DebXWoody has left
  159. DebXWoody has joined
  160. dele2 has left
  161. typikol has left
  162. Lance has left
  163. lovetox pep. you need origin-id not for lmc
  164. lovetox you need it to deduplicate your own mam messages
  165. lovetox hm ah i remember now
  166. pep. hmm, because I don't get reflected messages in 1:1, I keep the origin-id and netx time I fetch MAM I can see where I stopped?
  167. pep. hmm, because I don't get reflected messages in 1:1, I keep the origin-id and next time I fetch MAM I can see where I stopped?
  168. lovetox it was because in the MUC xep was a sentence that MUCs dont have to keep the ids that clients set
  169. lovetox so message-id was overwritten by muc service, so you had no chance to deduplicate with it
  170. pep. Well in MUC it wouldn't apply right? As there is stanza-ids? Well, when the MUC does MAM
  171. pep. Otherwise yeah I can use origin-id
  172. lovetox no you are joined in a MUC, you set a message id
  173. lovetox you send the message
  174. lovetox damn, you are right
  175. lovetox i forgot why we added this
  176. lovetox maybe i remember later, im sure there was a reason
  177. pep. Maybe the XEP could be clarified and add a clear motivation
  178. lovetox but yeah that reason is maybe gone, maybe ask Daniel i think he remembers
  179. pep. I have an implementation in slix, I'll wait for feedback a bit more I guess
  180. Ge0rG Too many ids, too much confusion.
  181. pdurbin has joined
  182. Lance has joined
  183. andy has left
  184. andy has joined
  185. Lance origin-id was a way to stamp without leaking your jid
  186. Lance since stanza-id requires a by
  187. curen has joined
  188. pdurbin has left
  189. Nekit has left
  190. DebXWoody has left
  191. DebXWoody has joined
  192. waqas has left
  193. waqas has joined
  194. kokonoe has left
  195. kokonoe has joined
  196. adityaborikar Is this site down, or is there anywhere else I could read this white paper https://www.isode.com/whitepapers/xmpp-constrained-bandwidth.html
  197. adityaborikar The link is on https://xmpp.org/about/myths.html
  198. mathieui adityaborikar, https://web.archive.org/web/20160310073118/https://www.isode.com/whitepapers/xmpp-constrained-bandwidth.html
  199. adityaborikar Thanks ๐Ÿ˜€
  200. mr.fister has left
  201. winfried has left
  202. winfried has joined
  203. eevvoor has joined
  204. COM8 has joined
  205. COM8 has left
  206. alacer has left
  207. alacer has joined
  208. benne has left
  209. alacer has left
  210. alacer has joined
  211. wurstsalat has left
  212. alacer has left
  213. alacer has joined
  214. alacer has left
  215. alacer has joined
  216. Andrew Nenakhov has left
  217. alacer has left
  218. alacer has joined
  219. wurstsalat has joined
  220. Yagiza has joined
  221. valo has left
  222. valo has joined
  223. ralphm has left
  224. ralphm has joined
  225. adityaborikar has left
  226. ralphm I think they replaced it with https://www.isode.com/whitepapers/low-bandwidth-xmpp.html
  227. Zash Cool URLs don't change!
  228. adityaborikar has joined
  229. ralphm But it would sure be nice if they kept URLs working.
  230. ralphm FWIW it seems to be a different article
  231. ralphm As in newer.
  232. ralphm I'm sure Tobias knows.
  233. moparisthebest has left
  234. moparisthebest has joined
  235. Andrew Nenakhov has joined
  236. Andrew Nenakhov has left
  237. Andrew Nenakhov has joined
  238. frainz has left
  239. frainz has joined
  240. adityaborikar has left
  241. lovetox pep. i think i remember again
  242. lovetox first everything previous to mam:2 did not inject stanza-id
  243. pep. yeah I assumed there was something something mam and stanza-id
  244. lovetox second many clients used message-ids which were not uuids
  245. lovetox like 1, 2, 3, 4
  246. lovetox so yeah if we live now in a world where most clients use uuids as message-ids, and almost every server uses mam:2
  247. lovetox i think you dont need origin-id
  248. alacer has left
  249. alacer has joined
  250. andrey.g has left
  251. benne has joined
  252. patrick has left
  253. larma message id and origin-id have different uniqueness guarantees. - XEP-0359 origin-id MUST BE globally unique (at least that's the common understanding of XEP-0359), so if everyone plays by the rules it is globally unique, otherwise it's unique per user if at least that user plays by the rules. - RFC 6120 stanza id attribute on messages can be unique within that stream or globally unique (per RFC 6120 ยง 8.1.3). There is no MUST in there, so one may argue that no uniquness guarantee is provided, but explicitly no global uniqueness. Interestingly in XEP-0045 v1.31+, there is a rule that MUCs SHOULD reflect the original message stanza id on reflected messages, which implies that there is not even a by-stream uniqueness guarantee on the message id as other MUC occupants can reuse prior message ids and thus cause a collision of message stanza id on a stream (and still be fully standards compliant).
  254. igoose has joined
  255. moparisthebest has left
  256. moparisthebest has joined
  257. larma Technically there is no uniqueness guarantees on <origin-id> whatsoever, only <stanza-id> are unique per generating entity (as specified in their by attribute)
  258. Yagiza has left
  259. Yagiza has joined
  260. Yagiza has left
  261. Yagiza has joined
  262. lovetox yes larma, but all you need is unique within an archive
  263. lovetox and this is guaranted by mam
  264. Nekit has joined
  265. larma for mam that's guaranteed through <stanza-id>, not message id or <origin-id>
  266. larma but there are many other use cases that use a message id (or origin/stanza id)
  267. lovetox_ has joined
  268. ralphm has left
  269. igoose has left
  270. lovetox yeah but they are not as important as message deduplication
  271. lovetox so i always thought if a client does not use unique ids, then this feature will just not work good
  272. larma LMC changing the wrong message?
  273. igoose has joined
  274. lovetox yes, of course you can implement LMC badly, then this results in very bad stuff
  275. lovetox but normally you have a timeframe where correction is allowed
  276. lovetox and even if you decide not, then you should always give the user the chance to see all corrections and original messages
  277. lovetox so worst is, the user sees weird stuff
  278. lovetox_ has left
  279. lovetox but most clients use uuids
  280. lovetox and if you implement some timeframe, like message is only allowed to be corrected within 5 minutes
  281. lovetox the chance of weird stuff happening is almost zero
  282. lovetox even with clients who dont use uuids
  283. larma I feel I don't agree with most of what you wrote...
  284. larma "user sees weird stuff" is literally the worst thing that can happen, after all MAM is only one utility to help not doing this
  285. ralphm has joined
  286. larma "message is only allowed to be corrected within 5 minutes" I'd prefer that LMC was not only for the last message and also allow very old messages (up to days are acceptable for me)
  287. larma And even if you allow the user to display corrections, usually users won't do that anyway...
  288. lovetox hey i like it to, but this would depend on a uniqunes guarantee that can never exist
  289. lovetox you can always only trust the other client
  290. lovetox and if you trust message-id
  291. lovetox or some other made up element
  292. lovetox i mean if you feel better, trust origin-id :)
  293. lovetox i think this is the downside of a federated protocol
  294. lovetox make up for it by reducing the damage wrong IDs could make
  295. lovetox 1. timeframe, 2. give user the chance to deactivate lmc for bad contacts
  296. lovetox 3. give full transparancy, dont hide or replace messages
  297. lovetox thats how i deal with this
  298. lovetox if you got a better idea, im very interested
  299. frainz has left
  300. larma origin-id should be unique at least by origin, easiest way to guarantee is to use a proper UUIDv4. If an attacker uses the same origin-id for multiple messages, the later ones can just be ignored completely, nothing to worry about as it is not possible to happen if it's not an attack and attackers are allowed to suffer from their wrongdoings.
  301. frainz has joined
  302. larma But, you can't do the same for message ids as they are not unique by origin, so duplicate message ids are allowed to happen
  303. lovetox im not following, so you plan that i can correct ANY message i ever sent you whenever i want
  304. lovetox what is there to attack?!
  305. lovetox i can already replace any message
  306. lovetox and just in case we are not talking about the same thing, IDs should always every matched in the database with a (jid, id) tuple
  307. frainz has left
  308. frainz has joined
  309. lovetox there is zero abuse potential other then your contact abuses his own messages he sent you, in that case just stop talking with this dude
  310. Yagiza has left
  311. larma Maybe the name "attacker" was misleading here, I meant an entity that does not correctly implement origin-id and generates the same origin-id twice. Those would suffer from degraded usability (easiest is to ignore the messages with duplicated origin-id). However a user sending the same message id twice should not suffer from degraded usability (i.e. the message should be displayed as usual) as this is perfectly standards compliant behavior
  312. lovetox are we still talking about LMC?
  313. lovetox if someone sends 2 messages with the same id, and afterwards a correction for that id
  314. lovetox just take the more recent one
  315. lovetox i dont need origin-id for that and i dont need to ignore a message
  316. larma There is no reason why message correction should always reference the latest instance of a message id, the user might have intended to do something different. Message correction might be a bad example as those always originate from the sender and usually the same client (though this is not necessarily the case). However if you pick other usages of ids, you'll even get more problems. Like message attaching might attach to the wrong message or something
  317. valo has left
  318. valo has joined
  319. larma If you use the message id for message attaching (as suggested as a fallback when there is no origin-id in the XEP) you have the risk of this happening, as a client might not be able to know where to attach that message. So best would be to not allow attaching to messages that don't have an origin-id. But now apparently everyone for some reason tries to not implement origin-id
  320. kokonoe has left
  321. lovetox the reason is easy, there are already 2 other ids we manage
  322. kokonoe has joined
  323. lovetox so if we need a third one, it should be a damn good reason
  324. larma There is your reason ๐Ÿ˜‰
  325. larma And: if you don't want to support it on the receving end, at least support it as a sender for those clients that want to use it on the receiving end
  326. larma If your message id is already generated using UUIDv4, you'd just have to send the origin-id as well and be done with all the work on the sending side (I assume you already store your message id, so you will be able to handle any usages of the origin-id automatically if it is the same)
  327. lovetox the scenarios you think up seem unrealistic
  328. lovetox you talk to a contact, that has a client who sends the same message id over and over
  329. lovetox but for some reason its still so advanced that it supports message attaching
  330. lovetox so the client should now add origin-id instead of just making his message-id a uuid
  331. lovetox why cant the XEP not just say, clients who want to support message attaching should generate unique message-id
  332. larma The client sending the message and the client being able to display the message attaching must not necessarily be the same
  333. pep. lovetox, yeah I guess that would have the same effect? (mandating that clients generate unique @id)
  334. larma How do you mandate legacy clients?
  335. larma They are already out there, we can't change it afterwards.
  336. pep. If they want to implement XEP-foobar, this XEP can say "if you implement me you need to do X"
  337. pep. In practice it's a similar solution to origin-id
  338. pep. I guess XEP-foobar could say "you need to implement origin-id"
  339. lovetox larma, i dont have a problem with legacy clients having degraded experience
  340. pep. Same here
  341. lovetox but yeah message attaching is a bit unique, i have to look into it more
  342. lovetox LMC is really not a problem at all, with clients that use the same ids over and over
  343. lovetox i wonder how i would display message attaching on the sender side
  344. lovetox would i also only link in my own database to the id
  345. lovetox or would i copy the message im attaching and adding it in some other database column
  346. zach has left
  347. zach has joined
  348. lovetox i think i would just copy the message into some "attached_data" column
  349. lovetox that way i dont even have to care about if the other client uses unique ids
  350. lovetox if he uses unique ids he sees the correct stuff, if not, he doesnt implement message attaching anyway and will not see it
  351. larma OK, completely realistic scenario: - On my desktop I am using some legacy client that does reuse message ids and does not support message attaching - On my phone I use a modern client that does support message attaching I send a message from my desktop, the recipient attaches a message to my message, I send another message from my desktop that happenns to have the same message id. I open my phone, the message attachment is attached to the wrong message. Even if the XEP of message attaching would require a unique message id, that would not apply to the legacy client, because it doesn't implement the XEP and the recipient does not know if the message id is unique, so can only guess. If the XEP would require origin-id, it would be missing from the legacy client and thus the recipient would be unable to attach to their message
  352. lovetox larma i agree origin-id would solve this case
  353. larma We could also replace origin-id by an empty <origin-id /> to signal that the message id was unique, but we need this information to be transported in the message.
  354. lovetox just upgrading your desktop client would also
  355. lovetox hm actually i like that idea, to add an empty element
  356. larma The desktop client is allowed to not send a unique id as long as they don't implement a XEP that does require them to. And I am pretty certain there are still a lot of clients that don't do unique ids
  357. larma Maybe we want to add this as on option to XEP-0359
  358. larma Make 'id' optional on <origin-id> if the id of the surrounding stanza already provides the uniqueness guarantees for <origin-id>
  359. Lance empty element would reintroduce the problem the origin-id is there to mitigate: MUCs rewriting the message ids. you'd lose the original id iagain n that case
  360. lovetox Lance, but this was fixed in the MUC XEP
  361. larma Lance, true for MUCs, but for non-MUCs the 'id' could still be optional
  362. larma lovetox, it's an optional feature of MUCs
  363. larma to keep the ID when reflecting
  364. Lance let me know when the jdev follows the latest MUC XEP
  365. Lance let me know when the jdev room follows the latest MUC XEP
  366. Lance unfortunately :/
  367. lovetox Im not sure what your argument is, we have to stay compatible with old outdated software only because it is compliant with some XEP
  368. larma Introducing new requirements in a MUC is not really possible, there will always be legacy servers, only way would be to not connect to those anymore
  369. lovetox i couldnt care less about jabber.org
  370. lovetox if users tell me Gajim doesnt work with jabber.org, i tell them, go use another server
  371. lovetox not rewrite Gajim
  372. larma lovetox, > The service SHOULD reflect the message with the same 'id' that was generated by the client, to allow clients to track their outbound messages. If the client did not provide an 'id', the server MAY generate an 'id' and use it for all reflections of the same message (e.g. using a UUID as defined in RFC 4122 [18]).
  373. alacer has left
  374. lovetox im fine with indicating with origin-id that a client uses a unique id
  375. lovetox i think thats a fine use for origin-id
  376. lovetox if you want to change your behavior on that, fine, i think would not have the motiviation
  377. lovetox and fyi Gajim sets origin-id since forever :)
  378. larma I wasn't talking about Gajim, I was talking about you suggesting pep. not to do it
  379. lovetox yes, message attaching is to new, i didnt look into it
  380. lovetox i stand by my opinion that for all other XEPs, like LMC you dont really need this
  381. lovetox and i think, all clients who support mam, support unique ids
  382. lovetox and you would never use a client without mam in a multi client setup
  383. larma You don't need it for LMC, but need it as soon as it becomes MC without L
  384. lovetox so yeah i agree there are edge cases like the one you told, but im not sure we should put to much effort into supporting these
  385. lovetox but adding <origin-id/> to indicate unique ids, is not that much effort :)
  386. larma I doubt pep. intention was to actually use a different ID for message @id and <origin-id>
  387. lovetox what i really would like to prevent is adding another db column "origin-id"
  388. larma I understand your point from a dev perspective ๐Ÿ˜‰
  389. lovetox omg, jabber.ru does not send the muc subject on join
  390. lovetox if no subject is set
  391. lovetox do i interpret this correctly
  392. lovetox https://xmpp.org/extensions/xep-0045.html#order
  393. lovetox that a room subject MUST be sent, even if there is none?
  394. Zash correct
  395. lovetox i guess users will not join mucs without subject anymore with the next Gajim version :D
  396. Zash Prosody didn't send empty subjects in some earlier version but it's been fixed for some time. Not sure about other implementations.
  397. madhur.garg has joined
  398. rion has left
  399. rion has joined
  400. eevvoor Why does jabber.ru not send it? Is is due to the server they use? I thought it is a client issue, so how does it affect jabber.ru lovetox?
  401. Steve Kille has joined
  402. lovetox i think jabber.ru uses some very old ejabberd version
  403. lovetox so they dont profit from bugfixes
  404. lovetox eevvoor, the MUC xep mandates that a subject has to be sent, and gajim waits for it
  405. lovetox and if it never comes, the joining process is never completed
  406. ralphm That's silly. I've seen Gajim have more issues like that.
  407. eevvoor ah thus not the server sw is the prob but the missing updates :D. Reminds me of the so beloved ccc server. Badly administrated ...
  408. lovetox ralphm, whats silly about it?
  409. lovetox should we expect servers not following xeps now or what
  410. eevvoor yes lovetox you should support backcompatibility forever!!!elven111! XD
  411. ralphm lovetox: I agree servers must send it, but waiting on it, even if other stuff for the room comes in, seems silly
  412. lovetox so i guess self presence is has 110 status code is also silly?
  413. lovetox i mean if there is other stuff coming in, no need for that
  414. lovetox subject is the line between history messages, and live messages
  415. lovetox its the order of events, it indicates that history messages is complete and the join is full completed
  416. lovetox that means i can tell the user, now you can send messages
  417. ralphm I understand what it is for
  418. lovetox and not in between a history message fetch
  419. eevvoor so it carries kin of semantics, lovetox, in your opinion.
  420. eevvoor so it carries kind of semantics, lovetox, in your opinion.
  421. ralphm What I don't understand is that it stays in limbo forever
  422. eevvoor But of course it is nice if the client is robust and works well if the xep is not met, ralphm ?
  423. eevvoor So to avoid limbo?
  424. lovetox ralphm, of course i could add a timeout
  425. lovetox but all clients have to add this workaround
  426. eevvoor also not nice, in case it is just delayed ...
  427. lovetox or one server can just send a subject
  428. lovetox ...
  429. eevvoor many combinations to be considered ...
  430. ralphm lovetox: this is what I mean. A timeout would take care of not keeping the user in limbo in the face of broken servers
  431. eevvoor Hm but timeouts can result in strange bugs.
  432. ralphm Another example: when Slack still had an XMPP gateway, it didn't respond to the iq for private storage. This would also hang Gajim indefinitely.
  433. ralphm I manually patched Gajim to work around this.
  434. eevvoor dining philosophers ...
  435. lovetox working around servers that dont answer IQs, ok
  436. ralphm Why? That's a MUST too
  437. igoose has left
  438. lovetox but you still accept it
  439. lovetox and worked around it
  440. lovetox i mean answering IQs is one of the most basic rules in all of XMPP
  441. lovetox if we cant depend on that anymore ..
  442. ralphm I am more of the 'expect failure' variety.
  443. lovetox its a fine line
  444. ralphm And this example was extra tricky, because it is part of the Gajim connect sequence, not a random iq that is sent amongst other things.
  445. igoose has joined
  446. ralphm Of course I also reported it as a serious bug with Slack.
  447. ralphm And not getting a response for private storage shouldn't block the UI to look like the connection is not ready.
  448. ralphm So a timeout would have been a better approach, or async handling.
  449. lovetox yes i agree, its not anymore btw, requesting bookmarks is now independent of connection process
  450. lovetox only server disco info, roster, and roster delimiter iqs are now in the connection process
  451. ralphm Good
  452. Mikaela has left
  453. Lance has left
  454. goffi has left
  455. frainz has left
  456. frainz has joined
  457. eevvoor has left
  458. Lance has joined
  459. andy has left
  460. lovetox_ has joined
  461. lovetox_ has left
  462. waqas has left
  463. andy has joined
  464. igoose has left
  465. igoose has joined
  466. lnj has left
  467. lovetox has left
  468. benne has left
  469. benne has joined
  470. andy has left
  471. andy has joined
  472. andy has left
  473. andy has joined
  474. igoose has left
  475. igoose has joined
  476. igoose has left
  477. UsL has left
  478. UsL has joined
  479. Lance has left
  480. igoose has joined