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.
* 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_: accept community join request with mvds
* chore_: no sender when use mvds in comm join response
* fix_: only use mvds for tokenized communities
* chore_: add comment for this.
- TokenMaster request shared addresses on restoring from a backup
- Fixes sharing members revealed adresses
- Filter out outdated ApplicationMetadataMessage_COMMUNITY_PRIVILEGED_USER_SYNC_MESSAGE messages
This commit removes the list of members from non token gated channels.
Unfortunately is a breaking change. I could make it non-breaking, but
we would lose any performance benefit.
For clients, the pseudo code for checking the member list of a channel
is:
```
members := channel.TokenGated ? channel.Members : community.Members
```
Fixes https://github.com/status-im/status-desktop/issues/15175
The problem was that we used StartMembersReevaluaitonLoop in createCommunityPermission, in case the loop was never started. Indeed it worked if it was the first ever permission, because the loop would then start and members would be re-evaluated.
However, if the loop was already started, in the case where there were previous permissions, the call would just early exit, because it was already started.
The solution here is to use `ScheduleMembersReevaluaiton` like other permission functions use. To make sure a first permission still works, we call startLoop in schedule if the task doesn't exist.
* feat(community)_: Move images from community data to MediaServer
* test_: fix lint issue
* test_: add more test statements
* feat_: deprecate old API
* test_: addressed review feedback from Icaro
* fix_: addressed review feedback from Jonathan
* chore_:wrap image url in an object
Fixed logic to respect specified NFT quantities. Previously, holding one
NFT sufficed, regardless of the required count.
fixes: status-im/status-desktop#15122
Prevent the inclusion of CommunityDescription with an outdated clock in
MessengerResponse to avoid false-positives in tests and reduce redundant
data exchange between status-go and clients.
That's an optimisation. Instead of fetching collectibles owners for each
member, it is fetched once, before members iteration.
It should significantly reduce amount of queries to providers.
closes: status-im/status-desktop#14914
I've renamed TorrentManager to ArchiveManager, ArchiveManager to ArchiveFileManager, TorrentContract to ArchiveService, ArchiveContract to ArchiveFileService. I've also renamed all init functions and struct fields to the appropriate archive-centric naming.
Instead of using the TorrentContract interface I've set the field to expicitly declare as *TorrentManager. This removes all the random type casting used in the tests. I also removed all the usages of buildTorrentConfig() as we build the test suite with the torrent config now.
To be honest once I started this work I quickly realised how pointless it is as archiving functionality and torrent seeding functionality are really entwined. So I'm keeping the code I've done but it is a bit pointless without spending a lot of time untangling torrenting and archiving. I'm just going to make an interface for all the functions that are used publically from TorrentManager. I think that this will be the fast way to move on from this issue. I don't like this work any more, there is a lot of work to do elsewhere and torrent is a rabbit hole filled with canned worms.
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.