There are two types of errors "non-critical" (or "warning") and "critical".
These map to error codes `1` and `2` respectively.
The current error codes are a left-over of initial experimenting.
As part of the new Discord <-> Status Community Import functionality,
we're adding an API that extracts all discord categories and channels
from a previously exported discord export file.
These APIs can be used in clients to show the user what categories and
channels will be imported later on.
There are two APIs:
1. `Messenger.ExtractDiscordCategoriesAndChannels(filesToimport
[]string) (*MessengerResponse, map[string]*discord.ImportError)`
This takes a list of exported discord export (JSON) files (typically one per
channel), reads them, and extracts the categories and channels into
dedicated data structures (`[]DiscordChannel` and `[]DiscordCategory`)
It also returns the oldest message timestamp found in all extracted
channels.
The API is synchronous and returns the extracted data as
a `*MessengerResponse`. This allows to make the API available
status-go's RPC interface.
The error case is a `map[string]*discord.ImportError` where each key
is a file path of a JSON file that we tried to extract data from, and
the value a `discord.ImportError` which holds an error message and an
error code, allowing for distinguishing between "critical" errors and
"non-critical" errors.
2. `Messenger.RequestExtractDiscordCategoriesAndChannels(filesToImport
[]string)`
This is the asynchronous counterpart to
`ExtractDiscordCategoriesAndChannels`. The reason this API has been
added is because discord servers can have a lot of message and
channel data, which causes `ExtractDiscordCategoriesAndChannels` to
block the thread for too long, making apps potentially feel like they
are stuck.
This API runs inside a go routine, eventually calls
`ExtractDiscordCategoriesAndChannels`, and then emits a newly
introduced `DiscordCategoriesAndChannelsExtractedSignal` that clients
can react to.
Failure of extraction has to be determined by the
`discord.ImportErrors` emitted by the signal.
**A note about exported discord history files**
We expect users to export their discord histories via the
[DiscordChatExporter](https://github.com/Tyrrrz/DiscordChatExporter/wiki/GUI%2C-CLI-and-Formats-explained#exportguild)
tool. The tool allows to export the data in different formats, such as
JSON, HTML and CSV.
We expect users to have their data exported as JSON.
Closes: https://github.com/status-im/status-desktop/issues/6690
Otherwise it fails with:
```
build github.com/status-im/status-go/cmd/statusd: cannot load github.com/lucas-clemente/quic-go/internal/qtls: no Go source files
```
We also add missing `g++` compiler for `go-libutp` to fix:
```
go build github.com/anacrolix/go-libutp: g++: exec: "g++": executable file not found in $PATH
```
As well as install `libgcc` and `libstdc++` to avoids failures like this:
```
Error loading shared library libstdc++.so.6: No such file or directory (needed by /usr/local/bin/statusd)
Error loading shared library libgcc_s.so.1: No such file or directory (needed by /usr/local/bin/statusd)
Error relocating /usr/local/bin/statusd: _Znwm: symbol not found
Error relocating /usr/local/bin/statusd: _ZdlPvm: symbol not found
Error relocating /usr/local/bin/statusd: _Unwind_Resume: symbol not found
Error relocating /usr/local/bin/statusd: __gxx_personality_v0: symbol not found
```
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This introduces a flag to configure whether `Messenger.CreateCommunity`
should create a default channel.
As discussed in https://github.com/status-im/status-go/issues/2758, this
is needed for the upcoming functionality to import discord communities.
Closes#2758
This commit introduces a few changes regarding users accessing
communities:
While the APIs still exist, community invites should no longer be
used, instead communities should merely be "shared".
Sharing a community to users allows users to "join" the community,
which in reality makes them request access to that community.
This means, users have to request access to any community, even if
the community has permissions set to NO_MEMBERSHIP
Only difference between ON_REQUEST and NO_MEMBERSHIP is that
ON_REQUEST communities require manual approval of the owner/admin
to access a community. NO_MEMBERSHIP communities accept
automatically (as soon as owner/admin receives the request).
This also implies that users are no longer optimistically added to the
member list of communities, but only after they have been accepted.
This introduces a bit of a message ping-pong for users to know that
someone is now part of a community
fix: add verification request to response
fix: code review
add missing functions and simplify timestamp usage
fix: sync verification requests
feat: add endpoint to fetch all received verification requests
feat: add signal when trusting verification request
Co-authored-by: Jonathan Rainville <rainville.jonathan@gmail.com>
Adding the optional switch to satisfy the following requirements
- Desktop nim app requires to build for x86_64
- Desktop C++ app requires native support with Qt6.3+
The default is still forcing x86_64 builds on apple silicon
Richard Ramos
Pascal Precht
Mikhail Rogachev
Michal Iskierko
Roman Volosovskyi
yqrashawn
Khushboo-dev-cpp
Parvesh Monu
Anthony Laibe
Anthony Laibe
Jakub Sokołowski
Siddarth Kumar
audriu
Churikova Tetiana
Patryk Osmaczko
Vitaliy Vlasov
Andrea Maria Piana
Boris Melnik
frank
Stefan
Samuel Hawksby-Robinson