I've removed any mention or dependency of TorrentManager from Manager. There is still more work to do, but Messenger now communicates directly with a TorrentManager rather than asking the communities Manager to handle it. I've ensured that LogStdout() is only called from TorrentManager and removed entirely from Manager, this functionality seems to be some kind of debug tool specifically for torrent related functionality. Next I need to focus on functions within Messenger that call a TorrentManager and see how to isolate these from the main flows, following that I also need fix the tests that are broken. I will also need to refactor torrentClientReady() so that it is a function of TorrentManager, this may allow for pushing more functions into TorrentManager which will lead to better torrent encapsulation.
I'm not particularly proud of this work. I've just passed in all the deps as vars, there are way too many concerns handled by the TorrentManager that I don't know what is the best approach to removing them. I've even resorted to declaring an 'Publisher' interface to handle all the 'publish()' calls the TorrentManager makes. Next up I need to resolved the communities Manager API, because I've removed all of its end points. The TorrentManager needs to be a lot more simple than it is.
Code moved into new TorrentManager. This commit is BROKEN! The code is not ready to use so don't use it, lots more work to do. Biggest problem is that the torrent management in Manager is very tightly coupled to sending encrypting etc. All of that needs to be prised apart
Send information to owners and token masters about operations: burn, airdrop, remote destruct.
Add CommunityTokenActionSignal to signalize client side.
Fix#13371
Add ReTrackOwnerTokenDeploymentTransaction function which will runs community tokens transactions listening.
Add deployment transaction hash to community_tokens table.
Issue #14699
fix(communities)_: Receiving mention notifications (@everyone) from spectated communities #14798
Fix condition to check if user has joined community isCommunityJoinedBeforeClock
Fixes#14798
This avoids locking of the community until the end of reevaluation.
There is no special handling for community changes while reevaluation is
ongoing. If members are added or removed, the function will behave
correctly. If permissions are changed, they will be accommodated in the
next reevaluation.
fixes: status-im/status-desktop#14775
Light functions are based on the fact that permissions are met if the user is on community/channel member list.
If the user is not on the list, permissions will not be met and the client is responsible to use regular permissions-check functions.
For all permissions-check functions, corresponding light versions are added: CheckAllChannelsPermissionsLight,
CheckChannelPermissionsLight, CheckPermissionToJoinLight.
Issue #14220
Use EventWatcher to catch wallet events.
Handling all community tokens wallet events in communitytokens service (database and messenger operations).
Adding new signal to nim: CommunityTokenTransactionSignal, which is emitted everytime when the event is received.
Issue #4351
Fixes https://github.com/status-im/status-desktop/issues/14421
The problem is that you can receive messages to a channel, then later, before marking them as read, a permission is added to them, so you no longer have access.
Then, you can't even mark it as read if it's hidden.
Here, I fix it by setting the unread count on Init at 0 if the user doesn't have view access to it. And I make sure we update the counts when we are removed from a channel
* fix_: prevent publishing older community description
* fix_: schedule member reevaluation instead of reevaluating in parallel
* fix_: lock community on members reevaluation
* fix(TestJoinCommunityAsAdminWithMemberAndAdminPermission)_: setup waitOnCommunitiesEvent in advance
* fix(TestEditSharedAddresses)_: remove redundant community description retrieval
This commit attempts to upgrade go version to 1.20.12
This commit also removes the following items from lint checks :
* `goconst`
* `structcheck`
* `deadcode`
* `golint`
* `varcheck`
Mobile PR for QA purposes -> https://github.com/status-im/status-mobile/pull/19564
`ReevaluateMembers` is run as a separate goroutine and sometimes it is
executed after `Manager` has been stopped. It tries to use the lock and
in consequence, it panics. Ensuring the map is still there prevents that.
^Happened in test: `TestCreateTokenPermission`.
* feat_: add periodical publishing for community grants
feat_: Validate grant when receiving it
feat_: add expiration for grants
feat_: add test for grants expiration
fix_: move grants test to profile showcase, fix a few bugs
* feat_: use one group mesage to update grants
* chore_: review fixes
Despite the expectation that only validated events are stored in the
database, instances have been identified where invalid events are saved.
This can lead to unexpected behavior or crashes.
This commit adds validation for community events read from the database
to prevent such cases.
**NOTE**: this fix does not address the root cause, which involves
invalid events being saved to the database. The exact scenario leading
to this issue has yet to be identified.
mitigates: status-im/status-desktop#14106
Previously, `CommunityDescription` instances failing partial decryption
were not reprocessed due to duplicate message check. This commit fixes
the issue by bypassing the check for such descriptions, allowing their
reprocessing upon receiving missing encryption key.
fixes: status-im/status-desktop#13647
AmountInWei will have a wei-like units.
Amount field becomes deprecated because it kept string with float value.
Comparison (in case of Decimals == 5):
Amount (deprecated) = "1.2"
AmountInWei = "120000"
Issue #11588
- Extracted `community_events_factory.go`
- Introduced `eventsProcessor`
- Improved processing logic order
- Improved events filtering
- Introduced concept of `EventTypeID` to prevent redundant events handling
- Added sanity check before events appliance when reading community from
database
- Removed reject&re-apply scheme (no more ping-pong issue)
- Fixed and added more variants to eventual consistency test
fixes: status-im/status-desktop#13387fixes: status-im/status-desktop#13388
* chore: move profile showcase structures to the indentity package
* feat: implement proof of membership for unecrypted communities
* feat: implement proof of membership for encrypted communties with grants
This commit adds HighestRole & a list of permissions in order of
importance to the CheckPermissionToJoinResponse.
This simplify client code so that it doesn't need to be calculated on
the client.
This commit fixes a few issues with communities encryption:
Key distribution was disconnected from the community description, this created a case where the key would arrive after the community description and that would result in the client thinking that it was kicked.
To overcome this, we added a message that signals the user that is kicked. Also, we distribute the key with the community description so that there's no more issues with timing.
This is a bit expensive for large communities, and it will require some further optimizations.
Key distribution is now also connected to the request to join response, so there are no timing issues.
Fixes an issue with key distribution (race condition) where the community would be modified before being compared, resulting in a comparison of two identical communities, which would result in no key being distributed. This commit only partially address the issue.
Samuel Hawksby-Robinson
Michal Iskierko
Mykhailo Prakhov
Jonathan Rainville
Godfrain Jacques
Igor Sirotin
Andrey Bocharnikov
Patryk Osmaczko
osmaczko
frank
Ajay Sivan
Siddarth Kumar
Mikhail Rogachev
yqrashawn
Andrea Maria Piana
Michał Iskierko
Icaro Motta
richΛrd
Ibrahem Khalil