jdev - 2023-01-11

  1. rubi has left

  2. edhelas has left

  3. Millesimus has left

  4. edhelas has joined

  5. rubi has joined

  6. atomicwatch has left

  7. Millesimus has joined

  8. kapad has left

  9. selurvedu has joined

  10. rubi has left

  11. rubi has joined

  12. Millesimus has left

  13. debacle has left

  14. marc0s has left

  15. marc0s has joined

  16. Millesimus has joined

  17. rubi has left

  18. menel has left

  19. rubi has joined

  20. menel has joined

  21. jgart has left

  22. Millesimus has left

  23. wurstsalat has left

  24. selurvedu has left

  25. Millesimus has joined

  26. rubi has left

  27. rubi has joined

  28. menel has left

  29. rubi has left

  30. rubi has joined

  31. menel has joined

  32. jgart has joined

  33. Millesimus has left

  34. Trung has left

  35. Schimon_ has left

  36. rubi has left

  37. rubi has joined

  38. menel has left

  39. u has left

  40. u has joined

  41. thomaslewis has joined

  42. marc0s has left

  43. marc0s has joined

  44. Millesimus has joined

  45. rubi has left

  46. rubi has joined

  47. Millesimus has left

  48. rubi has left

  49. rubi has joined

  50. Millesimus has joined

  51. adx has left

  52. rubi has left

  53. Millesimus has left

  54. Yagizа has joined

  55. Millesimus has joined

  56. rubi has joined

  57. Millesimus has left

  58. Millesimus has joined

  59. rubi has left

  60. Millesimus has left

  61. marc0s has left

  62. marc0s has joined

  63. Millesimus has joined

  64. Millesimus has left

  65. Millesimus has joined

  66. sponji has left

  67. Millesimus has left

  68. rubi has joined

  69. sponji has joined

  70. Millesimus has joined

  71. marc0s has left

  72. marc0s has joined

  73. hearty has left

  74. hearty has joined

  75. Millesimus has left

  76. nicoco has joined

  77. Millesimus has joined

  78. Beherit has joined

  79. antranigv has joined

  80. antranigv has left

  81. antranigv has joined

  82. antranigv has left

  83. Yagizа has left

  84. Yagizа has joined

  85. atomicwatch has joined

  86. antranigv has joined

  87. hearty has left

  88. Sam has left

  89. antranigv has left

  90. antranigv has joined

  91. mirux has joined

  92. hearty has joined

  93. thomaslewis has left

  94. sponji has left

  95. sponji has joined

  96. sponji has left

  97. sponji has joined

  98. sponji has left

  99. sponji has joined

  100. sponji has left

  101. sponji has joined

  102. sponji has left

  103. MSavoritias (fae,ve) has joined

  104. sponji has joined

  105. sponji has left

  106. sponji has joined

  107. wurstsalat has joined

  108. sponji has left

  109. sponji has joined

  110. sponji has left

  111. sponji has joined

  112. Sam has joined

  113. u has left

  114. u has joined

  115. Vaulor has left

  116. Alex has left

  117. Alex has joined

  118. Mario Sabatino has joined

  119. Trung has joined

  120. Vaulor has joined

  121. jubalh has joined

  122. pulkomandy has left

  123. Kev has joined

  124. kapad has joined

  125. menel has joined

  126. sponji has left

  127. Beherit has left

  128. goffi has joined

  129. goffi has left

  130. goffi has joined

  131. oshn has left

  132. oshn has joined

  133. debacle has joined

  134. Dele Olajide has joined

  135. u has left

  136. u has joined

  137. goffi has left

  138. goffi has joined

  139. rubi has left

  140. rubi has joined

  141. rubi has left

  142. rubi has joined

  143. rubi has left

  144. rubi has joined

  145. goffi has left

  146. sonny has left

  147. sonny has joined

  148. Vaulor has left

  149. Vaulor has joined

  150. antranigv has left

  151. sponji has joined

  152. sponji has left

  153. rubi has left

  154. sponji has joined

  155. sponji has left

  156. antranigv has joined

  157. sponji has joined

  158. gregory has left

  159. rubi has joined

  160. stuart.j.mackintosh has joined

  161. gregory has joined

  162. atomicwatch has left

  163. sponji has left

  164. rubi has left

  165. rubi has joined

  166. rubi has left

  167. rubi has joined

  168. atomicwatch has joined

  169. atomicwatch has left

  170. sponji has joined

  171. larma has joined

  172. mirux has left

  173. mirux has joined

  174. Millesimus has left

  175. rubi has left

  176. rubi has joined

  177. Beherit has joined

  178. Millesimus has joined

  179. u has left

  180. atomicwatch has joined

  181. u has joined

  182. sponji has left

  183. rubi has left

  184. rubi has joined

  185. stuart.j.mackintosh has left

  186. larma has left

  187. larma has joined

  188. larma has left

  189. larma has joined

  190. goffi has joined

  191. pulkomandy has joined

  192. rubi has left

  193. rubi has joined

  194. PapaTutuWawa has joined

  195. Trung has left

  196. Trung has joined

  197. Trung has left

  198. Trung has joined

  199. stuart.j.mackintosh has joined

  200. goffi has left

  201. Wojtek has joined

  202. wurstsalat has left

  203. wurstsalat has joined

  204. rubi has left

  205. techmetx11 has left

  206. techmetx11 has joined

  207. rubi has joined

  208. Wojtek has left

  209. Wojtek has joined

  210. pulkomandy has left

  211. stuart.j.mackintosh has left

  212. stuart.j.mackintosh has joined

  213. rubi has left

  214. rubi has joined

  215. stuart.j.mackintosh has left

  216. stuart.j.mackintosh has joined

  217. Wojtek has left

  218. goffi has joined

  219. PapaTutuWawa has left

  220. moparisthebest has left

  221. PapaTutuWawa has joined

  222. Dele Olajide has left

  223. edhelas has left

  224. edhelas has joined

  225. Dele Olajide has joined

  226. moparisthebest has joined

  227. kapad has left

  228. stuart.j.mackintosh has left

  229. SouL has left

  230. pep.

    https://xmpp.org/extensions/xep-0060.html#publisher-publish-error-forbidden Any clue what "insufficient privileges" mean in this context? Can a publisher of the node have insufficient privileges?

  231. stuart.j.mackintosh has joined

  232. jonas’

    if you're no publisher, yes

  233. pep.

    But as a publisher?

  234. pep.

    Can one edit/delete other publisher's items for example? Is there such restrictions available?

  235. jonas’

    what's the actual question?

  236. jonas’

    a client always needs to be prepared to handle authorization errors

  237. pep.

    Trying to see what's currently available for moderation on pubsub

  238. jonas’

    depends on the implementation.

  239. jubalh has left

  240. jonas’

    services can do whatever they like

  241. jonas’

    (as long as they return the appropriate responses)

  242. pep.

    That's always a great answer in a standard :P

  243. jonas’

    '60 is quite flexible in that regard

  244. pep.

    Ok, maybe there's some way for servers to advertize capabilities in this regard, so that clients don't need to do trial and error and can avoid providing UI when the feature isn't there or stuff like that

  245. MattJ

    Products vs protocols and all that. The XEP defines a protocol, there are many ways to use it. There is nothing specifically written anywhere about moderation in pubsub, but that doesn't mean it's not possible, and it might be a good idea to write it.

  246. pep.

    I'm planning to have a look at that in the "near future"

  247. SouL has joined

  248. larma has left

  249. larma has joined

  250. rubi has left

  251. Wojtek has joined

  252. SouL has left

  253. SouL has joined

  254. larma has left

  255. larma has joined

  256. sonny has left

  257. flow

    pep., I think this is a prime example for a case where the error response should contain a more refined description of its cause

  258. john-machine has left

  259. pep.

    flow, maybe. I do think (as I said above) that a client should be able to know beforehand it's not authorized to

  260. pep.

    Of course there can be both

  261. jonas’

    pep., agreed though.

  262. jonas’

    it would be good if you could disco#info a node and get a list of all your permissions on a node

  263. larma has left

  264. Kev

    There's assorted places in XMPP where you can't tell if something will succeed until you try, and it's ... not great.

  265. jonas’

    it would be good if you could disco#info a node and get a list of all _your_ permissions on _that_ node

  266. flow

    maybe, I am not sold on that

  267. larma has joined

  268. pep.

    Kev, yeah.. I've seen the last thread on the list about reactions :P

  269. flow

    that appears to be a case where it is better to ask for forgiveness than permission

  270. jonas’

    flow, disagree

  271. pep.

    flow, tell the user that

  272. jonas’

    that's terrible for UIs

  273. pep.


  274. john-machine has joined

  275. flow

    fair point

  276. jonas’

    nice for machine-to-machine, but not good for human interfaces.

  277. Kev

    "Thanks for writing out your thesis. I'm afraid you're not allowed to submit it."

  278. flow

    I wonder if we should design a generic protocol pattern where an operation can be marked as "dry-run" (or "don't do it"). so you can check if you would be allowed to do it

  279. larma has left

  280. larma has joined

  281. pep.

    flow, but then you'd need the content of that operation to be available first?

  282. jonas’

    flow, trying all possible optinos in a UI when showing it is very inefficient

  283. flow

    pep., the content does not matter if it is a dry run

  284. pep.

    it may

  285. sonny has joined

  286. flow

    ok, depends on what you classify as content then

  287. jonas’

    flow, banned words, length limitations, ... there are lots of ways even real content may matter

  288. jonas’

    but also parameters like which item ID you are retracting

  289. flow

    well the item ID could by the correct one

  290. flow

    and for the other parameters you mentioned: those are probably also not discoverable otherwise

  291. pep.

    They could be made available via disco

  292. flow

    you probably can't take everything into consideration, there is a certain tradeoff

  293. pep.

    Well a spec is a living document right? :P

  294. larma has left

  295. pep.

    Surely at some point you'll have an error, and that's where indeed good description of the error is necessary

  296. larma has joined

  297. pep.

    (and i18n)

  298. flow

    I think i18n is secondary to the refined description (but sure can't hurt)

  299. pep.

    As it's likely to be shown straight to the user, I think it's absolutely necessary

  300. jonas’

    flow, ... how is it secondary?

  301. jonas’

    that ^

  302. pep.

    Now of course between what one feels is necessary and implementations progress, there's always a gap

  303. flow

    I believe such refined descriptions cause typically more confusion in case of the average user

  304. flow

    as in non-tech safy

  305. jonas’

    even more important then to know ahead of time whether a thing is allowed

  306. flow


  307. flow

    I wasn't considering the human UI aspect in this discussion (for some reason)

  308. larma has left

  309. larma has joined

  310. larma has left

  311. larma has joined

  312. larma has left

  313. larma has joined

  314. Alex has left

  315. antranigv has left

  316. Alex has joined

  317. jubalh has joined

  318. larma has left

  319. larma has joined

  320. larma has left

  321. larma has joined

  322. rubi has joined

  323. larma has left

  324. larma has joined

  325. stefan has left

  326. stefan has joined

  327. Wojtek has left

  328. Holger has joined

  329. Wojtek has joined

  330. oxtyped has joined

  331. jubalh has left

  332. SouL has left

  333. u has left

  334. u has joined

  335. oxtyped has left

  336. SouL has joined

  337. _root has left

  338. nicoco

    about MAM: do clients actually implement support for <fin stable='false'>, eg, by re-fetching MAM periodically until stable='false' disappear? cf paragraph just above https://xmpp.org/extensions/xep-0313.html#sect-idm46316171986560

  339. MattJ

    "they should"

  340. MattJ

    I suspect they don't :)

  341. MattJ

    It's quite a lot to ask of a client

  342. nicoco

    it's probably hard to get a proper UX around that indeed

  343. pep.

    Typo in the paragraph btw: "it the server could return best-guess results", "it"

  344. pep.

    (or I don't understand the sentence)

  345. hearty has left

  346. hearty has joined

  347. _root has joined

  348. _root has left

  349. antranigv has joined

  350. nicoco

    it's quite tricky for slidge to guarantee stable MAM results for legacy networks that allow message editing (and re(tr)actions…) but I guess always replying to queries with stable=false would be very very very ugly anyway. fastening collation would help a lot, but I hope to figure something out before (if?) it's worked out :(

  351. antranigv has left

  352. Schimon_ has joined

  353. _root has joined

  354. antranigv has joined

  355. antranigv has left

  356. Sam has left

  357. Sam has joined

  358. Kev

    Always replying with stable=false is the right thing to do, though, if the results aren't stable.

  359. MattJ

    The universe is unstable

  360. jonas’

    do not look up false vacuum decay unless you need more existential angst

  361. jonas’

    (speaking of "universe is unstable")

  362. nicoco

    I would be more cautious: _our perception of_ the universe is unstable ;)

  363. MattJ

    Just serve clients stable results, and if they change... just tell them it's only their perception that is unstable

  364. MattJ

    But all this to say, more seriously, that I think some pragmatism is required

  365. nicoco

    sounds like a plan to me! you hated my bug reports already? hold on, it's about to get worse :P

  366. MattJ

    If you serve results and say they are stable, and they later change, the client may not update them. You might or might not care about that.

  367. Kev

    Lots of clients don't have to care about this stuff, because they fetch on demand, but anyone who wants to do a full-MAM-sync client and wants to support clustered servers that can operate in a split mode have to care.

  368. MattJ

    We have the same problem with Matrix bridges

  369. MattJ

    Since the history can change at any time

  370. jonas’

    > Lots of clients [citation needed]

  371. menel has left

  372. Kev

    Ok. Some clients.

  373. MattJ

    It's different to a clustered XMPP instance knowing that the past N entries in the archive haven't been fully replicated and confirmed

  374. MattJ

    In such a setup, both client and server using the 'stable' flag correctly can still achieve consistent synchronized history

  375. Kev

    Right, but even in a situation where no queries are ever stable, it's useful to flag that to a client, isn't it?

  376. Kev

    So that the client knows it can't use a "sync once, and then just catch up" strategy.

  377. MattJ

    Yes, I would agree that if the server judges that clients should not cache the results, it should always set stable=false

  378. pep.

    Would the server flag a full response btw, or would it only flag parts of it? If it knows only a subset is unstable

  379. nicoco

    agreed about pragmatism. I should just ignore reactions/edits/retractions of old messages, and be happy with only "live updates". guaranteeing proper ~infinite history sounds like a lot of trouble for something that most likely won't matter. the reason I want to implement MAM is just to make groups usable on mobile…

  380. MattJ

    But I can then understand that clients might just ignore that flag

  381. Kev

    > But I can then understand that clients might just ignore that flag Sure, clients can do what they like based on the properties they want.

  382. menel has joined

  383. MattJ

    What's not going to happen in most clients, is implementing two different sync strategies, and choosing between them on a per-query basis

  384. Kev


  385. nicoco

    >Would the server flag a full response btw pep. full response, since it's in <fin> I think?

  386. MattJ

    A client that does the "right" thing, paired with a server that always returns stable=false would be somewhat problematic

  387. Vaulor has left

  388. Kev

    I'm happy enough that clients choose to ignore the edge cases if they want to. As long as we give them the information to do the right thing if they so choose.

  389. Vaulor has joined

  390. MattJ

    It almost suggests we need a third flag

  391. Kev

    > A client that does the "right" thing, paired with a server that always returns stable=false would be somewhat problematic Not necessarily. Doing the right thing with stable=false only means not treating it as a source of truth, which means refetching it next time you want that segment of the archive.

  392. MattJ

    "temporarily unstable" (try again in a bit) or "permanently unstable" (do whatever you want)

  393. Kev

    Permanently unstable is probably a property of the whole archive that could be advertised.

  394. nicoco

    isn't there some overlap between what "permanently unstable" entails and what the fastening collation xep tries to do?

  395. Kev

    Is there?

  396. pulkomandy has joined

  397. Kev

    "Unstable" means that there may be messages missing from the middle of your results.

  398. Kev

    And the fastening collation is a way to indicate on results that later stanzas have been applied to change somewhat-meta-data.

  399. Sam has left

  400. nicoco

    from my (very narrow) point of view, there is some overlap: I can't say stable="true" because of this msg metadata changes

  401. Kev

    But you can.

  402. pep.

    nicoco, it's another message, not a message that has changed

  403. _root has left

  404. Kev

    Or, at least, the collation stuff shouldn't affect it. All that should affect stable/not is whether messages might be missing from the returned sequence.

  405. Sam has joined

  406. _root has joined

  407. jubalh has joined

  408. nicoco

    >another message, not a message that has changed indeed. every "metadata event" (edits, reactions, ...) is indeed a new message stanza in XMPP. that does not map to what most networks do where the MAM-equivalent returns collated results only.

  409. Kev

    And that's fine.

  410. Kev

    And that's what collations allow XMPP to act like.

  411. nicoco

    >whether messages might be missing from the returned sequence the overlap is here? if a MAM server serves collated results, it's because they don't want to serve all "metadata edit events" but only the current state (probably as optimization for storage and network IO)

  412. Kev

    Well, no, I don't think that's true.

  413. Kev

    If your MAM archive serves

  414. Kev

    If your MAM archive serves fastenings as normal messages, they're in sequence. If it doesn't, they're always missing.

  415. Kev

    I think unstable-ness is completely orthogonal to serving of collations.

  416. Kev

    (While accepting I could be wrong)

  417. larma has left

  418. menel has left

  419. jubalh has left

  420. nicoco

    > If your MAM archive serves fastenings as normal messages, they're in sequence. If it doesn't, they're always missing. I'm having trouble parsing this. Could you expand a little? 🤯️

  421. menel has joined

  422. Kev

    I'm saying that your MAM archive will either serve up messages that are a fastening, or will not serve up messages that are a fastening. Whichever way it chooses to do, which messages are returning a particular period (stable=true/false) is unaffected by subsequent fastenings being processed by the archiving server.

  423. Kev

    s/returning/returned for/

  424. debacle has left

  425. nicoco

    > The third form, "collate", presents each traditional IM message, as "simplified", but within the result includes summary information about the fastenings (and pseudo-fastenings) encountered. what I meant by overlap was: if a server serves "summary information about the fastenings", clients should always treat it as "stable=false". or doesn't that make sense?

  426. nicoco

    I mean that by nature, the "summary information" is unstable (like the universe)

  427. Kev

    I think I understand your point, but I don't agree with it entirely.

  428. Kev

    If you want to render that message again, you'll want to refetch the collation, yes. But you do at least know that the message itself is there, that no new messages have been inserted before it, etc. You can render a page from your local cache, for example, and fill in the fastenings as they come in from a subsequent query.

  429. Nicoco has joined

  430. oshn has left

  431. SouL has left

  432. SouL has joined

  433. oshn has joined

  434. Wojtek has left

  435. larma has joined

  436. jubalh has joined

  437. _root has left

  438. _root has joined

  439. menel has left

  440. PapaTutuWawa has left

  441. menel has joined

  442. Vaulor has left

  443. Vaulor has joined

  444. antranigv has joined

  445. Nicoco

    Kev: I understand. from a client's perspective it is different in this regards. Thanks for the replies. "Not all stanzas are born equal" could be the subtitle of the fastening collation spec.

  446. Kev

    Or "It seemed like a good idea at the time", which applies to much of XMPP :)

  447. pep.

    Retractions with <body/> included are really not user-friendly.. "This person is retracting a message that they may have not wanted you to see, so we're going to repeat it", or "This person has retracted a message that was taking quite some space, so we're going to repeat it because it's good that you can see it once more"

  448. pep.

    That's really all this makes me think about :/

  449. jubalh has left

  450. PapaTutuWawa has joined

  451. rom1dep

    Hey there, I'm having a fuzzy memory of someone mentioning ad-hoc commands being implemented by some fork of Conversations, does that ring a bell, and would anyone know which client that might be?

  452. MattJ

    rom1dep, Cheogram

  453. MattJ

    Conversations fork, has ad-hoc commands

  454. rom1dep

    Sounds like it might be it, thanks a lot MattJ 🙂

  455. Beherit


  456. Wojtek has joined

  457. u has left

  458. u has joined

  459. pulkomandy has left

  460. Sam has left

  461. pulkomandy has joined

  462. larma has left

  463. Sam has joined

  464. spiral has left

  465. spiral has joined

  466. Nicoco

    pep.: about retractions, would you rather see no message at all for clients that don't support it?

  467. pep.

    I wonder. I think yes. Maybe at the most "The user retracted a message", to say they did something, but without context it's probably useless so..

  468. Yagizа has left

  469. nicola has joined

  470. stuart.j.mackintosh has left

  471. Vaulor has left

  472. Sam has left

  473. Sam has joined

  474. kapad has joined

  475. Vaulor has joined

  476. sonny has left

  477. rubi has left

  478. rubi has joined

  479. sonny has joined

  480. tsk has joined

  481. rubi has left

  482. tsk has left

  483. Sam has left

  484. Sam has joined

  485. spiral has left

  486. spiral has joined

  487. rubi has joined

  488. rubi has left

  489. rubi has joined

  490. antranigv has left

  491. sponji has joined

  492. Schimon_ has left

  493. Trung has left

  494. selurvedu has joined

  495. Millesimus has left

  496. testes has joined

  497. techmetx11 has left

  498. techmetx11 has joined

  499. Millesimus has joined

  500. Alex has left

  501. Millesimus has left

  502. Millesimus has joined

  503. atomicwatch has left

  504. MSavoritias (fae,ve) has left

  505. stefan has left

  506. Wojtek has left

  507. jubalh has joined

  508. Millesimus has left

  509. u has left

  510. u has joined

  511. qwemnb has joined

  512. Millesimus has joined

  513. kapad has left

  514. Kev has left

  515. mirux has left

  516. Millesimus has left

  517. Millesimus has joined

  518. atomicwatch has joined

  519. sonny has left

  520. Dele Olajide has left

  521. yarmo has left

  522. yarmo has joined

  523. sonny has joined

  524. antranigv has joined

  525. menel has left

  526. menel has joined

  527. wurstsalat has left

  528. menel has left

  529. menel has joined

  530. menel has left

  531. menel has joined

  532. testes has left

  533. goffi has left

  534. debacle has joined

  535. Beherit has left

  536. menel has left

  537. menel has joined

  538. stefan has joined

  539. Wojtek has joined

  540. Wojtek has left

  541. sponji has left

  542. debacle has left

  543. menel has left

  544. menel has joined

  545. debacle has joined

  546. antranigv has left