2020-11-18 09:16:51 +00:00
syntax = "proto3" ;
2021-08-06 15:40:23 +00:00
option go_package = "./;protobuf" ;
2020-11-18 09:16:51 +00:00
import "chat_identity.proto" ;
2023-03-02 16:19:19 +00:00
import "enums.proto" ;
2020-11-18 09:16:51 +00:00
package protobuf ;
message Grant {
bytes community_id = 1 ;
bytes member_id = 2 ;
string chat_id = 3 ;
uint64 clock = 4 ;
}
message CommunityMember {
2021-01-11 10:32:51 +00:00
enum Roles {
UNKNOWN_ROLE = 0 ;
ROLE_ALL = 1 ;
ROLE_MANAGE_USERS = 2 ;
2022-12-02 11:34:02 +00:00
ROLE_MODERATE_CONTENT = 3 ;
2021-01-11 10:32:51 +00:00
}
repeated Roles roles = 1 ;
Check token funds when handling community requests to join
This adds checks to `HandleCommunityRequestToJoin` and
`AcceptRequestToJoinCommunity` that ensure a given user's revealed
wallet addresses own the token funds required by a community.
When community has token permissions of type `BECOME_MEMBER`, the
following happens when the owner receives a request:
1. Upon verifying provided wallet addresses by the requester, the owner
node accumulates all token funds related to the given wallets that
match the token criteria in the configured permissions
2. If the requester does not meet the necessary requirements, the
request to join will be declined. If the requester does have the
funds, he'll either be automatically accepted to the community, or
enters the next stage where an owner needs to manually accept the
request.
3. The the community does not automatically accept users, then the funds
check will happen again, when the owner tries to manually accept the
request. If the necessary funds do not exist at this stage, the
request will be declined
4. Upon accepting, whether automatically or manually, the owner adds the
requester's wallet addresses to the `CommunityDescription`, such that
they can be retrieved later when doing periodic checks or when
permissions have changed.
2023-03-16 14:35:33 +00:00
repeated string wallet_accounts = 2 ;
2020-11-18 09:16:51 +00:00
}
2023-02-20 11:57:33 +00:00
message CommunityTokenMetadata {
map < uint64 , string > contract_addresses = 1 ;
string description = 2 ;
string image = 3 ;
CommunityTokenType tokenType = 4 ;
string symbol = 5 ;
2023-03-07 14:29:16 +00:00
string name = 6 ;
2023-02-20 11:57:33 +00:00
}
2020-11-18 09:16:51 +00:00
message CommunityPermissions {
enum Access {
UNKNOWN_ACCESS = 0 ;
NO_MEMBERSHIP = 1 ;
INVITATION_ONLY = 2 ;
ON_REQUEST = 3 ;
}
bool ens_only = 1 ;
// https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md is a candidate for the algorithm to be used in case we want to have private communityal chats, lighter than pairwise encryption using the DR, less secure, but more efficient for large number of participants
bool private = 2 ;
Access access = 3 ;
}
2023-03-02 16:27:48 +00:00
message TokenCriteria {
map < uint64 , string > contract_addresses = 1 ;
CommunityTokenType type = 2 ;
string symbol = 3 ;
string name = 4 ;
string amount = 5 ;
repeated uint64 token_ids = 6 ;
string ens_pattern = 7 ;
2023-03-16 14:17:23 +00:00
uint64 decimals = 8 ;
2023-03-02 16:27:48 +00:00
}
message CommunityTokenPermission {
enum Type {
UNKNOWN_TOKEN_PERMISSION = 0 ;
BECOME_ADMIN = 1 ;
BECOME_MEMBER = 2 ;
}
string id = 1 ;
Type type = 2 ;
repeated TokenCriteria token_criteria = 3 ;
repeated string chat_ids = 4 ;
bool is_private = 5 ;
}
2020-11-18 09:16:51 +00:00
message CommunityDescription {
uint64 clock = 1 ;
map < string , CommunityMember > members = 2 ;
CommunityPermissions permissions = 3 ;
ChatIdentity identity = 5 ;
map < string , CommunityChat > chats = 6 ;
2021-03-19 09:15:45 +00:00
repeated string ban_list = 7 ;
2021-05-23 13:34:17 +00:00
map < string , CommunityCategory > categories = 8 ;
2022-03-21 14:18:36 +00:00
uint64 archive_magnetlink_clock = 9 ;
2022-05-10 14:21:38 +00:00
CommunityAdminSettings admin_settings = 10 ;
2022-05-24 19:20:13 +00:00
string intro_message = 11 ;
string outro_message = 12 ;
2022-05-27 09:14:40 +00:00
bool encrypted = 13 ;
2022-06-24 13:40:12 +00:00
repeated string tags = 14 ;
2023-03-02 16:27:48 +00:00
map < string , CommunityTokenPermission > token_permissions = 15 ;
2023-02-20 11:57:33 +00:00
repeated CommunityTokenMetadata community_tokens_metadata = 16 ;
2023-03-28 14:40:00 +00:00
uint64 active_members_count = 17 ;
2022-05-10 14:21:38 +00:00
}
message CommunityAdminSettings {
bool pin_message_all_members_enabled = 1 ;
2020-11-18 09:16:51 +00:00
}
message CommunityChat {
map < string , CommunityMember > members = 1 ;
CommunityPermissions permissions = 2 ;
ChatIdentity identity = 3 ;
2021-05-23 13:34:17 +00:00
string category_id = 4 ;
int32 position = 5 ;
}
message CommunityCategory {
string category_id = 1 ;
string name = 2 ;
int32 position = 3 ;
2020-11-18 09:16:51 +00:00
}
message CommunityInvitation {
bytes community_description = 1 ;
bytes grant = 2 ;
string chat_id = 3 ;
bytes public_key = 4 ;
}
2021-01-11 10:32:51 +00:00
message CommunityRequestToJoin {
uint64 clock = 1 ;
string ens_name = 2 ;
string chat_id = 3 ;
bytes community_id = 4 ;
2022-06-22 18:02:44 +00:00
string display_name = 5 ;
feat: add verified wallet accounts to community requests
This commit extends the `CommunityRequestToJoin` with `RevealedAddresses` which represent wallet addresses and signatures provided by the sender, to proof a community owner ownership of those wallet addresses.
**Note: This only works with keystore files maanged by status-go**
At high level, the follwing happens:
1. User instructs Status to send a request to join to a community. By adding a password hash to the instruction, Status will try to unlock the users keystore and verify each wallet account.
2. For every verified wallet account, a signature is created for the following payload, using each wallet's private key
``` keccak256(chatkey + communityID + requestToJoinID) ``` A map of walletAddress->signature is then attached to the community request to join, which will be sent to the community owner
3. The owner node receives the request, and if the community requires users to hold tokens to become a member, it will check and verify whether the given wallet addresses are indeed owned by the sender. If any signature provided by the request cannot be recovered, the request is immediately declined by the owner.
4. The verified addresses are then added to the owner node's database such that, once the request should be accepted, the addresses can be used to check on chain whether they own the necessary funds to fulfill the community's permissions
The checking of required funds is **not** part of this commit. It will be added in a follow-up commit.
2023-03-17 09:19:40 +00:00
map < string , bytes > revealed_addresses = 6 ;
2020-11-18 09:16:51 +00:00
}
2022-10-28 08:41:20 +00:00
message CommunityCancelRequestToJoin {
uint64 clock = 1 ;
string ens_name = 2 ;
string chat_id = 3 ;
bytes community_id = 4 ;
string display_name = 5 ;
}
2021-01-11 10:32:51 +00:00
message CommunityRequestToJoinResponse {
uint64 clock = 1 ;
CommunityDescription community = 2 ;
bool accepted = 3 ;
bytes grant = 4 ;
2022-07-01 13:54:02 +00:00
bytes community_id = 5 ;
2022-12-09 14:26:12 +00:00
string magnet_uri = 6 ;
2020-11-18 09:16:51 +00:00
}
2022-03-21 14:18:36 +00:00
2022-08-22 10:10:31 +00:00
message CommunityRequestToLeave {
uint64 clock = 1 ;
bytes community_id = 2 ;
}
2022-03-21 14:18:36 +00:00
message CommunityMessageArchiveMagnetlink {
uint64 clock = 1 ;
string magnet_uri = 2 ;
}
message WakuMessage {
bytes sig = 1 ;
uint64 timestamp = 2 ;
bytes topic = 3 ;
bytes payload = 4 ;
bytes padding = 5 ;
bytes hash = 6 ;
2022-09-28 12:45:34 +00:00
string thirdPartyId = 7 ;
2022-03-21 14:18:36 +00:00
}
message WakuMessageArchiveMetadata {
uint32 version = 1 ;
uint64 from = 2 ;
uint64 to = 3 ;
repeated bytes contentTopic = 4 ;
}
message WakuMessageArchive {
uint32 version = 1 ;
WakuMessageArchiveMetadata metadata = 2 ;
repeated WakuMessage messages = 3 ;
}
message WakuMessageArchiveIndexMetadata {
uint32 version = 1 ;
WakuMessageArchiveMetadata metadata = 2 ;
uint64 offset = 3 ;
uint64 size = 4 ;
uint64 padding = 5 ;
}
message WakuMessageArchiveIndex {
map < string , WakuMessageArchiveIndexMetadata > archives = 1 ;
}