XSF Discussion - 2020-07-14

  1. !XSF_Martin

    Why there is https://xmpp.org/extensions/inbox/occupant-id.html and https://xmpp.org/extensions/xep-0421.html?

  2. jonas’

    because we don’t delete stuff from the inbox currently

  3. !XSF_Martin

    During my first search i found the first and thought it's not yet accepted and later I found the second.

  4. jonas’

    and we can’t set redirects :(

  5. jonas’

    probably deleting would be a good thing then

  6. !XSF_Martin

    jonas’: That's irritating if your search engine isn't as clever as google. :(

  7. jonas’

    I agree

  8. jonas’

    but deleting is also meh regarding reading mailing list history

  9. jonas’

    (but so would redirects)

  10. pep.

    https://github.com/xsf/xeps/issues/738

  11. jonas’

    or that, yesn

  12. jonas’

    !XSF_Martin, I hear you want to join the editor team....

  13. !XSF_Martin

    :D

  14. Link Mauve

    jonas’, you could do a HTML redirect instead of an actual deletion.

  15. jonas’

    Link Mauve, would also require changes to the schema as in #738

  16. Link Mauve

    That’s way worse than being able to configure the web server, but since this is now a task too complicated thanks to containers… ✎

  17. Link Mauve

    That’s way worse than being able to configure the web server, but since this is now a task too complicated to be realisticly thanks to containers… ✏

  18. Link Mauve

    That’s way worse than being able to configure the web server, but since this is now a task too complicated to be realisticly done, thanks to containers… ✏

  19. jonas’

    has nothing to do with containers

  20. Link Mauve

    Oh?

  21. jonas’

    but everything with lack of configuration management

  22. jonas’

    the containers are just a band-aid around the former, alleviating some of the pains in that regard (because some config is baked into the containers instead of handled ad-hoc on nodes)

  23. jonas’

    but the core issue is that there’s no config management

  24. Guus

    would you expect to find messages that were shared with a MUC room in MAM responses from a personal archive?

  25. Link Mauve

    I’ say no, I would expect them only in the MUC archive. ✎

  26. Link Mauve

    I’d say no, I would expect them only in the MUC archive. ✏

  27. Guus

    Openfire doing a catch-all where the 'to' and 'from' matches the addressee, which also captures some MUC messages (notably, when you're online) ✎

  28. Kev

    I would, yes.

  29. Guus

    I just helped a customer that was confused that it got inconsistent group chat history while querying MAM - they were querying personal archives, rather than the MUC address.

  30. Guus

    Easily fixed, but it made me wonder.

  31. Guus

    Openfire doing a catch-all where the 'to' and 'from' matches the addressee, which also captures some MUC messages (notably, when you're in the room) ✏

  32. Guus

    Although I can see how MUC messages would technically end up in personal archives, I wonder what the value of those are. Chances of it not being a consistent history are large, I think?

  33. jonas’

    Guus, congratulations, you just rediscovered one of the key issues with MIX :)

  34. Guus

    Am I not more than 5 years late to the party?

  35. Kev

    Don't you mean one of the key issues with MUC that's resolved with MIX? :)

  36. jonas’

    Kev, no?

  37. jonas’

    in MUC, nobody expects messages to be in the account archive

  38. Kev

    I do.

  39. jonas’

    it’s not specified anywhere tho

  40. Guus

    (I can't help but read that in a Monty Python voice)

  41. jonas’

    in MIX, everybody does, and MIX does not specify how to recover from s2s outagfes ✎

  42. jonas’

    in MIX, everybody does, and MIX does not specify how to recover from s2s outages ✏

  43. Kev

    "not specified anywhere" to the tune of "A server SHOULD also include messages of type 'groupchat' that have a <body>, but where such history is accessible through another method (e.g. through an archive on the MUC JID)" ? ✎

  44. Kev

    "not specified anywhere" to the tune of "A server SHOULD also include messages of type 'groupchat' that have a <body>" ? ✏

  45. jonas’

    fun, I don’t know of any client which looks there for MUC archives. I seem to even recall that people wanted type='groupchat' explicitly excluded from their MAM results because it would be inconsistent and waste bandwidth for nothing ;)

  46. Kev

    It's not 'nothing' though, is it?

  47. Kev

    If I want to find a message that I know I sent about X, I shouldn't need to remember where I sent it in order to find it, I should just query my archive.

  48. eta

    well the issue with that is, if all your clients are offline your MUC archive won't populate

  49. eta

    because you're not in any MUCs

  50. jonas’

    Kev, you’re of course using E2EE so you can’t query your archive for X and have to rely on your local archive anyways /s ✎

  51. Kev

    Yes, but I also probably didn't send or receive any messages to the MUC while I was offline :)

  52. jonas’

    Kev, you’re of course using E2EE so you can’t query your server archive for X and have to rely on your local archive anyways /s ✏

  53. Guus

    in your specific case, I wouldn't put it past you, but generically, I think you're right 🙂

  54. Guus

    I'm guessing the benefits and drawbacks, functionality wise, might be roughly in balance on this?

  55. Guus

    consensus on implementation might be good. Following the specification is a good place to start, I guess 🙂

  56. edhelas

    hi everyone

  57. edhelas

    i had a look at XEP-0402, looks great 💕

  58. edhelas

    but I already had a bookmarks:0 implementation in Movim, and 0411 explains how to convert between 0049 and 0402

  59. edhelas

    i'm wondering how I can do the transition smoothly

  60. edhelas

    from :0 to :1

  61. lovetox

    edhelas, the only difference is the <extension> container or not?

  62. lovetox

    what is there to migrate?

  63. pep.

    lovetox, I guess the question is mostly on what to push where. push :0 or push :1 and handle deletion on the other side or not etc.

  64. pep.

    Link Mauve, was your mod_bookmarks2 handling conversion?

  65. Link Mauve

    pep., yes, but only between 0049-Private XML and 0402, not between 0049-PEP and 0402.

  66. lovetox

    im confused, it the question how to migrate from bookmarks:0 to 1?

  67. pep.

    ah edhelas, in 402 it's written "urn:xmpp:bookmarks:1#compat"

  68. Link Mauve

    Due to Prosody internals reasons.

  69. lovetox

    or from other bookmark xeps to 402