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.