* 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
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
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.
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.
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
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.
