simplex on Nostr: No, not like Session at all. We are not going to throw away double ratchet, and we ...
No, not like Session at all.
We are not going to throw away double ratchet, and we are not going to create cryptocurrencies based on public blockchains. If we ever replace double ratchet with any other scheme, we would replace it with the more secure one, not with a less secure one like Session did.
We are moving to a very different direction from Session's: https://simplex.chat/blog/20240516-simplex-redefining-privacy-hard-choices.html
Also, the design of the private routing achieves the level of metadata privacy that onion routing in Session doesn’t provide - I can comment more on it, but here is the post: https://simplex.chat/blog/20240604-simplex-chat-v5.8-private-message-routing-chat-themes.html
I understand that Session fans might be angry about my criticism of Session, but its crisis is of their own doing - Session's decision to remove double ratchet was a wrong one - users who choose Session need double ratchet, at least.
The path for Session to regain users' trust would be:
1) get double ratchet back, with all its qualities, and figure out how to solve multidevice without compromising encryption security - I’d happily collaborate on that, as an acceptable solution doesn’t exist yet.
2) make node ownership optionally transparent and let clients choose nodes owned by known and different operators (to avoid unknown operators who potentially collude undermining onion routing promises - these promises only hold under the assumption that operators of nodes chosen for the circuit do not collude).
3) decentralise media storage in the same way messages are decentralised - Session may as well adopt XFTP protocol we designed - it's independent from messaging, and that can create some collaboration points too.
4) add a notification when another device access the same profile via recovery code.
5) protect access to recovery code in the app with PIN.
In its current state Session is simply dangerous to use for any scenarios requiring privacy and security.
Solving points 4 and 5 would remove Session from "dangerous" territory and make it simply “not too secure”. I don't understand why it wasn't already done after the public conversation with Keith several months ago, see the links here: https://x.com/SimpleXChat/status/1755216356159414602
Solving 1 would make it secure. Solving 2 and 3 would make it private.
It's correct to point out SimpleX network limitations, and we work on resolving them.
But by misleading the audience about Session level of privacy and security you are creating risks that may cost some people their lives or freedom - this is really bad for the community and detrimental for your reputation as well.
We are not going to throw away double ratchet, and we are not going to create cryptocurrencies based on public blockchains. If we ever replace double ratchet with any other scheme, we would replace it with the more secure one, not with a less secure one like Session did.
We are moving to a very different direction from Session's: https://simplex.chat/blog/20240516-simplex-redefining-privacy-hard-choices.html
Also, the design of the private routing achieves the level of metadata privacy that onion routing in Session doesn’t provide - I can comment more on it, but here is the post: https://simplex.chat/blog/20240604-simplex-chat-v5.8-private-message-routing-chat-themes.html
I understand that Session fans might be angry about my criticism of Session, but its crisis is of their own doing - Session's decision to remove double ratchet was a wrong one - users who choose Session need double ratchet, at least.
The path for Session to regain users' trust would be:
1) get double ratchet back, with all its qualities, and figure out how to solve multidevice without compromising encryption security - I’d happily collaborate on that, as an acceptable solution doesn’t exist yet.
2) make node ownership optionally transparent and let clients choose nodes owned by known and different operators (to avoid unknown operators who potentially collude undermining onion routing promises - these promises only hold under the assumption that operators of nodes chosen for the circuit do not collude).
3) decentralise media storage in the same way messages are decentralised - Session may as well adopt XFTP protocol we designed - it's independent from messaging, and that can create some collaboration points too.
4) add a notification when another device access the same profile via recovery code.
5) protect access to recovery code in the app with PIN.
In its current state Session is simply dangerous to use for any scenarios requiring privacy and security.
Solving points 4 and 5 would remove Session from "dangerous" territory and make it simply “not too secure”. I don't understand why it wasn't already done after the public conversation with Keith several months ago, see the links here: https://x.com/SimpleXChat/status/1755216356159414602
Solving 1 would make it secure. Solving 2 and 3 would make it private.
It's correct to point out SimpleX network limitations, and we work on resolving them.
But by misleading the audience about Session level of privacy and security you are creating risks that may cost some people their lives or freedom - this is really bad for the community and detrimental for your reputation as well.