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.