-
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.
-
tom
I think it's interesting that way Kristall's client handles crypto identies
-
tom
(A Gemini client)
-
tom
Trust On First Use by default
-
tom
Similar to OpenSSH
-
tom
https://github.com/MasterQ32/Kristall
-
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
-
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
-
Zash
tom: Have you seen https://gultsch.de/trust.html ?
-
tom
Similar to OTR then
-
tom
Protection against passive attacks just by turning it on
-
tom
But verify the fingerprint or challenge question and you get authenticated otr
-
tom
For active attack protection
-
Neustradamus
MattJ: Nice! It is excellent to see changes about the OS!
-
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.
-
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.
-
flow
what jcbrand said
-
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?
-
edhelas
what doy ou mean "one request per room", network wise, db wise ?
-
Guus
stanza-wise
-
Zash
Guus: Not a client but https://xmpp.org/extensions/xep-0437.html
-
Guus
Zash that seems useful, thanks
-
flow
dwd, you don't happen to be able to provide a simple short summary of our discussion with ruslan on the ml?✎ -
Holger
ruslan: VALID CERTS OR YOU'RE DOOMED! dwd: You didn't quite get the point.
-
dwd
I'm not sure he's saying that.
-
dwd
I'm not sure what he's saying, actually. But it's not that.
-
Zash
Has any clarity been found regarding the original issue?
-
MattJ
Guus: that use case is exactly what that XEP was for
-
MattJ
Have a Converse.js and Prosody implementation
-
flow
dwd, you don't happen to be able to provide a simple short summary of your discussion with ruslan on the ml? ✏
-
flow
Holger, dwd, thanks, that already made me feel better ;)
-
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?
-
MattJ
It uses affiliations to determine subscriptions - I left that open in the XEP because other setups may want to use a different source
-
MattJ
Unread messages are calculated by tracking <displayed/> markers from the client
-
MattJ
(and similarly we only store these for affiliated users)
-
Guus
Right, makes sense
-
Guus
Thanks