In persistence.go, the lack of sufficient knowledge for constructing
fully initialized Community objects required clients to manually call
`initializeCommunity`. This commit addresses the issue by delegating
Community creation to Manager. It also removes queries and logic
duplication.
Fixes https://github.com/status-im/status-desktop/issues/12558
When getting kicked out of a community, before we used to leave the community completely, but just keep the filters on.
That created a problem when reopening the app, because the community disappeared and could even create a problem in desktop where it tried to open the last opened community but it's no longer there.
The fix now is that when getting kicked out, we instead just remove ourselves from the community and set Joined to false, but we keep the community spectated.
This commit changes the format of the encryption id to be based off 3
things:
1) The group id
2) The timestamp
3) The actual key
Previously this was solely based on the timestamp and the group id, but
this might lead to conflicts. Moreover the format of the key was an
uint32 and so it would wrap periodically.
The migration is a bit tricky, so first we cleared the cache of keys,
that's easier than migrating, and second we set the new field hash_id to
the concatenation of group_id / key_id.
This might lead on some duplication in case keys are re-received, but it
should not have an impact on the correctness of the code.
I have added 2 tests covering compatibility between old/new clients, as
this should not be a breaking change.
It also adds a new message to rekey in a single go, instead of having to
send multiple messages
With the recent introduction of pending states, the community requests
logic became more complex. This commit simplifies the flow and
appropriately delegates logic to its corresponding abstraction levels:
messenger, manager and community. Additionally, it eliminates
redundancies in notifications and request-saving mechanism.
- use protected topics for communities
- associate chats to pubsub topics and populate these depending if the chat belongs to a community or not
- mailserver functions should be aware of pubsub topics
- generate private key for pubsub topic protection when creating a community
- add shard cluster and index to communities
- setup shards for existing communities
- distribute pubsubtopic password
- use protected topics for communities
- associate chats to pubsub topics and populate these depending if the chat belongs to a community or not
- mailserver functions should be aware of pubsub topics
- generate private key for pubsub topic protection when creating a community
- add shard cluster and index to communities
- setup shards for existing communities
- distribute pubsubtopic password
- fix: do not send the requests to join and cancel in the protected topic
- fix: undefined shard values for backward compatibility
- refactor: use shard message in protobuffers
New contracts and contract go functions.
Adjust owner&master tokens deployment flow.
Create deployment signature.
CommunityTokens API for handling signer pubkey.
Issue #11954
- share requests to join with new privileged roles during reevaluating member role
- share requests to join with new members, joined the community as TOKEN_MASTER, ADMIN
- share requests to join revealed addresses to ADMINS and TOKEN_MASTERS
- refactor common test functionality to make them more predictable
- removed unused CommunityToken protobuf
Mykhailo Prakhov
Patryk Osmaczko
Mikhail Rogachev
Mykhailo Prakhov
Richard Ramos
Vitaly Vlasov
Dario Gabriel Lipicar
Sale Djenic
Jonathan Rainville
Andrea Maria Piana
Michal Iskierko
Anthony Laibe