Needed for https://github.com/status-im/status-desktop/issues/16640
In Desktop, we still used a "forked" version of the BlockContact function that had as differences that it didn't leave the chat nor delete the messages.
However, we want to have parity now and those features, so it makes no sense to use a different function.
This is a breaking change because it removes an API, but I took care of removing the use of that function in the Desktop app and Mobile never used it, so it's an inoffensive breaking change.
Additionally, I added the notifications to the messenger response.
Found when fixing https://github.com/status-im/status-desktop/issues/16639
When a message is deleted, we need to delete the pins too as they are no longer available. This was done using an ON DELETE clause (thanks @osmaczko)
I also made sure the SELECT query for the pins doesn't return deleted messages
Fixes https://github.com/status-im/status-desktop/issues/16817
There were two issues.
When dismissing a CR, then sending one back, it did mark the two contacts as mutual and showed the 1-1 chat. However, the message sent in the second/final CR was not shown in the first person's client.
Also, the AC notification for the first user didn't update, so it got stuck in a "pending" state.
Those two issues are fixed now with a test to confirm.
Fixes https://github.com/status-im/status-desktop/issues/16688
Since we use the local image server to show the community image, the URL never changes when we update the image, since it's served using a query string containing the community ID. eg: `https://Localhost:46739/communityDescriptionImages?communityID=0x03c5ece7da362d31199fb02d632f85fdf853af57d89c3204b4d1e90c6ec13bb23c&name=thumbnail`
Because of that, the clients cannot know if the image was updated, so they had to force update the image every time, which was inefficient.
We discovered this issue when I refactored the community client code in Desktop so that we only update the changed properties of a community instead of reseting the whole thing.
The solution I came up with in the PR is to add a `version` to the URL when we detect that the image changed. This let's the clients detect when the image was updated without having to do any extra logic.
Fixes https://github.com/status-im/status-desktop/issues/16741
The issue was that in image messages, you can update the text, but then the ContentType would become Text and lose the image.
The solution is to ignore ContentType changes, since there is no way to change the type of message.
The community cache that the image server was using was not intended to be used for that. It can be invalidated at any moment. Also, it did not contain changes made by admins (admin events).
Using this new approach, we pass functions from the community manager to the media server so that it can have access to the correct community description.
This caused communities being passed to the client via `handleCommunitiesSubscription` to not have images and they would "flash" in the client because it would disappear for a second then come back when another signal updated it back.
* fix_: chats and message history loading after login takes too much time
* chore_: split to small functions to writing unit test easily
* test_: add test
* chore_: improve OldestMessageWhisperTimestampByChatIDs function
- Use 'any' type instead of 'interface{}' for args slice
- Add error check after rows iteration
* chore_: optimize OldestMessageWhisperTimestampByChatIDs query
This commit simplifies and optimizes the SQL query in the OldestMessageWhisperTimestampByChatIDs function. The changes include:
1. Removing the subquery and ROW_NUMBER() function
2. Using MIN() and GROUP BY instead of the previous approach
3. Directly selecting the required columns in a single query
These changes should improve the performance of the function, especially for large datasets, while maintaining the same functionality.
Ensure that communities created prior to the introduction of tokenized
ownership propagate community ID through the description.
fixes: status-im/status-desktop#16226
* fix(sync)_: Improve EnableInstallationAndSync and add EnableInstallationV2
- Refactor EnableInstallationAndSync for better error handling and response merging
- Add new EnableInstallationV2 method returning the installation
- Update tests to check for installation in response
- Deprecate old EnableInstallation method
* chore_: remove EnableInstallationV2
* fix(sync)_: create/delete AC notification only when targetInstallationID match
- Add targetInstallationID parameter to SendPairInstallation function
- Update protobuf SyncPairInstallation struct with TargetInstallationId field
- Modify method calls across multiple test files to include new parameter
- Update pairing.proto and pairing.pb.go with new field for local pairing
* chore_: rename stubEnableInstallationAndPair
chore_: move InstallationIDProvider
chore_: revert endpoints.go
test_: check AC with resp
chore_: rename ModifiedInstallationsTargetedToThisDevice
test_: add InstallationIDProvider
chore_: revert endpoints.go
chore_: remove comment
test_: add TestNewInstallationCreatedIsNotDeleted
Syncing the entire community for potentially frequent actions like
`LastOpenedAt` updates is highly inefficient when using Waku as the
transport layer, as it can result in significant bandwidth overhead.
We remove the shared accounts to send normal admins to not leak the addresses, however, that was a destructive action that also removed them from the `requestToJoin` param, which is reused later in the code, so it created an unwanted side effect. The side effect is now erased.
Logs from `messenger_mailserver` occupy 40 out of 100MB of data in
my `geth.log`.
Instead of extending `logger` with many parameters, such as `chatIDs`,
`topic`, etc., the hash of those parameters is calucalted and kept as a
context.
iterates: #5889
Fixes https://github.com/status-im/status-desktop/issues/16323
The problem was that the code expected to receive the Discord message ID, but the bridge is smart enough to return the Status message ID already, so there is no need to try and convert it.
There were also a couple issues in the bridge code itself.
* feat_: log error and stacktrace when panic in goroutine
* test_: add test TestSafeGo
* chore_: rename logAndCall to call
* chore_: rename SafeGo to Go
* chore_: make lint-fix
* chore_: use t.Cleanup
* chore_: Revert "chore_: use t.Cleanup"
This reverts commit 4eb420d179cc0e208e84c13cb941e6b3d1ed9819.
* chore_: Revert "chore_: make lint-fix"
This reverts commit fcc995f157e671a4229b47419c3a0e4004b5fdab.
* chore_: Revert "chore_: rename SafeGo to Go"
This reverts commit a6d73d6df583f313032d79aac62f66328039cb55.
* chore_: Revert "chore_: rename logAndCall to call"
This reverts commit 8fbe993bedb9fbba67349a44f151e2dd5e3bc4cc.
* chore_: Revert "test_: add test TestSafeGo"
This reverts commit a1fa91839f3960398980c6bf456e6462ec944819.
* chore_: Revert "feat_: log error and stacktrace when panic in goroutine"
This reverts commit f612dd828fa2ce410d0e806fe773ecbe3e86a68a.
* feat_: log error and stacktrace when panic in goroutine
* chore_: make lint-fix
* chore_: rename logAndCall to call
* chore_: renaming LogOnPanic
* chore_: update rest goroutine function calls
* chore_: make lint-fix
* feat(sync)!: remove compatibility with v2.29
* feat(sync)_: add AC notifications when initiating the sync fallback
Needed for https://github.com/status-im/status-desktop/issues/15750
Adds an AC notification when the syncing fails and the user is prompted to use a seed phrase instead.
There is one notification for the initiator (created) and one for the old account (received).
Once the flow is completed, ie the receiver presses Enable and sync, the notifications are deleted
* test_: update test
* fix_: lint issue
* chore_: ignore tmp file generated by make lint-fix
* chore_: rename EnableAndSyncInstallation to EnableInstallationAndSync
* chore_: address review feedback
* chore_: revert changes to .gitignore
* fix_: simplify code
* fix_: keep old API
---------
Co-authored-by: Jonathan Rainville <rainville.jonathan@gmail.com>