XSF Discussion - 2021-02-24


  1. Vaulor has left
  2. deuill has joined
  3. LNJ has left
  4. eevvoor has joined
  5. mukt2 has joined
  6. Lance has left
  7. mukt2 has left
  8. emus has left
  9. karoshi has joined
  10. alameyo has joined
  11. Seve has left
  12. debacle has left
  13. paul has left
  14. mukt2 has joined
  15. mukt2 has left
  16. karoshi has left
  17. Lance has joined
  18. stp has joined
  19. alameyo has left
  20. stp has left
  21. lovetox_ has left
  22. stp has joined
  23. Lance has left
  24. mukt2 has joined
  25. qnix has left
  26. mukt2 has left
  27. Andrzej has joined
  28. Adi has left
  29. Andrzej has left
  30. qnix has joined
  31. Adi has joined
  32. wladmis has joined
  33. Andrzej has joined
  34. wladmis has left
  35. wladmis has joined
  36. wladmis has left
  37. wladmis has joined
  38. qnix has left
  39. qnix has joined
  40. wladmis has left
  41. Andrzej has left
  42. wladmis has joined
  43. wladmis has left
  44. wladmis has joined
  45. wladmis has left
  46. wladmis has joined
  47. wladmis has left
  48. wladmis has joined
  49. stp has left
  50. qnix has left
  51. SamWhited Looks like this co-op magazine about the web might be taking submissions if anyone is a good writer and wants to make a few extra dollars while writing about XMPP: https://compost.digital/
  52. jcbrand has joined
  53. Andrzej has joined
  54. wladmis has left
  55. wurstsalat has left
  56. qnix has joined
  57. govanify has left
  58. govanify has joined
  59. govanify has left
  60. govanify has joined
  61. Seve has joined
  62. chronosx88 has left
  63. chronosx88 has joined
  64. chronosx88 has left
  65. chronosx88 has joined
  66. Adi has left
  67. chronosx88 has left
  68. chronosx88 has joined
  69. Adi has joined
  70. chronosx88 has left
  71. chronosx88 has joined
  72. qnix has left
  73. Andrzej has left
  74. qnix has joined
  75. Vaulor has joined
  76. govanify has left
  77. govanify has joined
  78. lskdjf has left
  79. Yagiza has joined
  80. DebXWoody has left
  81. DebXWoody has joined
  82. andy has joined
  83. Tobias has joined
  84. dancanns has joined
  85. dancanns has left
  86. Andrzej has joined
  87. krauq has left
  88. qnix has left
  89. qnix has joined
  90. krauq has joined
  91. paul has joined
  92. ti_gj06 has joined
  93. ti_gj06 has left
  94. ti_gj06 has joined
  95. andy has left
  96. andy has joined
  97. jcbrand has left
  98. wurstsalat has joined
  99. govanify has left
  100. govanify has joined
  101. nyco has left
  102. Mikaela has joined
  103. nyco has joined
  104. wladmis has joined
  105. Andrzej has left
  106. wladmis has left
  107. emus has joined
  108. govanify has left
  109. govanify has joined
  110. mathijs has left
  111. derdaniel has left
  112. derdaniel has joined
  113. mathijs has joined
  114. chronosx88 has left
  115. chronosx88 has joined
  116. chronosx88 has left
  117. chronosx88 has joined
  118. qnix has left
  119. wladmis has joined
  120. nyco has left
  121. qnix has joined
  122. Andrzej has joined
  123. nyco has joined
  124. wladmis has left
  125. wladmis has joined
  126. wladmis has left
  127. wladmis has joined
  128. wladmis has left
  129. wladmis has joined
  130. qnix has left
  131. wladmis has left
  132. wladmis has joined
  133. floretta has left
  134. floretta has joined
  135. wladmis has left
  136. wladmis has joined
  137. wladmis has left
  138. wladmis has joined
  139. wladmis has left
  140. wladmis has joined
  141. debacle has joined
  142. wladmis has left
  143. wladmis has joined
  144. wladmis has left
  145. wladmis has joined
  146. Andrzej has left
  147. Andrzej has joined
  148. mdosch has left
  149. mdosch has joined
  150. paul has left
  151. qnix has joined
  152. paul has joined
  153. Andrzej has left
  154. wladmis has left
  155. wladmis has joined
  156. david has left
  157. david has joined
  158. jcbrand has joined
  159. Viktor has joined
  160. qnix has left
  161. qnix has joined
  162. goffi has joined
  163. karoshi has joined
  164. qnix has left
  165. wladmis has left
  166. wladmis has joined
  167. stp has joined
  168. derdaniel has left
  169. derdaniel has joined
  170. wladmis has left
  171. wladmis has joined
  172. Zash has left
  173. Andrzej has joined
  174. purplebeetroot has left
  175. goffi has left
  176. derdaniel has left
  177. derdaniel has joined
  178. wladmis has left
  179. wladmis has joined
  180. stp has left
  181. stp has joined
  182. nyco has left
  183. paul has left
  184. wladmis has left
  185. wladmis has joined
  186. wladmis has left
  187. wladmis has joined
  188. wladmis has left
  189. wladmis has joined
  190. qnix has joined
  191. wladmis has left
  192. wladmis has joined
  193. wladmis has left
  194. wladmis has joined
  195. wladmis has left
  196. wladmis has joined
  197. qnix has left
  198. wladmis has left
  199. wladmis has joined
  200. alameyo has joined
  201. goffi has joined
  202. MattJ SamWhited: > Does it matter if you include <after> in Result Set management, but also set after-id in the MAM form? Does the latest ID win? The form is the filter query, RSM is for paging through the results of the query.
  203. Zash has joined
  204. chronosx88 has left
  205. chronosx88 has joined
  206. LNJ has joined
  207. alameyo has left
  208. Steve Kille has left
  209. Viktor has left
  210. wladmis has left
  211. wladmis has joined
  212. jonas’ form is where, RSM is limit
  213. Steve Kille has joined
  214. jonas’ form is WHERE, RSM is LIMIT
  215. paul has joined
  216. Viktor has joined
  217. Zash And OFFSET
  218. jonas’ yep
  219. Zash Except how do you offset on an id?
  220. Andrzej has left
  221. jonas’ yes, it’s better than SQL in that regard
  222. jonas’ but semantically it’s that
  223. wladmis has left
  224. goffi has left
  225. wladmis has joined
  226. Mikaela has left
  227. Wojtek has joined
  228. nyco has joined
  229. Mikaela has joined
  230. x51 has joined
  231. alameyo has joined
  232. esil has joined
  233. esil has left
  234. wladmis has left
  235. wladmis has joined
  236. qnix has joined
  237. wladmis has left
  238. wladmis has joined
  239. Maranda has left
  240. Andrzej has joined
  241. x51 has left
  242. wladmis has left
  243. wladmis has joined
  244. Andrzej has left
  245. chronosx88 has left
  246. chronosx88 has joined
  247. esil has joined
  248. esil has left
  249. wladmis has left
  250. wladmis has joined
  251. wladmis has left
  252. wladmis has joined
  253. wladmis has left
  254. wladmis has joined
  255. Maranda has joined
  256. x51 has joined
  257. Steve Kille has left
  258. Adi has left
  259. Adi has joined
  260. Steve Kille has joined
  261. wladmis has left
  262. esil has joined
  263. esil has left
  264. wladmis has joined
  265. wladmis has left
  266. wladmis has joined
  267. wladmis has left
  268. pasdesushi has joined
  269. goffi has joined
  270. pasdesushi has left
  271. pasdesushi has joined
  272. pasdesushi has left
  273. pasdesushi has joined
  274. pasdesushi has left
  275. pasdesushi has joined
  276. debacle has left
  277. debacle has joined
  278. wladmis has joined
  279. wladmis has left
  280. qnix has left
  281. pasdesushi has left
  282. qnix has joined
  283. Andrzej has joined
  284. esil has joined
  285. esil has left
  286. Guus has joined
  287. purplebeetroot has joined
  288. Andrzej has left
  289. Andrzej has joined
  290. Guus has left
  291. SamWhited RSM has an 'after' concept too though.
  292. Zash SamWhited: I think you misunderstood what was said. The RSM 'after' corresponds to OFFSET in SQL
  293. SamWhited I don't see how that's different than. after-id still
  294. Zash after-id is WHERE RSM after is OFFSET
  295. jonas’ SamWhited, that `after` in MAM-RSM corresponds to the stanza ID is an implementation detail you must not rely on
  296. jonas’ on the surface it doesn’t matter, but there are ugly edge cases and long mailing list discussions which came to be because of the lack of a WHERE which is separate from the RSM-<after/>/<before/>-LIMIT mechanism
  297. Zash The MAM stuff selects a subset of messages. RSM shifts a view over that subset.
  298. qnix has left
  299. wladmis has joined
  300. Zash FWIW while implementing extended MAM in Prosody I cheated and just put the after-id in the same slot in the internal API as the RSM after
  301. Zash But, implementation detail..
  302. jonas’ shush!
  303. Zash Only matters for <count> I think, which should not be affected by RSM parameters, only MAM ones
  304. wladmis has left
  305. wladmis has joined
  306. SamWhited ooh, I need to read RSM again I think then. Are you saying that 'after' is an int, not an ID?
  307. jonas’ SamWhited, no, after is an opaque string
  308. jonas’ you mustn’t interpret it (on the client side anyway)
  309. SamWhited I still have zero concept of what you mean by 'offset' and 'where' then
  310. Zash SamWhited: I think we were talking abstract concepts, not exact SQL mapping
  311. jonas’ I was for sure
  312. Zash OFFSET in SQL is an int, yes. But conceptually you SELECT a range, and then shift the starting point with OFFSET
  313. jonas’ no, you select a *subset of records*
  314. jonas’ not necessarily a range (which is thought of to be regular or consecutive even)
  315. Zash /correct s/range/subset/
  316. Zash I must have thought of a SELECT with only after-id
  317. wladmis has left
  318. wladmis has joined
  319. wladmis has left
  320. wladmis has joined
  321. nyco has left
  322. MattJ Step 1 is to run the query and get the results, step 2 is to return the correct page. If you use <after> in RSM with an id that isn't in the result set you'll get an item-not-found: https://xmpp.org/extensions/xep-0059.html#notfound
  323. MattJ (previous versions of 313 indicated otherwise, but this was fixed in one of the later revisions)
  324. lskdjf has joined
  325. Wojtek has left
  326. wladmis has left
  327. wladmis has joined
  328. nyco has joined
  329. qnix has joined
  330. SamWhited Okay, no longer on a phone and coffee has been aquired, I was hoping that would help, but I still don't see how that's different from after-id. I mean, they both contain "after" in the name and take an ID, they both return an error if the ID doesn't exist.
  331. SamWhited Going back to read the RSM description of "after" now.
  332. Kev It’s not a mechanical objection, AFAICT Sam, but a case of dogma not wanting to use RSM for this. Obviously it worked mechanically using RSM, because that was deployed and working.
  333. SamWhited Kev: I guess that's what I don't get then, it says "use RSM" but then also says "Also here's more form fields that appear the same"
  334. SamWhited Is it just that RSM requires max (I think?) and this is just "after but without requiring a limit"?
  335. SamWhited Or is it that RSM doesn't specify what the ID is and it might be an ID local to the result set and not the actual stanza ID like after-id takes? Although in that case I'd question why it didn't just say "use RSM, and use the stanza ID"
  336. Zash Isn't that exactly what MAM says?
  337. qnix has left
  338. Zash You use RSM, IDs are stanza-ids.
  339. SamWhited Okay, then it definitely seems like exactly the same thing in two places in the sstanza to me
  340. SamWhited Maybe someone can provide a SQL query that includes <after> and after-id how they would translate?
  341. Zash Again, conceptually, after-id would map to `WHERE item_id > after-id` and RSM after would map to `OFFSET after-first.id` or something (excuse the math)
  342. SamWhited So after-id is some sort of string comparison? I dont' get that from reading the XEP
  343. SamWhited Nothing says that IDs have to be ordered as far as I can see
  344. Zash You're still taking this too literally
  345. SamWhited Okay, let's step back then, I don't understand what the difference between WHERE and OFFSET is in that query if it's not "one is doing a string comparison, one is saying 'give me rows that are after this row'"
  346. Zash So yeah in actual SQL it'd be more like `WHERE _internal_id > (SELECT _internal_id WHERE id=$after_id}`
  347. Zash Unless you actually do have ordered IDs
  348. SamWhited That seems *exactly* the same as offset then
  349. Zash But we can't count on that, it's an implementation detail
  350. Zash It's not
  351. Zash You could implement it either way, but it's not the same, conceptually.
  352. SamWhited I guess I don't see how. Or if they are the same but just "different conceptually" why bother having both?
  353. wladmis has left
  354. SamWhited Let me try this: would I ever actually *use* both in a MAM query?
  355. Zash You could also implement it by not having any limit, collect *all* the results and then throw away items until you go past the RSM after id
  356. Zash Then the MAM fields go in the SQL, RSM go into cropping the results afterwards
  357. purplebeetroot has left
  358. SamWhited Where does it say that?
  359. Zash Using both after-id and rsm after would be ponitless yes.
  360. SamWhited So what is the point of having both if using them both would be pointless?
  361. wladmis has joined
  362. wladmis has left
  363. SamWhited Or does it actually specify how I should implement it somewhere?
  364. Zash It's written a bit up where MattJ said so.
  365. SamWhited That's just an error that gets returned?
  366. Zash > Step 1 is to run the query and get the results, step 2 is to return the correct page.
  367. Zash That part
  368. SamWhited Where does the XEP say that though?
  369. SamWhited And why would it force an implementation detail like that on me?
  370. SamWhited Eg. wouldn't I just have a single concept of "give me stuff after this ID" and then if I wanted to just directly query for that vs. query for everything, cache those results, and return subsets of them as more queries come in entirely my decision and I wouldn't need two afters to indicate either thing?
  371. wladmis has joined
  372. MattJ Step 1: you want to query the archive between two ids Step 2: You formulate the query using after-id and before-id Step 3: You send the query to the server Step 4: The server returns the results, but there are many, so it returns the first page of 20 stanzas Step 5: You make a second request with the same query parameters, but specify <after>last-id-in-the-page</after> in your RSM payload
  373. MattJ You *could* just update after-id in the query parameters, you'll get the same messages
  374. SamWhited Why not just make the query specifying <after> to start with, is what I'm asking?
  375. edhelas "how to mimic SQL requests on top of a protocol where the server is actually doing SQL requests behind"
  376. MattJ after-id didn't always exist, and it has different semantics (e.g. you can't specify before+after in RSM)
  377. MattJ But yes, they do overlap, but they are conceptually different
  378. Zash It matters more for before, since that implicitly makes it so you start at the end of the results and page backwards
  379. SamWhited I don't see why MAM couldn't just say "if before and after are in RSM it's a range in this spec", but okay, that's the first thing that's vaguely sounded like a real difference to me, thanks
  380. MattJ So I recommend using each one for its intended purpose
  381. SamWhited ahhh, okay, before meaning you go backwards makes sense, so it would need a different concept I guess. That's absolutely infuriating, but makes sense.
  382. wladmis has left
  383. wladmis has joined
  384. SamWhited Okay, I dunno, I guess I still don't see why MAM couldn't just specify that, but I guess it's a tiny bit weird modifying RSM behavior just for one spec. This seems like a major failure of RSM though that we had to include another concept of the exact same thing, but also sort of use RSM but only sometimes, etc.
  385. MattJ I think RSM is pretty good at what it's designed for
  386. MattJ It's not designed for querying
  387. SamWhited Fair enough; seems like it just shouldn't be used in MAM at all then.
  388. MattJ and the alternative would be duplicating all the paging syntax and semantics into MAM
  389. ti_gj06 has left
  390. ti_gj06 has joined
  391. purplebeetroot has joined
  392. SamWhited Maybe I'm really the only one who's confused by this, but that would seem to be better. If RSM just doesn't work for what MAM's trying to do, shoehorning it in and duplicating some of its concepts just seems confusing to me.
  393. MattJ It does work
  394. MattJ RSM is not for querying, MAM is not for paging
  395. MattJ I really don't see the problem :)
  396. MattJ Unless you choose to confuse the two
  397. SamWhited That seems like a distinction without a difference to me in this particular case.
  398. MattJ If you choose to treat them as the same thing, then you're inviting confusion in edge cases
  399. SamWhited I dunno, maybe I'm just being obtuse since no one else seems to have a problem with this, but saying "there's after and there's after, they do the same thing but one of them is for querying initially and one is for subsequent queries to get pages later" just seems insane
  400. MattJ I don't see a problem with "here is a query", and "here is how you access further pages of the same query"
  401. SamWhited But again, I seem to be the only one confused by this so I guess I'm wrong 🤷\
  402. MattJ You decide what results you are interested in, and then you page through until you're done
  403. wladmis has left
  404. wladmis has joined
  405. SamWhited And the spec says *none* of this as far as I can tell. There was one throw away comment about how after/before behavior wasn't defined in RSM, that's it I think
  406. SamWhited The spec just leaves you wondering why after-id and after aren't the same thing.
  407. MattJ Says none of what exactly?
  408. MattJ "A client or server will typically want to limit the number of results transmitted at a time, thereby breaking the result stream into smaller 'pages'. For this purpose a server MUST support Result Set Management (XEP-0059) [4] and MUST support the paging mechanism defined therein."
  409. MattJ That's the section that introduces RSM
  410. SamWhited Doesn't say that RSM is for querying after the first query and after-id is for the first query or whwhatever
  411. MattJ Because that's not the case
  412. SamWhited It just introduces two concepts, after and after-id that at first glance appear identical.
  413. SamWhited I swear that's literally what you just said, no?
  414. MattJ RSM is not designed for querying
  415. MattJ Yes, you can get the same result set two different ways (after-id or using RSM) in specific query types
  416. MattJ But you're designing an API here
  417. pasdesushi has joined
  418. MattJ So this should be of benefit to you, you need to get it right
  419. Zash grep vs more ?
  420. SamWhited "filtering vs. querying" then. The point is that the spec just says "you can use RSM, it has after, there is also after-id in the form" (not an actual quote, obviously).
  421. MattJ 1. choose the results you are interested in 2. select the page
  422. MattJ In an API these things should be 100% different
  423. MattJ For some queries (where you only care about ids), sure, you could do everything with RSM
  424. MattJ For anything more complex, they are not the same thing
  425. SamWhited I'm not sure if this is offtopic or not, because I honestly can't tell how it applies to after-id vs. after. But when zash says "grep vs more" or MattJ says "1. choose the results you are interested in 2. select the page", does it matter that I'm doing that behind thes scenes? I'm not sure how to phrase this, but that just sounds like an implementation detail that doesn't matter.
  426. SamWhited I would probably *never* do that in an implementation. I would always just make small queries, return results. Those results include info for making the next query. I would never actually pull out the entire archive within a range and then allow smaller queries to be filtered on that.
  427. SamWhited I can't tell if it actually matters for this discussion though.
  428. MattJ Just make your API nice, I don't care what mechanics you use if it works and is a nice API
  429. MattJ If you do it wrong I just reserve the right to never look at the code :)
  430. nyco has left
  431. Half-Shot has left
  432. uhoreg has left
  433. Matthew has left
  434. Rixon 👁🗨 has left
  435. pasdesushi has left
  436. Half-Shot has joined
  437. Matthew has joined
  438. Rixon 👁🗨 has joined
  439. uhoreg has joined
  440. SamWhited I *think* my API is nice, but as far as I can tell no matter how complex the query you could set the ID in after or after-id *unless* you need a window and want to set after/before. So the XMPP API still seems really weird to me.
  441. SamWhited (assuming you're using an ID and want stuff after it at all, I mean, obviously you could also set neither for the initial query)
  442. SamWhited So I can do what you say and use after-id the first time and <after> afterwards, it just seems worth clarifying in the XEP that you should always do that.
  443. MattJ You don't just use after-id the first time, you can include it every time
  444. SamWhited Oh crap, okay, now I'm back to square one and have no idea what you're talking about or why I'd do that.
  445. MattJ Ok, if we're back to square one then I have better things to do :)
  446. MattJ Just implement it, I'm sure you'll manage
  447. SamWhited Maybe it really is just me in which case fair enough, but I really don't see how this distinction isn't confusing and doesn't need to be clarified in the XEP.
  448. nyco has joined
  449. MattJ Also consider whether you want to make RSM reusable in your codebase
  450. MattJ Because it sounds like you're not even considering that
  451. SamWhited RSM is already resuable in the codebase.
  452. MattJ But you don't want to reuse it for some reason, even though MAM explicitly allows it
  453. MattJ You would rather recalculate MAM query parameters instead of just tacking on the RSM page request
  454. SamWhited I mean, I want to reuse it if it fits, but it sounds like MAM is having to partially re-invent it which is just confusing.
  455. MattJ I don't care what you do, but anything else seems more work
  456. MattJ MAM is not partially reinventing it because RSM does *not* do querying
  457. MattJ If you read the XEP that's pretty clear
  458. SamWhited I don't have to recalculate anything, it sounds like *exactly* the same thing to me which is what I still don't get. You make a query, get results back. You make another query and change <after> (or after-id) to the last one you got from the previous query.
  459. Viktor has left
  460. MattJ The RSM XEP, that is
  461. SamWhited MAM you have to make a query. RSM picks the page you get. I get that, I just don't see how it changes that after and after-id are the same thing.
  462. MattJ If you start with a time range query you're not just changing after-id, you're adding it. And if you want the last page first, what are you going to do then?
  463. MattJ Yes, I 100% agree that in some cases you can achieve the same query in two different ways
  464. MattJ I 100% don't think that this is something that needs to take up an afternoon of discussion
  465. MattJ If your API has the concept of a query, and the concept of a page, they map perfectly to MAM and to RSM
  466. SamWhited > If you start with a time range query you're not just changing after-id, you're adding it. Sure, but that would be the exact same thing still if you use after-id or <after>, right? Yes, you can also make other queries, I don't see how that changes anything. > > And if you want the last page first, what are you going to do then? You make the query using <before/> just like both MAM and RSM say to do, it has nothing to do with after/after-id being duplicated?
  467. MattJ if you want to conflate the two, feel free to do that
  468. eevvoor has left
  469. qnix has joined
  470. SamWhited Okay, I dunno, I don't think I'm conflating anything and I don't see why that distinction should even exist, which is what's concerning me, but I'll go re-read the relavant sections of MAM again and see if I can find anthing that clarifies this that I might have forgotten. Thanks for your help.
  471. SamWhited This is just driving me *nuts* because I don't understand the miscommunication. I'm not sure if I'm asking something wrong or there's some assumption others have that I don't, or what. It literally seems like we just have two identical things in the XEP and the only reason is that *technically* there is some slightly semantic difference in the words we use to describe them but no practical difference.
  472. Zash I couldn't consume coffee fast enough to keep up.
  473. Andrzej has left
  474. ti_gj06 has left
  475. SamWhited Okay, sorry, last thing just to make sure I'm being absolutely clear about what's confusing me with a practical example, then I'll just give up and go re-read MAM again:
  476. SamWhited Is there any difference in results that should be returned for the following two queries: https://gist.github.com/SamWhited/bdc7b2465a5f91d92bc881a3367d97d3
  477. wladmis has left
  478. wladmis has joined
  479. wladmis has left
  480. Zash SamWhited: Same messages, but they might differ on <rsm:count>
  481. Half-Shot has left
  482. uhoreg has left
  483. Matthew has left
  484. Rixon 👁🗨 has left
  485. Half-Shot has joined
  486. Matthew has joined
  487. Rixon 👁🗨 has joined
  488. uhoreg has joined
  489. nyco has left
  490. wladmis has joined
  491. mathijs has left
  492. mathijs has joined
  493. SamWhited ahhhh, okay, that's the difference, I understand now I think.
  494. goffi has left
  495. Andrzej has joined
  496. SamWhited There is actually a thing that would change, not just some vague semantic difference in wording but in practice they're identical.
  497. wladmis has left
  498. SamWhited I am not sure what I should have asked to get at that sooner, but maybe the lesson is "always include examples".
  499. Zash Since that count is the count of the whole set, if no RSM or limits were involved. But it's also not guaranteed to be exact.
  500. MattJ or present
  501. Zash Examples good.
  502. SamWhited Sure, I definitely wouldn't include that (it's very expensive in postgres without lots of hackery), but at least there is a real practical difference between the two concepts now.
  503. MattJ There already was (besides the few offered earlier)
  504. Zash I think in Prosody we only include it if you also ask for rsm:max=0
  505. MattJ Anyway, back to work
  506. wladmis has joined
  507. wladmis has left
  508. wladmis has joined
  509. SamWhited Going back I don't see how I would have gotten there from any of the previous replies, they all seem to sound like "sure, they're identical, but we can use different words to describe them"
  510. SamWhited I'm sure I was jus tasking something weird though and not making the confusion clear.
  511. SamWhited (ignoring the before/after thing, that one I agree is vaguely a reason, it just also seems like it would have been easy enough to do in MAM)
  512. wladmis has left
  513. wladmis has joined
  514. wladmis has left
  515. wladmis has joined
  516. wladmis has left
  517. wladmis has joined
  518. wladmis has left
  519. wladmis has joined
  520. wladmis has left
  521. nyco has joined
  522. L29Ah has left
  523. wladmis has joined
  524. L29Ah has joined
  525. wladmis has left
  526. wladmis has joined
  527. Kev It is possible that not using RSM at all would be sensible. It would certainly be possible.
  528. wladmis has left
  529. Kev It seemed like a good idea at the time, though.
  530. wladmis has joined
  531. wladmis has left
  532. wladmis has joined
  533. SamWhited To be clear, I am not advocating for a specific solution. I wasn't even sure there was a problem. I was just trying to understand why both after/after-id existed (or, with the reason I was given, why it actually matters). I think "count would be different" is the reason.
  534. wladmis has left
  535. nyco has left
  536. raghavgururajan has left
  537. jcbrand has left
  538. wladmis has joined
  539. wladmis has left
  540. wladmis has joined
  541. wladmis has left
  542. wladmis has joined
  543. millesimus has left
  544. wladmis has left
  545. wladmis has joined
  546. wladmis has left
  547. wladmis has joined
  548. Andrzej has left
  549. wladmis has left
  550. wladmis has joined
  551. wladmis has left
  552. wladmis has joined
  553. wladmis has left
  554. wladmis has joined
  555. millesimus has joined
  556. Andrzej has joined
  557. wladmis has left
  558. wladmis has joined
  559. wladmis has left
  560. wladmis has joined
  561. goffi has joined
  562. wladmis has left
  563. nyco has joined
  564. paul has left
  565. wladmis has joined
  566. qnix has left
  567. wladmis has left
  568. ti_gj06 has joined
  569. Andrzej has left
  570. qnix has joined
  571. wladmis has joined
  572. wladmis has left
  573. Lance has joined
  574. qnix has left
  575. qnix has joined
  576. arcxi has left
  577. arcxi has joined
  578. Andrzej has joined
  579. arcxi has left
  580. arcxi has joined
  581. qnix has left
  582. wladmis has joined
  583. wladmis has left
  584. paul has joined
  585. wladmis has joined
  586. arcxi has left
  587. arcxi has joined
  588. arcxi has left
  589. arcxi has joined
  590. arcxi has left
  591. arcxi has joined
  592. arcxi has left
  593. arcxi has joined
  594. eevvoor has joined
  595. wladmis has left
  596. wladmis has joined
  597. wladmis has left
  598. wladmis has joined
  599. SamWhited MattJ: are there any pending TODOs on MAM? Would you mind if the editor did another LC?
  600. MattJ Nothing pending, no
  601. SamWhited Would you mind if a LC happened then? There is one "FIXME" in the text that I can propose an editorial change for after work, but otherwise I'd like to see it advance if possible.
  602. SamWhited (unless of course you'd prefer to do it as the author, I just thought I'd offer)
  603. wladmis has left
  604. wladmis has joined
  605. MattJ Nope, go for it
  606. SamWhited Thanks
  607. SamWhited /cc whomever the editor is these days. jonas’ maybe?
  608. MattJ The last revision was intended to be the last revision, I just wanted to wait a while for feedback
  609. MattJ It's been a while, so I'm happy with moving it on now
  610. Kev Maybe I should actually read the latest version :D
  611. jonas’ SamWhited, ACK, maybe ask for LC together with your PR is easiest
  612. SamWhited MattJ: that's sort of what I was thinking. Given how small and mostly-inactive this community is, I figure just doing a LC is probably the best way to actually get people to look at it :)
  613. jonas’ SamWhited, ACK, maybe ask for LC together with your PR that should be easiest
  614. jonas’ Kev, well, that’s what the LC is for :)
  615. MattJ I also gave plenty of opportunity for feedback before submitting the revision too, so another argument for moving ahead
  616. SamWhited Will do.
  617. jonas’ SamWhited, thanks!
  618. Kev jonas’: Well, kinda. I’m Author too ;)
  619. Zash Haha
  620. arcxi has left
  621. jonas’ Kev, are you sure? ;)
  622. arcxi has joined
  623. Kev :(
  624. ti_gj06 has left
  625. qnix has joined
  626. jcbrand has joined
  627. wladmis has left
  628. stpeter has joined
  629. stpeter has left
  630. wladmis has joined
  631. ti_gj06 has joined
  632. fuana has joined
  633. arc has joined
  634. arc Meeting time?
  635. jonas’ arc, wrong day of week?
  636. jonas’ or did board reschedule?
  637. arc We rescheduled
  638. MattJ Wait what
  639. jonas’ oh, was that not announced on board@?
  640. jonas’ oh, in the minutes
  641. fuana has left
  642. wladmis has left
  643. MattJ I guess I should have read those more thorougly
  644. MattJ It's very unlikely I'll be able to attend
  645. arc I would happily be wrong on this
  646. ralphm We could skip though, since we're only half a week on
  647. arc I'm cool with that
  648. ralphm MattJ, does the new slot work in general?
  649. arc I just got out of the ER with extremely high blood pressure
  650. ralphm Dude. Take care of yourself first.
  651. ralphm I make it motion if necessary
  652. ralphm I'll make it a motion if necessary
  653. wladmis has joined
  654. jonas’ floor comment: I support that motion
  655. Andrzej has left
  656. ralphm Motion carries :D
  657. jonas’ ralphm, MR 20201126T15:04:59Z 000 <MattJ>  I generally have a hard cut-off at 1700Z in winter, 1600Z in summer
  658. mathijs has left
  659. jonas’ followed-up by: MR 20201126T15:07:53Z 000 <MattJ>  If we must, I can probably do that on a Thursday or Friday, at least during the winter
  660. millesimus has left
  661. ralphm Sorry my exocortex didn't raise that
  662. wladmis has left
  663. millesimus has joined
  664. ralphm not banging the gavel for the Board Meeting => +1W
  665. pasdesushi has joined
  666. wladmis has joined
  667. mathijs has joined
  668. Maranda has left
  669. Maranda has joined
  670. fuana has joined
  671. pasdesushi has left
  672. pasdesushi has joined
  673. mimi89999 has left
  674. wladmis has left
  675. mimi89999 has joined
  676. MattJ I can't do this time on any Wednesday and sensibly participate. My wife is working and I look after the children 😕
  677. andrey.g has joined
  678. Andrzej has joined
  679. pasdesushi has left
  680. pasdesushi has joined
  681. ti_gj06 has left
  682. fuana has left
  683. fuana has joined
  684. ralphm Ok. Back to the drawing board then
  685. wladmis has joined
  686. pasdesushi has left
  687. pasdesushi has joined
  688. Steve Kille has left
  689. wladmis has left
  690. wladmis has joined
  691. pasdesushi has left
  692. pasdesushi has joined
  693. pasdesushi has left
  694. pasdesushi has joined
  695. Steve Kille has joined
  696. pasdesushi has left
  697. pasdesushi has joined
  698. qnix has left
  699. pasdesushi has left
  700. pasdesushi has joined
  701. goffi has left
  702. neshtaxmpp has left
  703. pasdesushi has left
  704. xecks has left
  705. pasdesushi has joined
  706. mimi89999 has left
  707. mimi89999 has joined
  708. wladmis has left
  709. pasdesushi has left
  710. wladmis has joined
  711. xecks has joined
  712. werdan has joined
  713. pasdesushi has joined
  714. pasdesushi has left
  715. mimi89999 has left
  716. mimi89999 has joined
  717. pasdesushi has joined
  718. govanify has left
  719. govanify has joined
  720. mimi89999 has left
  721. mimi89999 has joined
  722. pasdesushi has left
  723. qnix has joined
  724. mimi89999 has left
  725. mimi89999 has joined
  726. mukt2 has joined
  727. fuana has left
  728. mukt2 has left
  729. mimi89999 has left
  730. mimi89999 has joined
  731. qnix has left
  732. Viktor has joined
  733. Andrzej has left
  734. Andrzej has joined
  735. Yagiza has left
  736. fuana has joined
  737. x51 has left
  738. raghavgururajan has joined
  739. ti_gj06 has joined
  740. x51 has joined
  741. raghavgururajan has left
  742. raghavgururajan has joined
  743. fuana has left
  744. x51 has left
  745. x51 has joined
  746. x51 has left
  747. x51 has joined
  748. x51 has left
  749. x51 has joined
  750. x51 has left
  751. x51 has joined
  752. x51 has left
  753. x51 has joined
  754. x51 has left
  755. x51 has joined
  756. x51 has left
  757. x51 has joined
  758. x51 has left
  759. x51 has joined
  760. x51 has left
  761. x51 has joined
  762. x51 has left
  763. ti_gj06 has left
  764. x51 has joined
  765. x51 has left
  766. x51 has joined
  767. emus Have you tried using those appointment finding polls?
  768. ti_gj06 has joined
  769. DebXWoody OpenPGP for XMPP - Context IM Is there a valid use case where a user has two OpenPGP keys which both are associated with one XMPP account?
  770. qnix has joined
  771. x51 has left
  772. x51 has joined
  773. x51 has left
  774. x51 has joined
  775. x51 has left
  776. x51 has joined
  777. qnix has left
  778. ti_gj06 has left
  779. x51 has left
  780. x51 has joined
  781. wladmis has left
  782. x51 has left
  783. x51 has joined
  784. x51 has left
  785. x51 has joined
  786. arcxi has left
  787. lovetox_ has joined
  788. lovetox_ has left
  789. x51 has left
  790. x51 has joined
  791. x51 has left
  792. x51 has joined
  793. arcxi has joined
  794. Mikaela has left
  795. ti_gj06 has joined
  796. x51 has left
  797. Andrzej has left
  798. werdan has left
  799. x51 has joined
  800. werdan has joined
  801. pasdesushi has joined
  802. pasdesushi has left
  803. pasdesushi has joined
  804. arcxi has left
  805. x51 has left
  806. pasdesushi has left
  807. pasdesushi has joined
  808. vanitasvitae I mean, the spec does not forbid it
  809. vanitasvitae DebXWoody ^
  810. vanitasvitae So why noz
  811. qnix has joined
  812. pasdesushi has left
  813. pasdesushi has joined
  814. vanitasvitae I think thats partly why there is the metadata node with public key list: https://xmpp.org/extensions/xep-0373.html#announcing-pubkey-list
  815. Mikaela has joined
  816. DebXWoody (on one device ). To have more keys in general (multi device) yes. But about more than one key in one local keyring.
  817. lovetox_ has joined
  818. arcxi has joined
  819. vanitasvitae I think there is no point in that. Then again I see no interop-concerns if a device has two secret keys. There might be a use-case for that as well (different keys presented to different contacts, like a work-key and a free-time key?)
  820. vanitasvitae But other devices would simply see two keys as if they would belong to different devices as there is no binding between devices and keys
  821. vanitasvitae So if your client wants to allow two secret keys on a device, I see no issues with that 😀
  822. pasdesushi has left
  823. pasdesushi has joined
  824. fuana has joined
  825. pasdesushi has left
  826. pasdesushi has joined
  827. goffi has joined
  828. DebXWoody I won't 😆 The user has to choose which key he will use to sign a message. I was thinking to show an error, but I don't know of there may some use cases.
  829. pasdesushi has left
  830. pasdesushi has joined
  831. andrey.g has left
  832. x51 has joined
  833. arcxi has left
  834. pasdesushi has left
  835. Andrzej has joined
  836. arcxi has joined
  837. vanitasvitae if I'd implement OX, I'd either generate a key for the user, or if the user can provide their own keys, I'd ask them for the key-ID they want to use 🙂
  838. fuana has left
  839. vanitasvitae btw. DebXWoody are you subscribed to standards@?
  840. vanitasvitae I just dropped a mail asking for possible dates for a regular OX meeting 😉
  841. chronosx88 has left
  842. chronosx88 has joined
  843. Tim has joined
  844. pasdesushi has joined
  845. pasdesushi has left
  846. pasdesushi has joined
  847. pasdesushi has left
  848. fuana has joined
  849. arcxi has left
  850. goffi has left
  851. goffi has joined
  852. Andrzej has left
  853. Tim has left
  854. arcxi has joined
  855. qnix has left
  856. deuill has left
  857. Andrzej has joined
  858. qnix has joined
  859. mathijs has left
  860. mathijs has joined
  861. fuana has left
  862. deuill has joined
  863. alex-a-soto has left
  864. deuill has left
  865. deuill has joined
  866. purplebeetroot has left
  867. Half-Shot has left
  868. uhoreg has left
  869. Matthew has left
  870. Rixon 👁🗨 has left
  871. Half-Shot has joined
  872. Matthew has joined
  873. Rixon 👁🗨 has joined
  874. uhoreg has joined
  875. pasdesushi has joined
  876. pasdesushi has left
  877. pasdesushi has joined
  878. pasdesushi has left
  879. Viktor has left
  880. werdan has left
  881. Andrzej has left
  882. goffi has left
  883. qnix has left
  884. x51 has left
  885. Tobias has left
  886. Half-Shot has left
  887. uhoreg has left
  888. Matthew has left
  889. Rixon 👁🗨 has left
  890. Half-Shot has joined
  891. Matthew has joined
  892. Rixon 👁🗨 has joined
  893. uhoreg has joined
  894. arcxi has left
  895. lskdjf has left
  896. neshtaxmpp has joined
  897. qnix has joined
  898. Andrzej has joined
  899. andy has left
  900. ti_gj06 has left
  901. qnix has left
  902. Maranda has left
  903. Maranda has joined
  904. Andrzej has left
  905. Andrzej has joined
  906. arcxi has joined
  907. amuza@riseup.net has left
  908. amuza@riseup.net has joined
  909. Andrzej has left
  910. qnix has joined
  911. neshtaxmpp has left
  912. lovetox_ has left
  913. alameyo has left
  914. lskdjf has joined
  915. neshtaxmpp has joined
  916. qnix has left
  917. Half-Shot has left
  918. uhoreg has left
  919. Matthew has left
  920. Rixon 👁🗨 has left
  921. Half-Shot has joined
  922. Matthew has joined
  923. Rixon 👁🗨 has joined
  924. uhoreg has joined
  925. alameyo has joined
  926. debacle has left
  927. Andrzej has joined
  928. Mikaela has left
  929. wladmis has joined
  930. wladmis has left
  931. wladmis has joined