XMPP Council - 2023-02-22


  1. moparisthebest has left

  2. moparisthebest has joined

  3. MSavoritias (fae,ve) has joined

  4. gooya has left

  5. MSavoritias (fae,ve) has left

  6. Tobias has joined

  7. Tobias has left

  8. Ingolf has left

  9. Ingolf has joined

  10. pprrks has left

  11. pprrks has joined

  12. mdosch has joined

  13. Tobias has joined

  14. Tobias has left

  15. Tobias has joined

  16. marc0s has left

  17. marc0s has joined

  18. MSavoritias (fae,ve) has joined

  19. emus has joined

  20. pprrks has left

  21. pprrks has joined

  22. neox has joined

  23. Kev has joined

  24. pprrks has left

  25. marc0s has left

  26. marc0s has joined

  27. pprrks has joined

  28. marc0s has left

  29. marc0s has joined

  30. marc0s has left

  31. marc0s has joined

  32. marc0s has left

  33. marc0s has joined

  34. pprrks has left

  35. pprrks has joined

  36. marc0s has left

  37. marc0s has joined

  38. marc0s has left

  39. marc0s has joined

  40. marc0s has left

  41. marc0s has joined

  42. gooya has joined

  43. marc0s has left

  44. marc0s has joined

  45. marc0s has left

  46. marc0s has joined

  47. marc0s has left

  48. marc0s has joined

  49. vaulor has left

  50. vaulor has joined

  51. pprrks has left

  52. pprrks has joined

  53. pprrks has left

  54. marc0s has left

  55. marc0s has joined

  56. moparisthebest has left

  57. marc0s has left

  58. marc0s has joined

  59. vaulor has left

  60. vaulor has joined

  61. pprrks has joined

  62. pprrks has left

  63. moparisthebest has joined

  64. marc0s has left

  65. marc0s has joined

  66. pprrks has joined

  67. pprrks has left

  68. pprrks has joined

  69. marc0s has left

  70. marc0s has joined

  71. larma

    👋

  72. Ge0rG

    😜

  73. marc0s has left

  74. marc0s has joined

  75. jonas’

    o/

  76. daniel

    Hi

  77. daniel

    1) Roll call

  78. jonas’

  79. moparisthebest

    Hello

  80. daniel

    I don’t think we have anything to talk about. the editor isn’t active currently

  81. daniel

    so instead of running through an empty agenda I’m just going to jump to AOB

  82. daniel

    does anyone have any AOB?

  83. jonas’

    I do not

  84. Ge0rG

    none here

  85. moparisthebest

    Nope

  86. larma

    No

  87. daniel

    ok. that was uneventful again

  88. daniel

    see you all next week

  89. moparisthebest

    See you then, thanks

  90. jonas’

    see ya

  91. pprrks has left

  92. Ingolf has left

  93. Ingolf has joined

  94. pprrks has joined

  95. neox has left

  96. neox has joined

  97. neox has left

  98. mdosch has left

  99. mdosch has joined

  100. marc0s has left

  101. marc0s has joined

  102. sonny has left

  103. marc0s has left

  104. marc0s has joined

  105. marc0s has left

  106. marc0s has joined

  107. sonny has joined

  108. Tobias has left

  109. Tobias has joined

  110. larma

    Just noticed during the discussion about XEP-0359 (stanza-id): XEP-0313 (MAM) was advanced to stable but depends on XEP-0359 which is still experimental/deferred. This shouldn't be possible. Maybe we should soon issue a last call for XEP-0359 (even though there are discussions about it right now) to fix that situation?

  111. Tobias has left

  112. Tobias has joined

  113. marc0s has left

  114. marc0s has joined

  115. marc0s has left

  116. marc0s has joined

  117. Ge0rG

    Am I going to be hated by everyone if I veto until <origin-id/> is burned out with napalm?

  118. larma

    I'd be fine to get rid of origin-id, but it still has it's usecase (reflection detection in MUCs that don't do the non-RFC-compliant stable-id thing)

  119. Zash

    This is the XSF. You can do anything at the XSF! The the only limit is XEP-0001.

  120. Ge0rG

    larma: how many of those MUCs are still in place [and don't also strip any XML payload besides of <body>, I'm looking at you, biboumi]

  121. larma

    probably not a lot

  122. Tobias has left

  123. Tobias has joined

  124. larma

    that's why I say I'm fine with getting rid of it 😉

  125. tmolitor

    didn't we have some informal consensus / business rule that said that an origin-id and a is on the stanza having the same value (and proper by attribute) means that the client uses something sufficiently random like uuids to generate the id?

  126. tmolitor

    that said, a disco feature indicating that the ids are sufficiently random (128bit of entropy, uuid, whatever) would be a better solution, imho...

  127. larma

    tmolitor, not strictly "sufficiently random" (because that's only recommended by 0359), but it requires them to be a) unique at the sender and b) not predictable - which is hard to achieve without actually using sufficient randomness :)

  128. marc0s has left

  129. tmolitor

    yeah...that one :)

  130. tmolitor

    was that written down anywhere?

  131. Zash

    disco is dead, MAM killed it :(

  132. marc0s has joined

  133. larma

    technically a client could generate a salt at start and then for every outgoing stanza hash that salt together with the nanoseconds since start of the client. That wouldn't be a lot of entropy, but for all practical purposes, this would be as good as a random uuid.

  134. Zash

    There exists a perfect way to generate unique stanza ids

  135. Zash

    (stream-id, counter++)

  136. Zash

    (pass trough hash or HMAC or something)

  137. Ingolf has left

  138. larma

    tmolitor, well origin-id as per 0359 requires: > the IDs defined in this extension MUST be unique and stable within the scope of the generating XMPP entity. > The values of the 'id' attribute SHOULD be unpredictable. Thus if a client generates an origin-id and puts the same id into the message's id-attribute, you know it's sufficiently random.

  139. tmolitor

    larma: depends on the entropy of the salt ;)

  140. marc0s has left

  141. marc0s has joined

  142. Ge0rG

    All the good clients already use that in stanza IDs, and if you rely on a third party client doing it for your database access or anything, you are in for a tough ride.

  143. larma

    We can also just define a new XEP to define the <good-id /> element that declares that the generation of the message's id-attribute followed certain rules.

  144. Ge0rG

    Which problem does that solve, again?

  145. larma

    some legacy clients generating id's be generating 16 bit of randomness at start and then counting up from that with every stanza and therefor likely running into collisions without bad intent

  146. larma

    some legacy clients generating ids by generating 16 bit of randomness at start and then counting up from that with every stanza and therefor likely running into collisions without bad intent

  147. Ge0rG

    Collisions of what exactly?

  148. daniel

    Anything that references that id

  149. daniel

    Edits. Replies

  150. daniel

    Reactions

  151. larma

    In direct chats only, of course

  152. daniel

    Yes

  153. daniel

    And edits in muc

  154. Tobias has left

  155. Ge0rG

    Which only affects the user of the broken client when also using a modern client

  156. Tobias has joined

  157. Ge0rG

    But the broken client won't generate an adequate ID for referencing anyway

  158. Tobias has left

  159. Tobias has joined

  160. larma

    Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id

  161. Ge0rG

    You need to send a message from pidgin, then edit it from a modern client

  162. Ge0rG

    Disabling a feature because of an opaque thing the user has no visibility of sounds like a bad idea

  163. tmolitor

    +1 for the <good-id/> element

  164. daniel

    > Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id Yes and origin ID is an OK detection for whether or not the other client is same

  165. Tobias has left

  166. daniel

    > Yes, and thus the replying/reacting client should not allow the user to send replies/reactions to such message with broken id Yes and origin ID is an OK detection for whether or not the other client is sane

  167. Tobias has joined

  168. daniel

    Origin ID is essentially good-id

  169. tmolitor

    yes, but with an additional id value that we could get rid of...

  170. daniel

    Why come up with a new element that does the same thing minus muc reflection

  171. daniel

    Then mandate message id==origin id

  172. daniel

    For the sender

  173. Ge0rG

    Are you actually disabling sophisticated features on messages without origin-id?

  174. Ge0rG

    daniel [20:37]: > Then mandate message id==origin id I've been asking for that since day 1

  175. daniel

    Me too

  176. Ingolf has joined

  177. Tobias has left

  178. tmolitor

    > Then mandate message id==origin id that would be ideal, what is blocking that?

  179. Tobias has joined

  180. Ge0rG

    yaxim will generate sufficiently random IDs but not set origin-id

  181. Ge0rG

    tmolitor: the author

  182. Tobias has left

  183. Tobias has joined

  184. tmolitor

    on what basis?

  185. Ge0rG

    It's not technically required

  186. Tobias has left

  187. Tobias has joined

  188. larma

    When I write that "best practices on using IDs" XEP (with how to reference messages depending on context), I'll definitely add that origin-id should be same as message id 🙂

  189. larma

    Not technically requires, but definitely a best practice.

  190. larma

    Not technically required, but definitely a best practice.

  191. larma

    Ge0rG, well, clients already have to limit some features for some messages. Because there exist messages without any id, makign it very hard to reference them 😉

  192. daniel

    I'm gonna block stanza id unless this must is in stanza id

  193. tmolitor

    > I'm gonna block stanza id unless this must is in stanza id wait, what? what id are you referring to exactly?

  194. marc0s has left

  195. marc0s has joined

  196. daniel

    The xep

  197. marc0s has left

  198. marc0s has joined

  199. daniel

    I think the only reason it's not in the xep is that it's slightly complicated to do in smack

  200. larma

    you mean "If the <origin-id /> element is present, the origin sender MUST set the message's id-attribute to the same value as the id-attribute of the <origin-id /> element." should be in XEP-0359? Rather than kicking origin-id out entirely?

  201. Ge0rG

    Can't you just accept any ID with more than four characters and be done?

  202. daniel

    > you mean "If the <origin-id /> element is present, the origin sender MUST set the message's id-attribute to the same value as the id-attribute of the <origin-id /> element." should be in XEP-0359? Rather than kicking origin-id out entirely? If that wording is in 359 it becomes functionally equivalent to <good-id/>

  203. daniel

    We could just remove origin id entirely. But it seems fairly well established for a good-id replacement

  204. Zash

    <good-id/> meaning that <message id=good> ?

  205. Ge0rG

    And you have an excuse to block out perfectly working clients from modern features

  206. daniel

    > <good-id/> meaning that <message id=good> ? Yes

  207. marc0s has left

  208. marc0s has joined

  209. Zash

    Sure would help against my feeling that modern XMPP is full of redundant duplicated IDs and timestamps and also redundancy

  210. Ge0rG

    Zash: also duplicate information

  211. marc0s has left

  212. marc0s has joined

  213. marc0s has left

  214. marc0s has joined

  215. marc0s has left

  216. marc0s has joined

  217. marc0s has left

  218. marc0s has joined

  219. marc0s has left

  220. Tobias has left

  221. marc0s has joined

  222. Tobias has joined

  223. Tobias has left

  224. Tobias has joined

  225. Tobias has left

  226. Tobias has joined

  227. Tobias has left

  228. Tobias has joined

  229. Tobias has left

  230. Tobias has joined

  231. Tobias has left

  232. Tobias has joined

  233. Tobias has left

  234. Tobias has joined

  235. Tobias has left

  236. Tobias has joined

  237. marc0s has left

  238. marc0s has joined

  239. Tobias has left

  240. Tobias has joined

  241. Tobias has left

  242. Tobias has joined

  243. marc0s has left

  244. marc0s has joined

  245. marc0s has left

  246. marc0s has joined

  247. pprrks has left

  248. marc0s has left

  249. marc0s has joined

  250. pprrks has joined

  251. tmolitor

    > I'm gonna block stanza id unless this must is in stanza id +1 for this MUST

  252. marc0s has left

  253. marc0s has joined

  254. marc0s has left

  255. marc0s has joined

  256. marc0s has left

  257. marc0s has joined

  258. marc0s has left

  259. marc0s has joined

  260. marc0s has left

  261. marc0s has joined

  262. marc0s has left

  263. marc0s has joined

  264. marc0s has left

  265. marc0s has joined

  266. marc0s has left

  267. marc0s has joined

  268. marc0s has left

  269. marc0s has joined

  270. marc0s has left

  271. marc0s has joined

  272. marc0s has left

  273. marc0s has joined

  274. MSavoritias (fae,ve) has left

  275. marc0s has left

  276. marc0s has joined

  277. paul has left

  278. marc0s has left

  279. marc0s has joined

  280. paul has joined

  281. Tobias has left

  282. Kev has left

  283. pprrks has left

  284. marc0s has left

  285. marc0s has joined

  286. neox has joined

  287. Tobias has joined

  288. pprrks has joined

  289. Tobias has left