- favourite column removed from the saved_addresses table
- favourite property removed from the SavedAddress struct
- ens name removed from the primary key, the primary key now is composed of address and is_test columns
- ens parameter removed from wakuext_deleteSavedAddress
- wallet_getSavedAddresses moved to wakuext_getSavedAddresses (to keep them all in a single place)
- saved addresses related endpoints removed from the wallet service, even they logically belong there, a reason for that
is avoiding emitting sync message if one uses calls from the wallet service, while that's not the case in ext service. Once
we refactor this and introduce devices syncing mechanism in the wallet service, we should not only these but other wallet
related endpoints move there (removed: wallet_getSavedAddresses, wallet_addSavedAddress and wallet_deleteSavedAddress).
Affected area:
Saved addresses
* feat: Add profile showcase messaging part with ecrypted data
* feat: Separate profile showcase categories to provide ablity to store custom data
* fix: review fixes
* feat: move profile showcase out of contact data
* fix: create index on contact id for profile tables
* chore: remove logger from link preview
This commit fixes 3 issues:
1) In some cases, the hash ratchet was not correctly found
2) Out of order messages were not processed correctly as the wrong error
was returned
3) Batched non datasync messages were not processed correctly
Fixes: #4170
This commit changes the format of the encryption id to be based off 3
things:
1) The group id
2) The timestamp
3) The actual key
Previously this was solely based on the timestamp and the group id, but
this might lead to conflicts. Moreover the format of the key was an
uint32 and so it would wrap periodically.
The migration is a bit tricky, so first we cleared the cache of keys,
that's easier than migrating, and second we set the new field hash_id to
the concatenation of group_id / key_id.
This might lead on some duplication in case keys are re-received, but it
should not have an impact on the correctness of the code.
I have added 2 tests covering compatibility between old/new clients, as
this should not be a breaking change.
It also adds a new message to rekey in a single go, instead of having to
send multiple messages
- use protected topics for communities
- associate chats to pubsub topics and populate these depending if the chat belongs to a community or not
- mailserver functions should be aware of pubsub topics
- generate private key for pubsub topic protection when creating a community
- add shard cluster and index to communities
- setup shards for existing communities
- distribute pubsubtopic password
- fix: do not send the requests to join and cancel in the protected topic
- fix: undefined shard values for backward compatibility
- refactor: use shard message in protobuffers
- share requests to join with new privileged roles during reevaluating member role
- share requests to join with new members, joined the community as TOKEN_MASTER, ADMIN
- share requests to join revealed addresses to ADMINS and TOKEN_MASTERS
- refactor common test functionality to make them more predictable
- removed unused CommunityToken protobuf
* sync preferred name;
remove settings.usernames
* update account name when handle settings.preferred_name from backup message
* fix Error:Field validation for 'KeycardPairingDataFile' failed on the 'required' tag
* bump version
* rebase
This commit adds support for unfurling static image URLs (not GIFs, not animated WebPs), such as https://placehold.co/600x400@2x.png. It also compresses images before returning them as data URIs to clients.
About compression: the compression strategy leverages the existing function images.CompressToFileLimits. A more comprehensive logic to consider the possibility of multiple image URLs being unfurled simultaneously is yet to be implemented.
Closes#3761
* rm params
* use url data proto
* feat: community channel and user data parsing; improve testing for urls
---------
Co-authored-by: MishkaRogachev <mishkarogachev@gmail.com>
Prior to this commit a control node would add the revealed addresses to
the member struct on the community description, which exposes all those
addresses to the public.
We don't want that. Revealed addresses are exclusively shared with
control nodes and should stay there (although, they might be privately
shared among token masters, see
https://github.com/status-im/status-desktop/issues/11610).
In this commit, we no longer add the revealed addresses to the community
description. The addresses are already stored in the requestToJoin
database table so we can take them from there if we need them.
Closes: https://github.com/status-im/status-desktop/issues/11573
Sale Djenic
Ibrahem Khalil
Godfrain Jacques
Cuteivist
Patryk Osmaczko
Mikhail Rogachev
Mykhailo Prakhov
Vitaly Vlasov
Igor Sirotin
frank
Mykhailo Prakhov
Andrea Maria Piana
Jonathan Rainville
Khushboo-dev-cpp
richΛrd
Icaro Motta
Felicio Mununga
Pascal Precht
Anthony Laibe
