Understandable actually. Server maintenance costs money and if a 3rd party chat app; which significantly has more usage than other forms of social media; is trying to connect to the server, they have to handle that traffic too. Remember, it is not just about data size, but also the sheer volume of connection to handle.
I think the solution is just P2P with each peer acting as a relay to the other too. The protocol needs to be designed in such a way that no-one in the middle can reply to send false acknowledgement so as to prevent sybil attack or other attack where a malicious actor is a part of the network.
Right, the rating list is generic, whereas it should be categorized. For example while iMessage is a walled garden, if the list was sorted by ease of use, it should be first, as it’s nearly zero-configuration for the end user and they get encrypted messaging. Matrix would be first on open access (if we weren’t counting SMS), because it’s available on so many platforms and clients. Signal probably wins on security, though I don’t know enough about it to verify that. So on and so forth
And RCS is only supported on Androids with Google or Samsung’s messaging apps, so therefore requires you to buy an android. However since iMessage is cross platform through Apple’s ecosystem, I would still rate it higher than RCS for ease of use. And I would certainly rate it higher than matrix or signal, as they require you to install additional software than what comes with a device.
I don’t buy that logic. How is it cross-platform? (It technically is, but c’mon. All of these OSs are in the walled garden.) I agree about RCS requiring Android, but that doesn’t really put it lower than iMessage, since that also requires you to buy a device. (iMessage does have more features, though.) Apple has promised to support RCS in iPhones, so this should soon change. Also, why would iMessage be rated higher than Signal using this logic? What’s easier, buying a device or installing an app on your existing device? (If someone doesn’t have any mobile device, I don’t think they really care about messaging anyway. So I don’t consider that as a proper prerequisite.)
First off, how can you claim RCS "requires you to buy an Android and then state iMessage is "cross platform through Apple’s ecosystem? RCS works on Android and is available in various devices from many manufacturers. iMessage is only available on devices sold by Apple.
Secondly, why would you rate iMessage higher than RCS for “ease of use”? That makes zero sense, they behave basically the exact same way.
Lastly, RCS is coming to iOS - Apple’s just been lagging because implementing a cross-platform solution is detrimental to their profits.
So RCS will eventually work across iOS and Android AND work by default. There’s no reason RCS wouldn’t be easier or rated higher than iMessage in terms of “ease of use”
This is an often repeated piece of misinformation. The developer of gurk-rs, a third party Signal client, has even said this himself. The client presents itself with a completely identifiable name to the Signal servers - the Signal devs can see this and could easily block this client from connecting but they don’t. This project has existed for at least 3+ years now.
There’s a few clients for Signal, nobody is preventing developers from creating apps; there’s Molly, gurk-rs, Axolotl, Flare, signal-cli, Pidgin (with the Signal plugin.
The problem is 3rd party clients don’t implement all features because it takes a lot of work and they’re created/developed by volunteers - just take a look at Matrix and how many clients support all features or even just group end-to-end encryption (E2EE). Last I checked many third party Matrix clients didn’t support encrypted group messages, primarily just Element, the reference client built by the matrix developers. So you have the same problem on Signal that you have on Matrix.
In Matrix a direct chat is a group chat with two people.
You’re right, I forgot how Matrix handled messages and the current state is that there’s are at least 6 other clients that support E2EE - this is awesome.
That said, as soon as you look for a stable client that supports other features like Native 1:1 calls and Threads the only client listed is Element, check here: https://matrix.org/ecosystem/clients/
Side note: Looks like ~3 years ago a Fluffychat dev stated they would not implement E2EE in the app [0], this must have been around the time I was looking at other clients because I recall this one “looking” the best and might be viable for non-techy people to use/recommend. I’m glad they changed their mind and implemented E2EE. Time to take a look at it again.
Do any of these also support SMS? I’ll switch back if I can have my encrypted message comingle with my SMS messages. Signal dropping SMS was the primary reason I left.
signal protocol is basically the opposite, open source but the company is hostile to 3rd party client development
They can’t prevent 3rd party apps, so what’s the issue?
From what I understand, they don’t want 3rd party apps to use their servers.
Understandable actually. Server maintenance costs money and if a 3rd party chat app; which significantly has more usage than other forms of social media; is trying to connect to the server, they have to handle that traffic too. Remember, it is not just about data size, but also the sheer volume of connection to handle.
I think the solution is just P2P with each peer acting as a relay to the other too. The protocol needs to be designed in such a way that no-one in the middle can reply to send false acknowledgement so as to prevent sybil attack or other attack where a malicious actor is a part of the network.
My point is basically that matrix/element is arguable the much more ethical chat solution because of its openess still with a focus on security.
Right, the rating list is generic, whereas it should be categorized. For example while iMessage is a walled garden, if the list was sorted by ease of use, it should be first, as it’s nearly zero-configuration for the end user and they get encrypted messaging. Matrix would be first on open access (if we weren’t counting SMS), because it’s available on so many platforms and clients. Signal probably wins on security, though I don’t know enough about it to verify that. So on and so forth
Should it, though? It requires the user to buy an Apple device.
And RCS is only supported on Androids with Google or Samsung’s messaging apps, so therefore requires you to buy an android. However since iMessage is cross platform through Apple’s ecosystem, I would still rate it higher than RCS for ease of use. And I would certainly rate it higher than matrix or signal, as they require you to install additional software than what comes with a device.
I don’t buy that logic. How is it cross-platform? (It technically is, but c’mon. All of these OSs are in the walled garden.) I agree about RCS requiring Android, but that doesn’t really put it lower than iMessage, since that also requires you to buy a device. (iMessage does have more features, though.) Apple has promised to support RCS in iPhones, so this should soon change. Also, why would iMessage be rated higher than Signal using this logic? What’s easier, buying a device or installing an app on your existing device? (If someone doesn’t have any mobile device, I don’t think they really care about messaging anyway. So I don’t consider that as a proper prerequisite.)
First off, how can you claim RCS "requires you to buy an Android and then state iMessage is "cross platform through Apple’s ecosystem? RCS works on Android and is available in various devices from many manufacturers. iMessage is only available on devices sold by Apple.
Secondly, why would you rate iMessage higher than RCS for “ease of use”? That makes zero sense, they behave basically the exact same way.
Lastly, RCS is coming to iOS - Apple’s just been lagging because implementing a cross-platform solution is detrimental to their profits.
So RCS will eventually work across iOS and Android AND work by default. There’s no reason RCS wouldn’t be easier or rated higher than iMessage in terms of “ease of use”
This is an often repeated piece of misinformation. The developer of gurk-rs, a third party Signal client, has even said this himself. The client presents itself with a completely identifiable name to the Signal servers - the Signal devs can see this and could easily block this client from connecting but they don’t. This project has existed for at least 3+ years now.
There’s a few clients for Signal, nobody is preventing developers from creating apps; there’s Molly, gurk-rs, Axolotl, Flare, signal-cli, Pidgin (with the Signal plugin.
The problem is 3rd party clients don’t implement all features because it takes a lot of work and they’re created/developed by volunteers - just take a look at Matrix and how many clients support all features or even just group end-to-end encryption (E2EE). Last I checked many third party Matrix clients didn’t support encrypted group messages, primarily just Element, the reference client built by the matrix developers. So you have the same problem on Signal that you have on Matrix.
In Matrix a direct chat is a group chat with two people.
Also I’ve used several clients and they all supported encryption.
You’re right, I forgot how Matrix handled messages and the current state is that there’s are at least 6 other clients that support E2EE - this is awesome.
That said, as soon as you look for a stable client that supports other features like Native 1:1 calls and Threads the only client listed is Element, check here: https://matrix.org/ecosystem/clients/
Side note: Looks like ~3 years ago a Fluffychat dev stated they would not implement E2EE in the app [0], this must have been around the time I was looking at other clients because I recall this one “looking” the best and might be viable for non-techy people to use/recommend. I’m glad they changed their mind and implemented E2EE. Time to take a look at it again.
[0] https://gitlab.com/KrilleFear/fluffychat/-/issues/25#note_423061121
There isn’t a call feature completely specified as far as I can find. Therefor it isn’t really possible to have cross client native calls.
It was introduced two years ago: https://element.io/blog/introducing-native-matrix-voip-with-element-call/
Looks like at least two other clients support 1:1 calls.
Do any of these also support SMS? I’ll switch back if I can have my encrypted message comingle with my SMS messages. Signal dropping SMS was the primary reason I left.