* Version bump
* Implemented lan connection string functionality
Also added more robust testing
* Added ConnectionParams struct and related funcs
* Add server mode to ConnectionParams
* Added function to get preffered network IP
Also done some refactor work oon server package to make a lot more reusable
* Added server.Option and simplified handler funcs
* Added serial number deterministically generated from pk
* Debugging TLS server connection
* Implemented configurable server ip
When accessing over the network the server needs to listen on the network port and not localhost or 127.0.0.1 . Also the cert can now have a dedicated IP
* Refactor of URL funcs to use the url package
* Removed redundant Options pattern in favour of config param
* Added full server test using GetOutboundIP
* Remove references and usage of Server.port
The application does not need to set the port, we rely on the net.Listener to pick a port.
* Version bump
* Added ToECDSA func and improved cert testing
* Added error check in test
* Split Server types, embedding raw Server funcs into specialised server types
* localhost
* Implemented DNS and IP based cert gen
ios doesn't allow for restricted ip addresses to be used in a valid tls cert
* Replace listener handling with original port store
Also added handlers as a parameter of the Server
Add banner image as a special `IdentityImage` beside "thumbnail" and "large"
Banner input cropped image processing
- Resize to keep in the limits of `BannerDim`
- Encode to match the file size limits define for banner
- Don't scale up. This can be done efficiently in the UI
Changes to `images` module
- Refactor `EncodeToBestSize` as `EncodeToLimits` to accept arbitrary dimensions
and allow for custom size
- Define `DimensionLimits` for banner not to exceed 450 KB and a rough estimate
for the ideal size
Added functionality to find target address when 6th param in path is added
for ex: "m'/44'/60'/0'/0/500" reperents the Address at the 500th index
Added a api to get the Address derived from a private key
This allows to store community admin settings that are meant to be propagated
to community members (as opposed to the already existing
`CommunitySettings` which are considered local to every account).
The first setting introduced as part of this commit is one that enables
community admins to configure whether or not members of the community
are allowed to pin messages in community channels.
Prior to this commit, this was not restricted at all on the protocol
level and only enforced by clients via UI (e.g. members don't see an
option to pin messages, although they could).
This config setting now ensures that:
1. If turned off, members cannot send a pin message
2. If turned off, pin messages from members are not handled/processed
This is needed by https://github.com/status-im/status-desktop/issues/5662
* Add user-facing explainer
Added a user-facing explainer at the top of the doc as we link to this file from the UI.
Moved all content that was already in the doc to below the divider with the heading 'How it works'
* Update _docs/app-metrics.md
Co-authored-by: Samuel Hawksby-Robinson <samuel@samyoul.com>
* Update _docs/app-metrics.md
Co-authored-by: Samuel Hawksby-Robinson <samuel@samyoul.com>
* Update _docs/app-metrics.md
Co-authored-by: Samuel Hawksby-Robinson <samuel@samyoul.com>
* More text edits based on comments
Session key > Batch ID
Regular Chat key > Chat key
* Remove spaces
* Update app-metrics.md
- Remove 'anonymous' claim
- Correct that we believe the data cannot be linked back to you
* Add criteria to include data in validator rules
* Update app-metrics.md
* Replace anonymous from intro
Removing anonymous reference as discussed on Discord. 'Anonymous' is a claim we logically can't make in spite of best effort and current insights; we are not delivering proof. In addition there is the threat model of a phone ending in the wrong hands with the collected data, albeit temporarily stored locally, falling in the wrong hands.
We do want to communicate that the approach is "as privacy preserving as we could possibly make it without it being useless"
anonymous > privacy-preserving
over Waku > over Status' peer-to-peer network (Waku)
* Update app-metrics.md
- Add warning at top
- Update text at the bottom of 'what will never be shared'
- Remove 'Time since last data message sent'
- Changed 'Time since last session' to 'Time since last batch sent' @shivekkhurana can you confirm this is accurate?
* Update app-metrics.md
Replace instance of 'anonymous' in `How it works` with 'end-to-end encrypted'
* Update app-metrics.md
Added: "Status will never use these data for profit."
* Edit to Transmission and deletion
Added that data is deleted locally if not transmitted after 7 days
@Samyoul can you take a look to see if there are more details to add to this section?
* Update app-metrics.md
Remove privacy-preserving as claim in intro and end-to-end encryption to reduce perception of privacy
* Added info banner
Added info note to explicitly state that usage data service is not included in release or nightly builds
* Added links to related PRs
These PRs include a lot of additional information that will be useful for a future dev, also probably me too.
Co-authored-by: Samuel Hawksby-Robinson <samuel@samyoul.com>
Otherwise Go version upgrades are a pain due to randomly hitting a host
with newer version of Go compiler.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This introduces the ability for status notes to handle community
history archive magnetlinks. To make this work, a few things are needed:
1. A new database table has been introduced to store message archive
hashes. This is necessary so status nodes can determine whether or
not they need to download a certain archive
2. The messenger's `handleRetrievedMessages()` has been exteded to take
magnetlink messages into account
3. New APIs were added to download torrent data given a magnetlink and
also to extract messages from downloaded archives, which are then
later fed to `handleRetrievedMessages`
Closes#2568
Prior to this commit, this API returns the in memory `NodeConfig` which
might not be the latest state.
This is the case when for example clients update any `NodeConfig` and
retrieve it right afterwards via `GetNodeConfig`.
To get the latest state of `NodeConfig` it has to be fetched from DB
instead.