* Fix: don't create extra system messages when accepting the CR again
* chore: add one more test for cr flows repeated
* chore: use deprecation.AddChatsCount in contact requests tests
Due to presence of syscall to `epoll_wait` android emulators after Android 10 would crash.
This commit has added `amd64` fallback implementations in 2 spots
- `tcp-shaker` ref : 571aa46f35
- `notify` ref : 0eb36e6c1a
The build flags are updated for fallback implementation to only be used in case of `x86_64` simulators.
status-mobile PR : https://github.com/status-im/status-mobile/pull/17773
fixes#10329
linked with PR #12879
- Adds capacity to mark a message as unread
- Adds capacity to mark a message with mention as unread
- Adds persistence to the marking of the message (change can be seen at
after reboot)
- Adds marking in right click contextual menu
When an open community was created by Device A and shared with Device B and when Device B would request to join such a community, the general channel would be forever in loading state.
This happened because as part of messenger response the chatId of general channel was not sent and mobile client would not fetch that chat data.
This commit fixes that issue by sending chatId as part of messenger response right after the request to join community succeeds.
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.
* feat: Marking Mentions and Replies AC notifications as read also marks corresponding message as seen
* feat: Marking message as seen marks as read corresponding notification (if there is so)
* chore: make messenger activity center test less flaky
* Update VERSION
- show activity center notification if user must reveal addressed to join/rejoin the community
- fixed unit test, added validation that ex-owner receive AC notification
* feat: Add profile showcase messaging part with ecrypted data
* feat: Separate profile showcase categories to provide ablity to store custom data
* fix: review fixes
* feat: move profile showcase out of contact data
* fix: create index on contact id for profile tables
* chore: remove logger from link preview
There were 2 issues:
1) We hard delete requests, that means that on retransmission they will
be recreated, the test has been changed to accommodate this behavior
2) We always used time.now when updating timestamp in notification,
sometimes time is the same so the notification is not updated, we
changed to use what essentially is a clock value
Filters were removed and recreated which resulted in a flaky test.
This was not needed as the filters didn't change, and they won't be
recreated if we reinstall the same filter.
This commit adds a test for out of order messages, which were only
implicitly tested.
It also deletes them after being processed, otherwise they would be
reproceessed each time a message was sent
This commit fixes 3 issues:
1) In some cases, the hash ratchet was not correctly found
2) Out of order messages were not processed correctly as the wrong error
was returned
3) Batched non datasync messages were not processed correctly
Fixes: #4170
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.
Also check pin post permission a bit earlier for the sender, with
canPost() in sendPinMessage(), even though there is a later check down
the line in dispatchMessage().
Fixes#4138
Which specifies that if a user is not a community member & a
chat member, he can't post, react or pin messages in that chat.
Notes:
- also fix&cleanup associated failing tests.
- refactor Community.CanPost() to reflect the new requirement.
- grant code is not fully implemented and is to be removed later.
Fixes https://github.com/status-im/status-desktop/issues/11915
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
* feat: profile showcase preferences basic impl
(squashed)
* feat: save preferences in batch for profile showcase
* chore: add validation for profile showcase settings request
and fix migration order
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
* feat: introduce KickedPending state for community members
* feat: tests for ban/unban pending states
* fix: remove pending And banned members from public serialization
* feat: add check for banning and kicking privileged users
* fix: process only first event when obtaining PendingAndBannedMembers
* fix: review fixes
* fix: proper conditions for kicking and banning checks
* Fix: fix tests after rebase
New contracts and contract go functions.
Adjust owner&master tokens deployment flow.
Create deployment signature.
CommunityTokens API for handling signer pubkey.
Issue #11954
- use `appdatabse.DbInitializer{}` in tests to ensure consistent migrations
- remove protocol's open database functions due to improper
initialization caused by missing node config migration
- introduce `PushNotificationServerConfig` to resolve cyclic dependency
issues
- 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
* sync preferred name;
remove settings.usernames
* update account name when handle settings.preferred_name from backup message
* fix Error:Field validation for 'KeycardPairingDataFile' failed on the 'required' tag
* bump version
* rebase
This commit skips deleting a keystore file for account which are not marked as fully operable
and also skips deleting master key keystore file if a keypair is non operable. It also takes into
consideration the operable property of an account when adding/updating/handling a keypair/keycard.
u3
When we received a remove event from a private group chat out of order,
the chat would not be created.
This was causing some issues if later on we received the previous event.
This commit changes the behavior so that a chat is created.
refactor: associate chats to pubsub topics and populate these depending if the chat belongs to a community or not
refactor: add pubsub topic to mailserver batches
chore: ensure default relay messages continue working as they should
refactor: mailserver functions should be aware of pubsub topics
fix: use []byte for communityIDs
When we switched to marking removed accounts, the handler remained unchanged. It kept
checking for the account existence in the received `protobuf.SyncKeypair` message, instead
of checking a removed flag.
This commit adds support for unfurling static image URLs (not GIFs, not animated WebPs), such as https://placehold.co/600x400@2x.png. It also compresses images before returning them as data URIs to clients.
About compression: the compression strategy leverages the existing function images.CompressToFileLimits. A more comprehensive logic to consider the possibility of multiple image URLs being unfurled simultaneously is yet to be implemented.
Closes#3761
interface for initializing db, which is implemented for appdatabase and
walletdatabase. TBD for multiaccounts DB.
Unified DB initializion for all tests using helpers and new interface.
Reduced sqlcipher kdf iterations for all tests to 1.
The only place where appDB is used in wallet is activity,
which refers to `keycards_accounts` table. So a temporary
table `keycards_accounts` is created in wallet db and updated
before each activity query.
Adding new smart contracts and generated go files.
Deploy token owner function and master token address getter.
Adding deployer and privilegesLevel columns to community_tokens table.
Passing addressFrom to API calls.
Issue #11250
* rm params
* use url data proto
* feat: community channel and user data parsing; improve testing for urls
---------
Co-authored-by: MishkaRogachev <mishkarogachev@gmail.com>
Fixes an issue where if a community had an admin permission, it would be impossible to join as a normal member because the admin permission wasn't satisfied.
Prior to this commit a control node would add the revealed addresses to
the member struct on the community description, which exposes all those
addresses to the public.
We don't want that. Revealed addresses are exclusively shared with
control nodes and should stay there (although, they might be privately
shared among token masters, see
https://github.com/status-im/status-desktop/issues/11610).
In this commit, we no longer add the revealed addresses to the community
description. The addresses are already stored in the requestToJoin
database table so we can take them from there if we need them.
Closes: https://github.com/status-im/status-desktop/issues/11573
This is a bigger change in how community membership requests are handled
among admins, token masters, owners, and control nodes.
Prior to this commit, all privileged users, also known as
`EventSenders`, were able to accept and reject community membership
requests and those changes would be applied by all users.
This commit changes this behaviour such that:
1. EventSenders can make a decision (accept, reject), but merely forward
their decision to the control node, which ultimately has to confirm
it
2. EventSenders are no longer removing or adding members to and from
communities
3. When an eventsender signaled a decision, the membership request will
enter a pending state (acceptedPending or rejectedPending)
4. Once a decision was made by one eventsender, no other eventsender can
override that decision
This implementation is covered with a bunch of tests:
- Ensure that decision made by event sender is shared with other event
senders
- `testAcceptMemberRequestToJoinResponseSharedWithOtherEventSenders()`
- `testRejectMemberRequestToJoinResponseSharedWithOtherEventSenders()`
- Ensure memebrship request stays pending, until control node has
confirmed decision by event senders
- `testAcceptMemberRequestToJoinNotConfirmedByControlNode()`
- `testRejectMemberRequestToJoinNotConfirmedByControlNode()`
- Ensure that decision made by event sender cannot be overriden by other
event senders
- `testEventSenderCannotOverrideRequestToJoinState()`
These test cases live in three test suites for different event sender
types respectively
- `OwnerWithoutCommunityKeyCommunityEventsSuite`
- `TokenMasterCommunityEventsSuite`
- `AdminCommunityEventsSuite`
In addition to the changes mentioned above, there's also a smaller
changes that ensures membership requests to *not* attached revealed wallet
addresses when the requests are sent to event senders (in addition to
control nodes).
Requests send to a control node will still include revealed addresses as
the control node needs them to verify token permissions.
This commit does not yet handle the case of event senders attempting to
kick and ban members.
Similar to accepting and rejecting membership requests, kicking and
banning need a new pending state. However, we don't track such state in
local databases yet so those two cases will be handled in future commit
to not have this commit grow larger.
* feat: proposal for collecting community metrics
https://github.com/status-im/status-desktop/issues/11152
* feat: collecting community message metrics with test
* feat: implement both strategies for fetching community metrics
* fix: review fixes
* fix: calc counts for timestamps
If a message is sent with only 1 image, the album is not generated (no albumID), so then, in the notification handling code, it didn't use the right ID, because it thought it had to use the AlbumID for the message ID
- distribute ratchet keys at both community and channel levels
- use explicit `HashRatchetGroupID` in ecryption layer, instead of
inheriting `groupID` from `CommunityID`
- populate `HashRatchetGroupID` with `CommunityID+ChannelID` for
channels, and `CommunityID` for whole community
- hydrate channels with members; channel members are now subset of
community members
- include channel permissions in periodic permissions check
closes: status-im/status-desktop#10998
This component decouples key distribution from the Messenger, enhancing
code maintainability, extensibility and testability.
It also alleviates the need to impact all methods potentially affecting
encryption keys.
Moreover, it allows key distribution inspection for integration tests.
part of: status-im/status-desktop#10998
**This is a breaking change!**
Prior to this commit we had `AddCommunityToken(token *communities,
croppedImage CroppedImage)` that we used to
1. add a `CommunityToken` to the user's database and
2. to create a `CommunityTokenMetadata` from it which is then added to
the community's `CommunityDescription` and published to its members
However, I've then discovered that we need to separate these two things,
such that we can deploy a community token, then add it to the database
only for tracking purposes, **then** add it to the community description
(and propagate to members) once we know that the deploy tx indeed went
through.
To implement this, this commit introduces a new API
`SaveCommunityToken(token *communities.CommunityToken, croppedImage
CroppedImage)` which adds the token to the database only and doesn't
touch the community description.
The `AddCommunityToken` API is then changed that it's exclusively used
for adding an already saved `CommunityToken` to the community
description so it can be published to members. Hence, the signature is
now `AddCommunityToken(communityID string, chainID int, address
string)`, which makes this a breaking change.
Clients that used `AddCommunityToken()` before now need to ensure that
they first call `SaveCommunityToken()` as `AddCommunityToken()` will
fail otherwise.
* chore: make the owner without the community private key behave like an admin
* Add test for the owner without community key
* chore: refactor Community fn names related to the roles
If user followed onboarding flow to recover his account using seed phrase or keycard,
then `ProcessBackedupMessages` property of node config json object should be set to
`true`, otherwise it should be set to `false` or be omitted.
- Fixed redundant permissions check. If community is set to auto-accept,
then permissions would be checked twice, in
`HandleCommunityRequestToJoin` and `AcceptRequestToJoinCommunity`.
Mitigated it by returning from `HandleCommunityRequestToJoin` immediately
in case of auto-accept.
- Extracted `accountsSatisfyPermissionsToJoin` to remove code
duplication and simplify the logic.
* feat: add api to remove private key and separete owner from private key ownership
For https://github.com/status-im/status-desktop/issues/11475
* feat: introduce IsControlNode for Community
* feat: remove community private key from syncing
* feat: add IsControlNode flag to Community json serialisation
* Update protocol/protobuf/pairing.proto
Co-authored-by: Jonathan Rainville <rainville.jonathan@gmail.com>
---------
Co-authored-by: Jonathan Rainville <rainville.jonathan@gmail.com>
* mute and unmute all community chats when community mute status changes
* unmute community when atleast one channel is unmuted
* fix: save community, extend the function to save muted state and mute duration
chore:
- add CommunityEventsMessage
- refactor community_admin_event to accept a list of events and patch a CommunityDescription
- save/read community events into/from database
- publish and handle community events message
- fixed admin category tests
- rename AdminEvent to Events or CommunityEvents
Adds airdropAddress to the request to join params and a is_airdrop_address flag in the communities_requests_to_join_revealed_addresses table.
This airdropAddress is used by the owner to know which address to use when airdropping
I have encountered a crash in the app after syncing, looks like a
community has been created without a Config.
This crashes the app after the user logs in.
This commit prevents the app from crashing, but does not fix the
underlaying issue (that's something I will have to investigate).
Added tests to validate the behavior.
Check community exists
* feat: don't remove sent mutual state messages on accepting a CR
* fix: don't send mutual state message for a new contact
* chore: move mutual state messages to `addContact`
* fix: use one chat for mutual state messages and contact requests
* fix: change `added` mutual state updatede messages to `accepted`
* feat: Use different content type for each mutual state event system message
* chore: use constants for mutual event system messages test, review fixes
* chore: fix tests related to local contacts map
Modify API to handle also ERC20 tokens.
Modify community_tokens table - keep supply as string since string is easly convertible to bigint.BigInt.
Use bigint.BigInt for supply functions and fields.
Issue #11129
This is the second step of improvements over keypairs/keycards/accounts.
- `SyncKeycardAction` protobuf removed
- `SyncKeypair` protobuf is used for syncing keycards state as well as for all
keycards related changes
- `last_update_clock` column removed from `keypairs` table cause as well as
for accounts, any keycard related change is actually a change made on a related
keypair, thus a keypair's clock keeps the clock of the last change
- `position` column added to `keypairs` table, needed to display keycards in
the same order accross devices
This is the first step of improvements over keypairs/keycards/accounts.
- `SyncKeypairFull` protobuf removed
- `SyncKeypair` protobuf is used for syncing all but the watch only accounts
- `SyncAccount` is used only for syncing watch only accounts
- related keycards are synced together with a keypair
- on any keypair change (either it's just a keypair name or any change made over an
account which belongs to that keypair) entire keypair is synced including related keycards
- on any watch only account related change, that account is synced with all its details
This commit extends the `AddCommunityToken` API to also expect an
optional `CroppedImage`, which will be used instead of the `ImageBase64`
path provided by `CommunityToken`, to calculate the actual base64
encoded image.
* feat(share-links): Add protobuf and encode/decode url data methods
* feat(new-links-format): Adds generators for new links format
* feat: add parsing for new links format
* feat: add messenger-level pubkey serialization and tests
* feat: fix and test CreateCommunityURLWithChatKey
* feat: impl and test parseCommunityURLWithChatKey
* feat: fix and test CreateCommunityURLWithData
* feat: impl and test parseCommunityURLWithData (not working)
* feat: UrlDataResponse as response share urls api
* feat: impl& tested ShareCommunityChannelURLWithChatKey
* feat: impl & tested ParseCommunityChannelURLWithChatKey
* fix: bring urls to new format
* feat: add regexp for community channel urls
* feat: impl & test contact urls with chatKey, Ens and data
* fix: encodeDataURL/encodeDataURL patch from Samyoul
* fix: fix unmarshalling protobufs
* fix: fix minor issues, temporary comment TestParseUserURLWithENS
* fix: allow url to contain extra `#` in the signature
* fix: check signatures with SigToPub
* chore: lint fixes
* fix: encode the signature
* feat: Check provided channelID is Uuid
* fix(share-community-url): Remove if community encrypted scope
* fix: review fixes
* fix: use proto.Unmarshal instead of json.Marshal
* feat(share-urls): Adds TagsIndices to community data
* feat: support tag indices to community url data
---------
Co-authored-by: Boris Melnik <borismelnik@status.im>
When deleting a message for me, the image url wasn't preserved,
resulting in the image disappearing on the client side.
This commit adds the processing of returned messages so that the image
is preserved.
- Add ERC20 contract
- Add decimals field to community_tokens db table
- Adjusting API to handle assets deployment
- Add decimals field to CommunityTokenMetadata
Issue #10987
Nameserver is passed by the OS on creation/restore, this commit adds the
ability to pass it at login time.
We don't want to store it on disk since that's bound to change, and
currently there's a bug on golang that prevents getting the DNS from the
system on android.
There's only one scenario in which a `RevealedAccount` will have an
empty `ChainIDs` list attached to it:
When the community in question requires users to satisfy certain
criteria to join, and the user's wallet does not own the necessary funds
on any of the supported chains.
If there are **no** permissions to join on the community, then we want
to reveal all (selected) accounts with all supported chainIDs.
This is necessary so that, once the community *does* become
permissioned, it'll have address + chain information from all joined
members.
Closes: https://github.com/status-im/status-desktop/issues/11255
This commit adds new tables to the database and APIs in `Messenger` and
communities `Manager` to store `CheckChannelPermissionsResponse`s.
The responses are stored whenever channel permissions have been checked.
The reason we're doing this is so that clients can retrieve the last
known channel permission state before waiting for onchain checks to
finish.
Sometimes confirmation for raw messages are received before the record
is actually saved in the database.
In this case, the code will preserve the Sent status.
Improve `RequestToJoinCommunity` to accept `Addresses` in the request. If `Addresses` is not empty, we then only pass to the owner the selected addresses. The others are ignored.
Does not validate that the addresses in the slice are part of the user's wallet. Those not part of the wallet are just ignored.
This API is used to get a permission status of all channels of a given
community.
Clients can use this API to get the provided information for all
community channels with a single RPC call instead of doing one call
for each channel separately.
Similar to `CheckPermissionToJoin()` we now get
a `CheckChannelPermissions()` API.
It will rely on the same `PermissionResponse` types, but gives
information about both `ViewOnlyPermissions` and
`ViewAndPostPermissions`.
This seems to be a bug that was introduced when two features, admin
permissions and "always reveal wallet accounts" where merged.
We need to make sure we **first** check the revealed accounts and only
**then** do we perform permission checks on them. Otherwise we can run
into scenarios where fake addresses are used and users will be accepted
to the community.
found
Turns out that, when we return with an error, instead of
a non-statisfied check permissions response, we can run into cases where
members that should be kicked are not kicked.
Change smart contract with new API.
Update gas amount for deployment.
Add Burn() and EstimateBurn() functions.
Add RemainingSupply() functions.
Issue #10816
It happens that an envelope is sent before it's tracked, resulting in
long delays before the envelope is marked as sent.
This commit changes the behavior of the code so that order is now
irrelevant.
When we reply to our own message with an image, we didn't set the URL of
the image of the message, which resulted in the image not being
displayed correctly.
This commit does a few things:
- Adds a migration that adds chainids to communities_request_to_join_revealed_addresses
- Removes RevealedAddress in favor of RevealedAccount which is now a struct that contains the revealed address, as well as the signature and a list of chain IDs on which to check for user funds
- Changes the logic of sending requests to join a community, such that after creating address signatures, the user node will also check which of the addresses has funds on which networks for the community's token permissions, and add the chainds to the RevealedAccount
- Updates checkPermissionToJoin() such that only relevant chainids are used when checking user's funds. Chain IDs are retrieved from RevealedAccounts and matched against token permission criteria chain IDs
There's two scenarios in which we're leaving a community:
We either get kicked or we leave ourselves.
In case of leaving ourselves it's fine to unsubscribe from further
community updates be cause we deliberately chose to leave.
In case of being kicked however, this is different.
Say I'm kicked from a community because its token permissions have
changed, in this case we don't want clients to manually re-subscribe to
the community to get informed when there were further changes.
status-go should rather not unsubscribe if we know for sure we've been
kicked by someone else.
fix flaky test: TestRetrieveBlockedContact
resolve conflict when rebase origin/develop
Feat/sync activity center notification (#3581)
* feat: sync activity center notification
* add test
* fix lint issue
* fix failed test
* addressed feedback from sale
* fix failed test
* addressed feedback from ilmotta
go generate ./protocol/migrations/sqlite/...
feat: add updated_at for syncing activity center notification
Godfrain Jacques
Igor Sirotin
Michal Iskierko
Mykhailo Prakhov
Cuteivist
Sale Djenic
Mikhail Rogachev
Siddarth Kumar
Patryk Osmaczko
Boris Melnik
Andrea Maria Piana
Dario Gabriel Lipicar
Ibrahem Khalil
richΛrd
BalogunofAfrica
Omar Basem
frank
Mohsen
Vitaly Vlasov
Mykhailo Prakhov
Jonathan Rainville
Volodymyr Kozieiev
yqrashawn
Teodor M. Ionita
Shinnok
Khushboo-dev-cpp
Alexander
Vitaliy Vlasov
Anthony Laibe
Icaro Motta
Ivan Belyakov
Felicio Mununga
flexsurfer
Pascal Precht
Anthony Laibe
Samuel Hawksby-Robinson
John Ngei
Roman Volosovskyi
MishkaRogachev
