If you're interested in peer-to-peer (P2P) encrypted text chat, and seem enthused by using WebRTC for that for multiple people at once, then you might want to think again.
So, if you combine this fantastic example of audio/video chat, strip out audio/video...
https://github.com/nielsbaloe/webrtc-php
...implement RTCDataChannel from WebRTC, and make a true, many-to-many, peer-to-peer text chat (where the server is only used for the signalling step, connecting one or more peers together), it really isn't desirable.
Why?
It's simple -- you won't get state management of the last 100 messages or so that were posted. People like to login and see the last 100 messages in a chat. (That's at least -- many will want to see even more.) And if you want state management, then you're better off just using ordinary AJAX and a web server with ordinary state management (database, RAM file, file, YAML file, JSON file, serialized object file, etc.).
For security, ensure you're running https instead of http, and never permit http connections. To be even more secure, you could ensure the state management is an encrypted shared memory component and/or an encrypted file. By requiring extra HTTP authentication headers and utilizing nonces, you can also add even more security.
Top comments (3)
Another solution is to store the data on all users machines and sync it when they get online together, something like CRDT can help
en.wikipedia.org/wiki/Conflict-fre...
that means you'll keep all the history in all peers machines so you'll have offline search and it's secure as Webrtc connection is already secured, no need for a server to keep the messages at all.
That would be a good solution. Or you could use IPFS. My biggest problem with WebRTC is that the ICE Servers get blocked on 3g/4g and I would to have to work around with websocket, then I can just use a centralized service. But look for yourself: peerweb.site/ (it's not a chat but a p2p hosting, chat could be built on top though)
Fascinating!