| The problem with web apps is that doing timing sensitive stuff such as encryption and decryption in javascript is risky and difficult. Javascript also takes a serious toll on performance and battery life. I'm assuming "completely offline" means that it still sends some data somewhere, otherwise the messenger wouldn't make any sense. I don't really understand the need for it to be a web app other than developer convenience. Electron and friends are a solution to the problem "I don't want to write Qt code", but a good platform for applications they are not. Adding encryption (proper encryption) to the Telegram client would net you a fully native experience that works cross-platform without issues. Going native also allows you access to stuff like TPMs, although you can assume most desktop machines still don't have them. You also have much more control over the security properties of the code if you stick to native code. The folks over at Matrix are experimenting with running their Matrix servers in a peer to peer configuration on the device itself. Stuff that server into a cross platform client like Fluffychat or Element and you've got yourself a chat app with federation and cross platform chat support without relying on any specific server. If you want to stick to a browser only solution, I'm not entirely sure how you'd go about making that talk to other clients. IPFS requires access to a third party gateway, as do most peer to peer solutions. I think you can make WebRTC work as a means of full P2P through a DHT but I'm not entirely sure how. The problem with a simple, offline, encrypted chat client is that it's not simple. Security is very hard; if you're willing to give that up, there's plenty of IRC web clients for you to choose from. If you've got any good ideas on how to build this, I encourage you to work it out and make a proof of concept, because it sounds like it could be very useful. |
This feels like somewhere WebAuthn and/or Emscripten/WASM help a little bit here? I'm most worried about vulnerabilities to the underlying protocol and less about perf/battery life (maybe some side-channel attacks?).
> I'm assuming "completely offline" means that it still sends some data somewhere, otherwise the messenger wouldn't make any sense.
Yes, I did a bad job of explaining this, but online-when-you-need-to-be. "offline" was meant to mean "offline-first", a common frontend terminology for PWAs.
> Adding encryption (proper encryption) to the Telegram client would net you a fully native experience that works cross-platform without issues. Going native also allows you access to stuff like TPMs, although you can assume most desktop machines still don't have them. You also have much more control over the security properties of the code if you stick to native code.
> The folks over at Matrix are experimenting with running their Matrix servers in a peer to peer configuration on the device itself. Stuff that server into a cross platform client like Fluffychat or Element and you've got yourself a chat app with federation and cross platform chat support without relying on any specific server.
Well that would be great, I'd love to just do that.
> If you want to stick to a browser only solution, I'm not entirely sure how you'd go about making that talk to other clients. IPFS requires access to a third party gateway, as do most peer to peer solutions. I think you can make WebRTC work as a means of full P2P through a DHT but I'm not entirely sure how.
I think you can get away with signaling (STUN/TURN) here -- if you have WebRTC you can go STUN-only and even if you have to TURN if you're sending encrypted data then it shouldn't matter. Honestly I think IPFS is actually overkill for this (though it has it's upsides), the only technology you really need for this to work is WebRTC + a STUN/TURN server.
> The problem with a simple, offline, encrypted chat client is that it's not simple. Security is very hard; if you're willing to give that up, there's plenty of IRC web clients for you to choose from. If you've got any good ideas on how to build this, I encourage you to work it out and make a proof of concept, because it sounds like it could be very useful.
But at this point we have methods that work, there's no need to rethink the primitives, we've got good well-tested schemes for sending simple messages. In the desktop world simply gpg encrypting and sending files is good enough (even a basic scheme with asymmetric crypto + nonce + symmetric key + symmetric crypto), why is messaging so hard as to be unattempted even in the 1-to-1 case?
Maybe the only way for this to really get it's tired kicked is to just build the thing in a weekend (if I'm right about it being so simple then it "should" be easy, right?) and post it to HN.