is the IM decentralised?
?
The messages services of Gems is based on a distributed instant messaging server which is completely asynchronous to achieve massive scale. This service is implemented on SignalR and OWIN - an open-source stack for running realtime signaling over WebSockets.
Note that every user can chose to be totally anonymous and to have all of his text messages client-client encrypted.
In the future we are thinking about adding public key cryptography. Encrypting messages from a user, to someone else using the recipients public key, that way its tied to the GEM asset and nobody can spy on it.
We also considered integration with other (or additional) blockchains better suited to the capabilities Gems core product requires (maidsafe, Storj, ethereum etc) but the problem is none of them are functional right now. Like we said in the past, we believe that everything that can be decentralized, will be decentralized - Blockchain technology is the future.
How Are Messages EncryptedInstant messages in Gems arrive in two flavors - standard and secret. Standard messages are the default type and provide a standard level of security. Secret messages are meant for highly confidential conversations and provide an extreme level of security and privacy. App users can switch between these two flavors for every chat conversation. Making a conversation secret is very easy, and only requires tapping on the "lock" icon inside the app.
Instant messages are encrypted on two levels. The first level of encryption is relevant for both standard and secret messages. For both types, all communications between the Gems mobile app and the Gems instant messaging cloud server are encrypted - this is also referred to as client-server encryption. Communications between the two is performed over SSL in a secure tunnel (HTTPS) with 256-bit keys. This prevents third-parties from listening in. This also prevents man-in-the-middle attacks and makes sure the Gems app only communicates with the real server and not anyone impersonating it.
The second level of encryption is only relevant for secret messages. On top of the client-server encryption, secret messages also have client-client encryption. Every Gems app generates a unique random pair of 4096-bit public/private keys upon installation. The public key is propagated within the network, but the private key never leaves the device. The public/private pair is unique to a device. If the user transfers his Gems account to a new device, a new pair is created. The key pair is also expired and refreshed periodically to enhance security.
When user A sends a secret message to user B, it's encrypted using RSA 4096 with user B's public key. Once the message arrives to user B's device, it's decrypted with B's private key. Decryption can only take place on user B's device because only this device has access to the correct private key.
The benefit of client-client encryption is that it provides a zero trust environment. The encrypted message cannot even be decrypted by the Gems server infrastructure. This means that even if the Gems servers have been compromised and hacked into, secret messages are still 100% private and can only be decrypted by their rightful recipient.
The drawback of secret messages is that they cannot appear in push notifications. Since push notifications are encrypted by Apple's/Google's infrastructure, they don't conform to zero trust policy. When a secret message is sent from user A to user B, the push notification user B receives contains the text "You've received a secret message from A" instead of showing the actual content of the message.
