f6c9ec7838
This commit introduces a few changes regarding users accessing communities: While the APIs still exist, community invites should no longer be used, instead communities should merely be "shared". Sharing a community to users allows users to "join" the community, which in reality makes them request access to that community. This means, users have to request access to any community, even if the community has permissions set to NO_MEMBERSHIP Only difference between ON_REQUEST and NO_MEMBERSHIP is that ON_REQUEST communities require manual approval of the owner/admin to access a community. NO_MEMBERSHIP communities accept automatically (as soon as owner/admin receives the request). This also implies that users are no longer optimistically added to the member list of communities, but only after they have been accepted. This introduces a bit of a message ping-pong for users to know that someone is now part of a community
protocol/encryption package
Hash ratchet encryption
encryptor.GenerateHashRatchetKey() generates a hash ratchet key and stores it in in the DB.
There, 2 new tables are created: hash_ratchet_encryption and hash_ratchet_encryption_cache.
Each hash ratchet key is uniquely identified by the (groupId, keyId) pair, where keyId is derived from a clock value.
protocol.BuildHashRatchetKeyExchangeMessage builds an 1-on-1 message containing the hash ratchet key, given it's ID.
protocol.BuildHashRatchetMessage builds a hash ratchet message with arbitrary payload, given groupId. It will use the latest hash ratchet key available. encryptor.encryptWithHR encrypts the payload using Hash Ratchet algorithms. Intermediate hashes are stored in hash_ratchet_encryption_cache table.
protocol.HandleMessage uses encryptor.decryptWithHR fn for decryption.