[hardwaresofton]

Taking advantage of this post to ask about this -- can anyone explain to me why Signal can't be implemented as a completely offline-first/PWA web-app.

If we throw away the more advanced requirements of perfect forward secrecy, non repudiation, ratcheting for groups, non repudiation, why is it a bad idea to get 80% of the way there with basic offline-first/WPA (+/- secure enclave, WebAuthN, whatever else) messages that are stored on peoples' devices, encrypted before being sent out etc.

Excalidraw is an excellent app that's actually already written about this[0], so we know it's possible in some form. There's exciting p2p technology in the browser (ipfs, gun, etc). To reach all the platforms you could use Electron and in the future Tauri (which purports to be less of a drain on system resources), etc.

What am I not seeing about why this fundamentally can't be done and I can enjoy relatively simple encrypted chat without worrying about installing too many things, in a throw-away shell somewhat similar to pastenow.me? Is it just that no one has built it? surely not

NOTE -- I don't mind too much about not having to be online at the same time to share information with someone else, I don't think it's too hard these days to coordinate a time to share initial contact information/status

[EDIT] correct "offline" to "offline-first/PWA" since it was leading to confusion, didn't include the "-first" enough places, clearly.

[finance_br0]

I don't get it. Why would a messaging app be offline? Do you mean you could send out messages even while you're offline, and the app would wait until it has a connection and send those messages out immediately?

[hardwaresofton]

Sorry the offline there is "offline-first", you need offline-first (AKA modern PWA type technology/architecture) for websites to work well in patchy internet/etc. The "offline-first" phrase/terminology is well known in frontend circles but maybe not as widely as I thought.

Generally offline-first/PWAs can be made "installable" by setting metadata on the page that hosts them and doing other things.

[jeroenhd]

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.

[hardwaresofton]

> 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.

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.

[chrisseaton]

> can anyone explain to me why Signal can't be implemented as a completely offline web-app

It's a messaging app. What's the point of a messaging app if you're never connected to anyone else to message them?

[hardwaresofton]

Edited for clarity, what I meant there was offline-first/PWA. The idea of being able to do things completely offline and use some other medium is also interesting, but what I mean to convey is web apps built with the expectation that the internet may not be connected (and keep working).

Generally offline-first/PWAs can be made "installable" by setting metadata on the page that hosts them and doing other things.

[discardedrefuse]

You might want to check out Secure ScuttleButt. Its an offline first social media protocol. It does more than simple messaging though.

[hardwaresofton]

Yeah ScuttleButt just seemed to have too much going on, I haven't looked at it in a long while (and have no reason to). I invested some time into figuring out the difference between scuttlebutt, IPFS, gun and others but it was a bit of a headache. It does feel like one of them can get you 90% of the way there though.

[imron]

> why Signal can't be implemented as a completely offline-first/PWA web-app.

Because some people want and/or need the things you said to just throwaway.

[hardwaresofton]

Some people do, but not everyone, and I'm personally not interested in an app that does it perfectly but no one can use.

Also, I did not mean to imply that the features could not be done -- they ostensibly can, it's just that I am not willing to accept the lack of them or possible lack of them as a reason, because a lot of people don't even know it's happening/don't know when it's missing. More interested in increasing the base of people who use more secure messaging that is more independent and simpler to understand where possible.

[robjan]

The whole point of signal is that it's secure and has reasonable UX. As soon as you can start choosing security parameters it becomes unnecessarily complicated for the average person with added scope to mess something up

[hardwaresofton]

Well the question is is there an even easier signal that is some reasonable mix of secure and reasonable UX? There are important features that Signal has left out (not requiring a phone number to sign up being the most egregious) -- the question I'm asking is whether there is another point in that space of tradeoffs.