jdev - 2021-01-24

  1. goffi has left

  2. adityaborikar has joined

  3. SouL has left

  4. gav has left

  5. gav has joined

  6. adityaborikar has left

  7. asterix has left

  8. asterix has joined

  9. adityaborikar has joined

  10. wurstsalat has left

  11. floretta has left

  12. asterix has left

  13. asterix has joined

  14. stpeter has joined

  15. mikeye has joined

  16. stpeter has left

  17. kikuchiyo has left

  18. gav has left

  19. mikeye has left

  20. sonny has left

  21. sonny has joined

  22. debacle has left

  23. gav has joined

  24. sonny has left

  25. sonny has joined

  26. stpeter has joined

  27. gav has left

  28. gav has joined

  29. sonny has left

  30. sonny has joined

  31. sonny has left

  32. sonny has joined

  33. stpeter has left

  34. sonny has left

  35. sonny has joined

  36. adityaborikar has left

  37. sonny has left

  38. sonny has joined

  39. adityaborikar has joined

  40. sonny has left

  41. sonny has joined

  42. sonny has left

  43. sonny has joined

  44. sonny has left

  45. sonny has joined

  46. sonny has left

  47. sonny has joined

  48. sonny has left

  49. sonny has joined

  50. mikeye has joined

  51. stpeter has joined

  52. sonny has left

  53. sonny has joined

  54. chunk has joined

  55. chunk has left

  56. raghavgururajan has left

  57. stpeter has left

  58. SouL has joined

  59. sonny has left

  60. sonny has joined

  61. sonny has left

  62. sonny has joined

  63. sonny has left

  64. sonny has joined

  65. paul has joined

  66. sonny has left

  67. sonny has joined

  68. sonny has left

  69. sonny has joined

  70. mikeye has left

  71. mikeye has joined

  72. sonny has left

  73. sonny has joined

  74. stpeter has joined

  75. blabla has joined

  76. marmistrz has joined

  77. stpeter has left

  78. sonny has left

  79. sonny has joined

  80. goffi has joined

  81. mikeye has left

  82. mikeye has joined

  83. belong has left

  84. Porru has joined

  85. wurstsalat has joined

  86. paul has left

  87. sonny has left

  88. sonny has joined

  89. marc has joined

  90. adityaborikar has left

  91. mikeye has left

  92. asterix has left

  93. asterix has joined

  94. paul has joined

  95. goffi has left

  96. asterix has left

  97. asterix has joined

  98. floretta has joined

  99. asterix has left

  100. adityaborikar has joined

  101. asterix has joined

  102. goffi has joined

  103. belong has joined

  104. marc has left

  105. marc has joined

  106. asterix has left

  107. asterix has joined

  108. asterix has left

  109. asterix has joined

  110. paul has left

  111. paul has joined

  112. paul has left

  113. paul has joined

  114. marmistrz has left

  115. stpeter has joined

  116. lovetox

    any client dev here that preservs notifications across app restarts?

  117. lovetox

    i would be intersted how this is implementd

  118. marmistrz has joined

  119. stpeter has left

  120. marmistrz has left

  121. xecks has left

  122. debacle has joined

  123. xecks has joined

  124. raghavgururajan has joined

  125. asterix has left

  126. asterix has joined

  127. asterix has left

  128. asterix has joined

  129. asterix has left

  130. asterix has joined

  131. asterix has left

  132. asterix has joined

  133. asterix has left

  134. asterix has joined

  135. asterix has left

  136. asterix has joined

  137. Alex has left

  138. Alex has joined

  139. asterix has left

  140. asterix has joined

  141. Yagizа has joined

  142. asterix has left

  143. asterix has joined

  144. asterix has left

  145. asterix has joined

  146. o2 has left

  147. asterix has left

  148. asterix has joined

  149. asterix has left

  150. asterix has joined

  151. asterix has left

  152. asterix has joined

  153. belong has left

  154. belong has joined

  155. mac has joined

  156. moparisthebest has left

  157. moparisthebest has joined

  158. stpeter has joined

  159. mac has left

  160. adityaborikar has left

  161. stpeter has left

  162. debacle has left

  163. adityaborikar has joined

  164. kikuchiyo has joined

  165. paul has left

  166. paul has joined

  167. belong has left

  168. belong has joined

  169. Zash has left

  170. Zash has joined

  171. goffi has left

  172. belong has left

  173. belong has joined

  174. goffi has joined

  175. moparisthebest has left

  176. moparisthebest has joined

  177. Porru has left

  178. Porru has joined

  179. floretta has left

  180. Porru has left

  181. Porru has joined

  182. Porru has left

  183. Porru has joined

  184. stpeter has joined

  185. Yagizа has left

  186. Yagizа has joined

  187. Porru has left

  188. Porru has joined

  189. asterix has left

  190. asterix has joined

  191. stpeter has left

  192. Porru has left

  193. Porru has joined

  194. belong has left

  195. stefan has joined

  196. belong has joined

  197. Porru has left

  198. Porru has joined

  199. Porru has left

  200. Porru has joined

  201. floretta has joined

  202. marmistrz has joined

  203. Porru has left

  204. stpeter has joined

  205. belong has left

  206. Porru has joined

  207. belong has joined

  208. Sam Whited

    I see in RFC 6120 that there is a rule that says that IDs must be unpredictable (of course), but I thought it also said that you must not attribute any meaning to them. I don't see that anywhere now though. Is this actually a rule somewhere for ID attributes or did I just dream it up? I know it's true for resourceparts, so maybe I'm just remembering that and getting confused

  209. Zash

    What's the meaning of "meaning"?

  210. Sam Whited

    eg. if I abuse IDs as an extension point and send "<stanzacount>-randomstuff" or something as the ID instead of using stream management acks (or anything really, just embedding some info in the ID). I'm trying to convince someone not to do this, but I can't find anything to quote that actually makes it illegal

  211. Sam Whited

    (they're not doing that specific example, I just made that up, I have no idea what they want to shove into the ID)

  212. marmistrz has left

  213. Sam Whited

    It's this PR that someone opened that I'm trying to formulate a response to in case anyone else wants to comment that this is a bad idea: https://github.com/mattn/go-xmpp/pull/128

  214. flow

    Sam Whited, xep359 (stanza-id) has that

  215. flow

    potentially you are confusing if with that?

  216. Zash

    flow, which words say that?

  217. Sam Whited

    flow: that's probably what I'm remembering. Drat, that doesn't help me though since now my argument has to be "this is a bad idea, just use XML" instead of "this is illegal, read the RFC" :)

  218. flow

    Zash, "The value of the 'id' attribute should not provide any further information besides the opaque ID itself."

  219. flow

    I note that this is not RFC keyworded

  220. flow

    And that ejabberd does not follow that

  221. flow

    and that I think that ejabberd has a good case for not following it

  222. Zash

    YOLO I'm using "date-random" in my IDs

  223. Sam Whited

    flow: what does ejabberd do? I wasn't aware they were doing anything like this

  224. Zash

    as in yyyy-mm-dd-xxxxxxxx

  225. flow

    Sam Whited, I think they simply use a nano or microseconds timestamp as ID

  226. Sam Whited


  227. Zash

    That's actually a sensible thing I wanna do too

  228. flow

    I think the eww'nes potentially depends on the use case

  229. flow

    On the one side, it sure is always a good idea to not leak information

  230. Zash

    High-precision timestamp as ID, so you can sort things by it.

  231. flow

    OTOH, it is really tempting to use timestamps for those IDs, and what could potentially go wrong?

  232. Sam Whited

    That bothers me a lot. To be fair, I don't have a good reason why, it just seems like if you're going to do that you should put a <timestamp/> element or attribute or something in there and sort by that

  233. flow

    eventually I think it is good that xep359 only recommends to not put any semantic in the ID, and it is good that implementations do not have to follow this

  234. Zash

    Semantics for yourself, but there's the risk of other entities starting to rely on that

  235. Zash

    It is kinda handy to encode data in IDs so you can do stateless things

  236. Holger

    Right, that's what ejabberd is doing in the IQ 'id' case.

  237. Holger

    (Not for sorting stuff but for routing responses without keeping state.)

  238. flow

    I guess as long as the next 'id' value is not predictable

  239. Sam Whited

    That makes sense to a certain extent if it's in an opaque way I suppose and not any info that someone else might decide is useful, rely on, and turn into a defacto API, but I don't know how to argue for "this is only okay sometimes"

  240. Holger

    flow: Nope, there's a random part.

  241. o2 has joined

  242. Zash

    High-precision timestamp with random noise in lowest bits. Mmmmmm.

  243. Holger

    Sam Whited: I'm not sure I'll buy this risk of my peers potentially doing stopid things as a show-stopper for me doing sane things. (While I would buy security worries of course.)

  244. jonas’

    Do not look at this: https://modules.prosody.im/mod_client_proxy.html

  245. Sam Whited

    Holger: I don't think it means you shouldn't do it, but I don't think that means we should encourage it and add specific library support for it.

  246. jonas’

    ~Do not look at this: https://modules.prosody.im/mod_client_proxy.html~ nevermind, that does resource things, not ID things.

  247. Sam Whited

    If I were starting from scratch I would probably make it illegal so that most things wouldn't support it, then if you wanted to support it "who cares?" It's not breaking anything and if you accept the risk you can do it.

  248. Sam Whited

    Anyways, sounds like it's not actually forbidden, so I'll have to make my argument some other way.

  249. Yagizа has left

  250. Porru has left

  251. asterix has left

  252. asterix has joined

  253. marmistrz has joined

  254. stpeter has left

  255. alacer has joined

  256. alacer has left

  257. asterix has left

  258. asterix has joined

  259. asterix has left

  260. asterix has joined

  261. asterix has left

  262. asterix has joined

  263. asterix has left

  264. asterix has joined

  265. debacle has joined

  266. Porru has joined

  267. Porru has left

  268. Porru has joined

  269. stefan has left

  270. marc has left

  271. Porru has left

  272. Porru has joined

  273. kikuchiyo has left

  274. kikuchiyo has joined

  275. stpeter has joined

  276. Porru has left

  277. Porru has joined

  278. stpeter has left

  279. marmistrz has left

  280. kikuchiyo has left

  281. kikuchiyo has joined

  282. kikuchiyo has left

  283. kikuchiyo has joined

  284. goffi has left

  285. goffi has joined

  286. Porru has left

  287. Porru has joined

  288. goffi has left

  289. Kev

    There are some limited cases where M-Link uses IDs for encoding information, too.

  290. Kev

    Although I hope to remove them at some point.

  291. Porru has left

  292. Porru has joined

  293. moparisthebest has left

  294. kikuchiyo has left

  295. kikuchiyo has joined

  296. Porru has left

  297. Porru has joined

  298. Porru has left

  299. Porru has joined

  300. Porru has left

  301. Porru has joined

  302. moparisthebest has joined

  303. blabla has left

  304. goffi has joined

  305. stpeter has joined

  306. asterix has left

  307. asterix has joined

  308. asterix has left

  309. asterix has joined

  310. asterix has left

  311. asterix has joined

  312. stpeter has left

  313. goffi has left

  314. lovetox has left

  315. lovetox has joined

  316. xecks has left

  317. xecks has joined

  318. lovetox has left

  319. oibalos has left

  320. xecks has left

  321. paul has left

  322. asterix has left

  323. asterix has joined

  324. wurstsalat has left

  325. asterix has left

  326. asterix has joined