XSF Discussion - 2020-07-06

*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.

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

(A Gemini client)

Trust On First Use by default

Similar to OpenSSH

https://github.com/MasterQ32/Kristall

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

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

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

Similar to OTR then

Protection against passive attacks just by turning it on

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

For active attack protection

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

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.

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.

what jcbrand said

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?

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

stanza-wise

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

Zash that seems useful, thanks

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

I'm not sure he's saying that.

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

Has any clarity been found regarding the original issue?

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

Have a Converse.js and Prosody implementation

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

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

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?

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

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

(and similarly we only store these for affiliated users)

Right, makes sense

Thanks