I think Element (https://element.io/) is worth looking at for anyone who wants something decentralized. Unfortunately I have exactly 1 contact who uses it, but that was true of Signal as well 8 years ago
Spaces was implemented but again the UI is just terrible
Other clients are better as an im like fluffy chat tho
[1]: https://cinny.in
Other than that, Cinny doesn't address the problem of Element on mobile not working very well. FluffyChat's UI isn't very nice either.
Hehe, I hopened with the inte tion to do it myself too, but never got around to doing it. It would require me to learn a bit of react and I don't have the time for it atm :/
I don't know what went wrong, but it still needs work. I'm glad to see that it's easier than last time I tried that.
I had issues with verification a while ago but recently it's worked perfectly fine.
The promised functionality doesn't really work reliably enough to protect against MITM, causes ugly warnings, but has been totally unactionable for years now.
I'm very much hoping they will hurry up with Sync v3, which would make this protocol a hell of a lot easier to use (for me, and a lot of other people). Right now booting up Element (or any other Matrix client, this is really a protocol issue) feels like a major chore, and it's something I prefer to avoid if I can. This is also why I keep Telegram installed on both my mobile, desktop and laptop.
Aside from Element, there isn't really much choice on Linux anyway. Fractal is ancient and gets stuck at "Syncing", Nheko takes up gigabytes of memory on initial sync until OOM'd, FluffyChat doesn't really work on my desktop (neither does NeoChat, Quaternion, Spectral), etc. etc. If you name a Matrix client, I have most likely tried it before and it didn't work (aside from Fractal Next, which doesn't have a release yet FWICS).
I've also considered hosting some sort of XMPP service, then bridging my Matrix account to said service so I don't have to endure the poor UX of various Matrix clients. Then again I'm not sure how the end-to-end encryption would work with that, and I would like to keep that if possible.
I have never experienced (or had to endure) an app with such poor UX as Element. Nothing seems to work quite as it should, sometimes it just plainly refuses to work, and other times you get issues which have been reported multiple years ago to the Matrix team (and still have yet to be fixed).
At this point I am very worn out of having to use Matrix, however due to my moderational duties I have no other choice.
Ahh, thank you telling me. I guess that's off the cards then.
> That's one of the reasons why I believe working on improving existing Internet Standards is better than switching to another trendy, non-standard protocol.
As much as I hate to admit it, I totally agree with you. While I personally quite like the API's and SDK's (although the JS SDK is pants, I've worked with it before), the UX of the client(s) just don't feel there yet, compared to what alternatives are offering.
Some polished XMPP clients include dino/gajim (desktop) and conversations/siskin (android/iOS). If you're looking for a unified-brand client/server distribution, snikket.im is a pretty cool project and could use help and funding.
Sub-folders would be even better for large-volume stuff like throwing multiple Discords worth of things into a Space, but I don't currently need that.
---
E2EE I have routine fights with, so yeah - Element is not great yet. But it's good enough that my siblings and I are seriously considering converting us + my non-technical parents over, now that Hangouts is horrible and we all hate how flaky it is. And it's a much, much better experience than Signal. The only other contender at the moment for that migration is Telegram (which is absolutely stellar, they're doing an amazing job).
How would they differ from sub spaces?
I may have just missed it.
Thanks! I've got Stuff™ to organize now.
If it doesn't matter, why not let people choose whatever they like? Personally I'm also wondering if having specifically white and specifically black thumbs-ups does not introduce more racial bias rather than the generic yellow default that I was used to, but I did notice people of color using specific colors so perhaps it does matter, at least for some of them. The rest of us can just be on (the afaik neutral) yellow, presuming that makes everyone happy.
Technology is made for people. People are all sorts of shades. Other chat apps give people the ability to modify skintone on several emoji.
Good grief.
Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients. [Some people are saying not: that homeservers don't see plaintext of E2EE traffic.]
There is talk about self-hosting in the client, but I don't know if it works yet, or ever will. Lack of encryption-at-rest, wherever it is that messages live, seems like a stupendous implementation design flaw, and makes me question all the project's other choices.
If, in fact, messages are, or can now be, stored securely, I would welcome correction. Likewise, if client-side hosting works now, or message-store migration, or a stable address despite such a migration, or any effort at securing metadata. I have not kept up since abandoning Matrix, but still want a viable alternative to Signal.
The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.
Will we need to start all over again? A rigidly layered system, with a provably secure basis, probably in a single, sandboxed server talked to by all clients and gateways, with services built on top, seems needed if we want both security and features.
As it is, it seems like clients -- i.e. application services -- run in the same address space with what should be secure message transport, necessarily compromising all security with each bug added.
partially true - while there isn't a protocol defined way, you can invite your new account to your rooms, import your encryption keys and leave the rooms with the old accounts
> (2) the homeserver has (!) plaintext access to all traffic on it
hmm, isn't that unavoidable?
> (4) no effort at all to obscure metadata, who you communicate with and when.
There is effort on it, e.g. by going P2P and eliminating dedicated homeservers
> I don't know of any clients that let you manage separate identities at the same time
FluffyChat, Syphon, and others I don't know the names by heart
> Matrix defines a sort of end-to-end encryption, but the ends are homeservers and clients.
The ends are the sessions in a room. The homserver is not an end. How did you get that impression?
> Lack of encryption-at-rest, wherever it is that messages live, seems like a stupendous implementation design flaw, and makes me question all the project's other choices.
Isn't encryption at rest usually done by the operating system?
> hmm, isn't that unavoidable?
Not only is it avoidable, it’s not actually true AFAIU. It’s unfortunate (if historically justifiable) that Matrix has a non-E2EE mode, but the thing it brands as E2EE is actually deserving of the name, with messages accessible to clients only and the associated hurdles (you literally can’t get access to message history in encrypted chats from a new client on the same account unless you get one of your old clients to cross-sign, even if the homeserver will help mediate the prompt).
Matrix is not free of problems, but it does have federated, multi-party, multi-device, end-to-end encrypted chats with persistent history and forward secrecy. The underlying crypto goes by Megolm[1]. It’s slightly weaker[2] (in particular regarding backward secrecy) than the strictly two-party thing Signal does (however they brand it these days), but nowhere near the point of allowing the homeserver to eavesdrop.
[1] https://blog.jabberhead.tk/2019/03/10/a-look-at-matrix-orgs-...
[2] https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
Note that new features apparently come unencrypted, even in otherwise encrypted rooms. For example reacting to messages with emoji sends the reaction non-E2E-encrypted for both all home servers to see: https://news.ycombinator.com/item?id=29656282.
I checked that. While reactions are not encrypted indeed, a very recent feature - polls which are available in labs on Element Android - is encrypted.
It is certainly not intended that new features are unencrypted, but unfortunately sometimes it happens in order for features to get added sooner.
That being said, there is still a lot of it that is up in the air. From what I've gathered, there's been talk about leaving aggregations to be done client-side specifically for reactions.
Just clients I think. Otherwise it couldn't be E2EE. AFAIK, if you actually can manage to verify your correspondents with whatever the identity numbers are called in Matrix, you get effective E2EE.
The person sending the message and their intended recipient(s) are the "ends" in end-to-end encryption. The server is not an "end".
Incidentally, the client software is also not the "end": If the system includes a component designed to forward any data about the otherwise-encrypted content of the messages to someone who is not the sender or their intended recipient (unless at the direction of someone who is an intended party to the conversation) then the system does not implement end-to-end encryption. For example, Apple's iMessage app does this with their mandatory client-side scanning misfeature.
There's a lot of incorrect information here. First of all, it is not mandatory, it's opt-in - parents have the ability to turn it on for children under 18 whose devices have parental controls enabled. (Technically you could argue that it is then mandatory for those children, but that's no different from other parental control features.) Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.
I think you're conflating it with the iCloud Photos CSAM detection, which would have been mandatory and sent results of on-device scans to Apple if you have iCloud Photos enabled, but they seem to have scrapped that (for now at least) as they quietly removed all mentions of it from their website.
> Also, it uses on-device machine learning to detect and blur NSFW photos. They even removed the feature that notifies the parents if the child chooses to view a photo that was detected as NSFW anyway, so the contents of messages are not sent to Apple or anyone else.
… suggests that there was something similar in iMessage at one point, even if it was later removed. The "on-device learning" (or rather, on-device classification) means you're effectively sharing the data with Apple's agent running on the device, and the user doesn't have the ability to turn that off. Though it wouldn't be unreasonable to consider the parent who authorized this to be one "end" of the conversation since there is a minor involved—assuming there actually is a minor involved. (These "parental controls" have been abused to monitor adults.) It would be best if that fact was somehow communicated to all the other participants, for example with a "parental control active" or "monitored account" badge on the user's icon & profile.
What do you mean? Signal is known for providing minimal information when requested by authorities, e.g., [0].
[0] https://signal.org/bigbrother/central-california-grand-jury/
As a simple example, they could easily log whenever account xyz connects to do a token exchange for using sealed sender. Asking that of Signal won't be something I'd expect a judge would consider excessive if there is a legitimate reason.
i know "whatsapp admins" who have been made to report to police stations because they operate "whatsapp news channels". there they are made to submit their phone and wait outside. then the phone is returned. i have suspected, for like past 3 years that pegasus style malware would have been installed during that time.
now, a lot of these issues and problems can be reduced/prevented if you were not required to mandatory link your mobile number. if they know me by a handle, rather than a phone, it would be a little bit harder to do mass surveillance and bullying.
this was last yearand it continues. i have taught people to use launchers on android like evie that lets you hide apps. that saves you a lot of roadside quick grief. same for using password protected "gallery" like simple gallery to keep stuff behind a password. a thorough check will defeat all this but saves you in the field as you can be randomly picked.
whatsapp/signal/telegram as i said is more difficult, even clubhouse because since your phone is already public, the police do join groups, public or private using any means, lets say by surveillance, by getting access from company side or "borrowing" a phone from a member. then they just get a list of names and go knocking on doors. if the number was not there, it would have been much more difficult.
Edit: grandparent comment can't seem to keep Matrix vs Signal straight.
Signal is the one that only works with Google Play, thus a Google account, and a phone number. It is easy for the spooks to connect that and its IP address to every subsequent communication, after the fact.
Matrix homeservers have plaintext access to whatever is plaintext, though most matrix homeserver software doesn't include built-in functionality for admins to do that sort of thing; it would involve digging through the database(s). DMs are opportunistic e2ee and rooms can be plaintext or E2EE.
> besides all the delicious metadata the spooks love and that (e.g.) Signal hands over to them with effusive eagerness,
Signal is not Matrix...and Signal does not have any metadata except account creation and last-seen timestamps. Maybe the fact that you can't keep the two communications networks straight is a good sign you're not qualified to be critiquing them.
> The Matrix protocol is extremely complex and getting more complex with great speed as they try to get to feature parity with Facebook and Twitter, making it hard to believe one will ever be able to trust it, E2EE or no.
That's not how that works.
Your comment is...seriously uninformed.
I hate the way Signal sells it, like there is zero trust involved and everything is solved by some magic encryption. There is a lot of data the Signal could store, like who is receiving the group message you just send to, that is only guaranteed by their server's source in Github (they could be hosting another thing and you will never know). That said, Signal is still much superior in terms of metadata protection, like the sealed sender feature for direct messages which will take time to arrive in Matrix [1]. I just wished they were more transparent about what they can't store and what they can store but is not storing.
It is proper end-to-end encryption using pretty much the same constructions as Signal.
This is categorically untrue. Matrix’s E2EE is between clients; homeservers can not see plaintext in encrypted rooms, and all private rooms are encrypted by default these days.
The parent is completely confused.