jdev - 2020-08-02

  1. eta

    I've just had an amazingly cursed idea

  2. eta

    so, when someone's client leaves a MUC they go offline, right, and leave the MUC

  3. eta

    could you continue to send that client messages for the MUC and would they be stored in offline storage?

  4. Ge0rG

    eta: when a client goes offline, their server will normally respond with errors to all MUC messages, leading to a kick of the client

  5. eta

    awww

  6. Ge0rG

    eta: the most interesting idea so far was to register XEP-0357: Push Notifications on each MUC, so that the MUC would send a push when a given client leaves, causing the client to be woken up and to rejoin

  7. Ge0rG

    AFAIK it wasn't implemented yet

  8. eta

    Ge0rG: I'm mainly trying to avoid having to store messages for a transport

  9. eta

    or at least, trying to offload storage to user servers

  10. Ge0rG

    eta: that's a nice idea, but won't work because users' servers drop groupchat from MAM

  11. eta

    Ge0rG: and offline storage?

  12. Ge0rG

    eta: never stored groupchat, and is also rather deprecated

  13. eta

    ah

  14. eta

    Ge0rG: what's wrong with offline storage?

  15. Ge0rG

    eta: it will be depleted by the first client coming online, your second client won't see anything from it

  16. eta

    oh is it not per-resource?

  17. Zash

    I experimented with having everything sent from the users bare JID, instead of the full JID

  18. eta

    okay that's a bit garbage

  19. eta

    Zash: yeah, the minimix thing

  20. Zash

    Yeah, that

  21. eta

    but that doesn't solve the MAM issue

  22. Zash

    Maybe we've talked about it

  23. eta

    we have :)

  24. Zash

    eta: Not directly, but it can solve the MAM issue, with some trickery.

  25. eta

    Zash: i.e. get the MAM service to store groupchat messages too?

  26. Zash

    You'd have to have the minimix and MAM conspire together

  27. Ge0rG

    what we need is more trickery.

  28. eta

    (and intercept MAM queries for the room JID)

  29. Zash

    Hacks upon hacks upon hacks

  30. eta

    that's how protocols work, of course

  31. eta

    "layers are only added, never removed"

  32. eta

    Zash: surely this would solve all the problems though?

  33. eta

    I guess it'd impose a storage burden on the servers

  34. Zash

    ALL THE PROBLEMS

  35. Ge0rG

    what about just going forward with XMPP 2.0?

  36. eta

    Ge0rG: XMPP *what*

  37. Ge0rG

    eta: https://wiki.xmpp.org/web/XMPP_2.0

  38. eta

    Zash: yep, all the problems all fixed, no more work needed

  39. eta

    Ge0rG: oh, fancy

  40. lovetox

    its assumed that a well maintained server, has pubsub persist items set to True by default on new nodes, or?

  41. lovetox

    im asking if i need to have code that reconfigures the node

  42. lovetox

    or if this is something i can tell users to bug the admin with