simplex-chat VS ghc-for-ios

For messaging I'm currently on Olvid (E2E with physical key exchange) but since it still use their servers, I'm currently testing SimpleX where I can host my own servers.

Notice how SimpleX (https://simplex.chat/) has no push notifications by default because of this issue.

I've been using SimpleX [0] with a couple of friends recently. It appears to work as advertised.

[0] https://simplex.chat

If you have a mobile phone number, the domestic intelligence agency knows exactly where you are at all times and any LEO (without a warrant) can also find you. In addition, there have been numerous CCC presentations showing how insecure the global (excluding US) and (separately) US carriers are guilty of promiscuous metadata trafficking ($$) and insecure SS7 setups. As a consequence, for low $, you can go to any one of several shady websites and find the last location of almost any phone number (person unique ID) globally. There are additional varying exploitable vulnerabilities depending on the exact combination of {handset x carrier x country} to impersonate them, tap their line, reveal their exact location, and redirect their phone number through a third-party handset or even a PBX. These are more expensive and some capabilities are forbidden for all but a few selective intelligence uses.

Session (Signal fork) doesn't use phone numbers. It's pretty well-designed overall and uses an onion routing approach. It's already a superset of Signal except it doesn't use phone numbers. https://getsession.org

Also look interesting:

* (unproven) https://www.olvid.io/technology

* (unproven) https://simplex.chat

PS: Using regular TOR on home broadband or cloud servers is relatively risky and inefficient. Sybil attacks on it are common. And to network operators and security agencies it gives an easy "flow tag" of your uplink and exit node data traffic as automatically suspicious.

Why not open up a Feature request on https://github.com/simplex-chat/simplex-chat/issues

What I know so far: 1. Compiling to iOS is "reasonably straightforward", see this repo for Intel-based Mac setup, on M1 mac it "should be" easier, as the code is natively executable and GHC binary is available for M1 CPUs from 8.10.7 (I think), so you don't even need to compile it. 2. Compiling to Android (you didn't ask for it, but still) was only done for GHC 8.4 as far as I know - see this post - not sure if it's possible to do with a newer version, but it took me 30min to downgrade our codebase to 8.4.4, so the difference seems not critical, if not. 3. Template Haskell cross-compilation is, at best, an extra challenge - see this post, for example: https://www.tweag.io/blog/2020-11-25-asterius-th/ . In your code you can probably avoid using it, but some libraries might use it - not sure yet how critical it is.. 4. FFI for C/C++ import/export is relatively straightforward, but writing Storable instances to marshall/unmarshall Haskell types to/from C structs with the existing tooling is quite annoying with lots of boilerplate - definitely some place for improvement here. 5. Connecting Haskell code to SQLite - it "should be" doable, as there is the same C api on all platforms. 6. Connecting Haskell code to network - most people would need http(s), we need tcp/tls, so in theory it should be doable to fork the libraries and replace c-bindings to keep the interface (and possibly to compile conditionally), but at best - it's non-trivial, at worst - can be impossible to keep Haskell APIs and would require replacing the libraries and changing the application code...