HTTPS is point-to-point encryption. It's good for client <-> server communication.
If you need to send data to another client through the server, then HTTPS won't suffice. The server decrypts the data and then sends it to the other client via HTTPS.
So if there's more than two points (client <-> server <-> client) you'll need end-to-end encryption.
Yeah, that'd be pretty tricky. End-to-end encryption is really easy to implement if you're sending data to only one user. It gets really hard and really slow once you start adding more users.
A simple way would be to encrypt your message with a symmetric key. Then encrypt this symmetric key with your private key, and create a copies of it for each recipient and encrypting it with their public key. So each recipient can decrypt the symmetric key and use that to decrypt the message.
You can probably guess that this gets really messy as you start adding more users. And you need to know the difference between symmetric key encryption and public key encryption.
It's probably better to look at a peer-to-peer solution, or find a more efficient protocol. This is a pretty enlightening StackOverflow post on the subject:
Most public/private use symmetric encryption for the data anyway but they use a key derivation scheme to share the key. You can't use public/private encryption for data size greater than the key size. Obviously you can sign/verify any data size.
Also, above you said "encrypt this symmetric key with your private key", did you mean sign this symmetric key?
