XSF Discussion - 2020-07-06


  1. strypey

    *shrug* If any of you care about whether or not the general public use jabber apps in place of WhatSapp, Telegram, Signal, etc, then UX matters a lot, and that includes consistency of basic features across apps, and whether apps keep UI promises (both explicit and implicit). I'll keep offering feedback about this in case it matters to anyone. But so far my impression is that the target audience for jabber apps is other jabber devs, in which case UX doesn't matter much at all.

  2. tom

    I think it's interesting that way Kristall's client handles crypto identies

  3. tom

    (A Gemini client)

  4. tom

    Trust On First Use by default

  5. tom

    Similar to OpenSSH

  6. tom

    https://github.com/MasterQ32/Kristall

  7. tom

    It's just a button right next to the url bar, but you can go in the settings and see a tabulated list of the trust database

  8. tom

    Seems like that kind of model should be suitable for omemo, instead of blaring popups in the user's face to trust or not trust a fingerprint the first time someone talks

  9. Zash

    tom: Have you seen https://gultsch.de/trust.html ?

  10. tom

    Similar to OTR then

  11. tom

    Protection against passive attacks just by turning it on

  12. tom

    But verify the fingerprint or challenge question and you get authenticated otr

  13. tom

    For active attack protection

  14. Neustradamus

    MattJ: Nice! It is excellent to see changes about the OS!

  15. jcbrand

    strypey: the other chat apps you mentioned aren't federated, open, extensible or backwards compatible. XMPP devs who want to federate and maintain compatibility with older clients have much more to contend with and have more constraints. Not to mention the fact that the open source projects generally don't have wealthy benefactors. Also, not being able to read messages on a new device is a feature and restriction of libsignal/OMEMO and not of XMPP itself.

  16. jcbrand

    That said, the UX of clients can definitely be improved, and we've held sprints to try and move this along. This is however not easy for many reasons.

  17. flow

    what jcbrand said

  18. Guus

    Does anyone have experience with clients that participate in _many_ (thousands) chat rooms? How would one most efficiently spot what rooms have unread messages, etc - preferably in less than one-request-per-room?

  19. edhelas

    what doy ou mean "one request per room", network wise, db wise ?

  20. Guus

    stanza-wise

  21. Zash

    Guus: Not a client but https://xmpp.org/extensions/xep-0437.html

  22. Guus

    Zash that seems useful, thanks

  23. flow

    dwd, you don't happen to be able to provide a simple short summary of our discussion with ruslan on the ml?

  24. Holger

    ruslan: VALID CERTS OR YOU'RE DOOMED! dwd: You didn't quite get the point.

  25. dwd

    I'm not sure he's saying that.

  26. dwd

    I'm not sure what he's saying, actually. But it's not that.

  27. Zash

    Has any clarity been found regarding the original issue?

  28. MattJ

    Guus: that use case is exactly what that XEP was for

  29. MattJ

    Have a Converse.js and Prosody implementation

  30. flow

    dwd, you don't happen to be able to provide a simple short summary of your discussion with ruslan on the ml?

  31. flow

    Holger, dwd, thanks, that already made me feel better ;)

  32. Guus

    MattJ: how does prosody keep track of what users to notify? All affiliates not in the room when a message is being shared in it? Or do you query the archives for data since the last time an affiliate became unavailable to the room?

  33. MattJ

    It uses affiliations to determine subscriptions - I left that open in the XEP because other setups may want to use a different source

  34. MattJ

    Unread messages are calculated by tracking <displayed/> markers from the client

  35. MattJ

    (and similarly we only store these for affiliated users)

  36. Guus

    Right, makes sense

  37. Guus

    Thanks