mirror of https://github.com/status-im/specs.git
spellcheck (#119)
* spellcheck * updated * Create f.yml * Delete f.yml * fix * only on pr * fix * spellcheck * attempt * more * updates * fix * more * updates * updated * more * more words * even more * updates * fix * sort * more * updates * updated * sort * Update docs/stable/6-payloads.md Co-authored-by: Samuel Hawksby-Robinson <samuel@samyoul.com> Co-authored-by: Samuel Hawksby-Robinson <samuel@samyoul.com>
This commit is contained in:
Dean Eigenmann
GitHub
parent
d093781369
commit
55d210c30e
|
|
@ -0,0 +1,31 @@
|
|||
# This is a basic workflow to help you get started with Actions
|
||||
|
||||
name: CI
|
||||
|
||||
# Controls when the action will run. Triggers the workflow on push or pull request
|
||||
# events but only for the master branch
|
||||
on: [pull_request]
|
||||
|
||||
jobs:
|
||||
spellcheck:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
|
||||
- name: Spellcheck Action
|
||||
uses: rojopolis/spellcheck-github-actions@0.2.0
|
||||
|
||||
lint:
|
||||
runs-on: ubuntu-latest
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
|
||||
- name: Set up Node.js
|
||||
uses: actions/setup-node@master
|
||||
with:
|
||||
node-version: 13
|
||||
- name: Install
|
||||
run: npm install
|
||||
- name: Test
|
||||
run: npm run lint
|
||||
15
.travis.yml
15
.travis.yml
|
|
@ -1,15 +0,0 @@
|
|||
sudo: required
|
||||
|
||||
dist: trusty
|
||||
|
||||
language: node_js
|
||||
|
||||
node_js:
|
||||
- "8"
|
||||
|
||||
script:
|
||||
- npm run lint
|
||||
|
||||
notifications:
|
||||
email: false
|
||||
|
||||
|
|
@ -6,13 +6,15 @@ nav_exclude: true
|
|||
|
||||
# Specifications for Status clients
|
||||
|
||||
|
||||
|
||||
This repository contains a list of specifications for implementing Status and
|
||||
its various capabilities.
|
||||
|
||||
## How to contribute
|
||||
|
||||
1. Create an issue for a new Status Improvement Proposal (SIP) or some bug that you'd like to address
|
||||
2. Create a corresponding PR and ping some exisiting SIP editors for review
|
||||
2. Create a corresponding PR and ping some existing SIP editors for review
|
||||
|
||||
If you need help, ask in #protocol at Status / Discord.
|
||||
|
||||
|
|
|
|||
|
|
@ -14,8 +14,8 @@ title: 6/PAYLOADS
|
|||
|
||||
## Abstract
|
||||
|
||||
This specifications decribes how the payload of each message in Status looks
|
||||
like. It is primarly centered around chat and chat-related use cases.
|
||||
This specifications describes how the payload of each message in Status looks
|
||||
like. It is primarily centered around chat and chat-related use cases.
|
||||
|
||||
The payloads aims be flexible enough to support messaging but also cases
|
||||
described in the [Status Whitepaper](https://status.im/whitepaper.pdf) as well
|
||||
|
|
@ -224,7 +224,7 @@ Messages with a `clock` greater than `120` seconds over the whisper timestamp SH
|
|||
|
||||
Messages with a `clock` less than `120` seconds under the whisper timestamp might indicate an attempt to insert messages in the chat history which is not distinguishable from a `datasync` layer re-transit event. A client MAY mark this messages with a warning to the user, or discard them.
|
||||
|
||||
`clock` value is used for the message ordering. Due to the used algorithm and distributed nature of the system, we achieve casual ordering which might produce counterintuitive results in some edge cases. For example, when one joins a public chat and sends a message before receiving the exist messages, their message `clock` value might be lower and the message will end up in the past when the historical messages are fetched.
|
||||
`clock` value is used for the message ordering. Due to the used algorithm and distributed nature of the system, we achieve casual ordering which might produce counter-intuitive results in some edge cases. For example, when one joins a public chat and sends a message before receiving the exist messages, their message `clock` value might be lower and the message will end up in the past when the historical messages are fetched.
|
||||
|
||||
#### Chats
|
||||
|
||||
|
|
@ -316,7 +316,7 @@ message SyncInstallationPublicChat {
|
|||
|
||||
### PairInstallation
|
||||
|
||||
`PairInstallation` messages are used to propagate informations about a device to its paired devices.
|
||||
`PairInstallation` messages are used to propagate information about a device to its paired devices.
|
||||
|
||||
```protobuf
|
||||
message PairInstallation {
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ title: 9/3RD-PARTY-USAGE
|
|||
* [Collectibles](#collectibles)
|
||||
* [Iubenda](#iubenda)
|
||||
5. [Changelog](#changelog)
|
||||
6. [Acknowledgements](#acknowledgements)
|
||||
6. [Acknowledgments](#acknowledgments)
|
||||
7. [Copyright](#copyright)
|
||||
|
||||
## Abstract
|
||||
|
|
@ -100,7 +100,9 @@ There is a set of services that used for getting information about collectibles:
|
|||
Making http request means that a user leaks metadata, which can be used in various attacks if the service is hacked.
|
||||
|
||||
### Iubenda
|
||||
|
||||
##### What is it?
|
||||
|
||||
Service that helps in creating documents that make websites and apps compliant with the law across multiple countries and legislations.
|
||||
|
||||
##### How Status use it?
|
||||
|
|
@ -115,7 +117,7 @@ If Iubenda fails Status users won't be able to navigate to app's privacy policy.
|
|||
| :-----: | ------- |
|
||||
| [0.1.0](https://github.com/status-im/specs/blob/master/docs/draft/9-3rd-party.md) | Initial Release |
|
||||
|
||||
## Acknowledgements
|
||||
## Acknowledgments
|
||||
|
||||
## Copyright
|
||||
|
||||
|
|
|
|||
|
|
@ -42,11 +42,11 @@ The minimum sticker image resolution is 512x512, and its background SHOULD be tr
|
|||
### Distribution
|
||||
|
||||
Sticker packs are implemented as [ERC721 token](https://eips.ethereum.org/EIPS/eip-721) and contain a set of stickers. These stickers
|
||||
are stored inside the sticker pack as a set of hyperlinks pointing to IPFS storage. These hyperlinks are publically available and can be accessed by any user inside the status chat.
|
||||
are stored inside the sticker pack as a set of hyperlinks pointing to IPFS storage. These hyperlinks are publicly available and can be accessed by any user inside the status chat.
|
||||
Stickers can be sent in chat only by accounts that own the sticker pack.
|
||||
|
||||
### IPFS gateway
|
||||
At the moment of writing, the current main Status app uses the [Infura](https://infura.io/) gateway. However clients could choose a different gateway or to run own IPFS node.
|
||||
At the moment of writing, the current main Status app uses the [Infura](https://infura.io/) gateway. However, clients could choose a different gateway or to run own IPFS node.
|
||||
Infura gateway is an HTTPS gateway, which based on an HTTP GET request with the multihash block will return the stored content at that block address.
|
||||
|
||||
The use of gateway is required to enable easy access to the resources over HTTP.
|
||||
|
|
@ -56,7 +56,7 @@ derived from the hash of the file. This ensures that a file can't be overridden,
|
|||
### Security
|
||||
The IPFS gateway acts as an end-user of the IPFS and allows users of the gateway to access IPFS without connection to the P2P network.
|
||||
Usage of a gateway introduces potential risk for the users of that gateway provider. In case of a compromise in the security of the provider, meta information such as IP address, User-Agent and other of its users can be leaked.
|
||||
If the provider servers are unavailable the access trought gateway to the IPFS network is lost.
|
||||
If the provider servers are unavailable the access trough gateway to the IPFS network is lost.
|
||||
|
||||
### Status sticker usage
|
||||
When a sticker is shown in the app, Status app makes an http GET request to IPFS gateway using the hyperlink.
|
||||
|
|
@ -76,7 +76,7 @@ To submit a sticker pack, the author should upload all assets to IPFS. Then gene
|
|||
:stickers [{:hash "e301017012207737b75367b8068e5bdd027d7b71a25138c83e155d1f0c9bc5c48ff158724495"}
|
||||
{:hash "e301017012201a9cdea03f27cda1aede7315f79579e160c7b2b6a2eb51a66e47a96f47fe5284"}]}}
|
||||
```
|
||||
All assets fileds, are contenthash fileds as per [EIP 1577](https://eips.ethereum.org/EIPS/eip-1577).
|
||||
All assets fields, are contenthash fields as per [EIP 1577](https://eips.ethereum.org/EIPS/eip-1577).
|
||||
This payload is uploaded also to IPFS, and the IPFS address is used in the content field of the Sticker Market contract. See [Sticker Market spec](https://github.com/status-im/sticker-market/blob/651e88e5f38c690e57ecaad47f46b9641b8b1e27/docs/specification.md) for a detailed description of the contract.
|
||||
|
||||
#### Install a sticker pack
|
||||
|
|
@ -87,7 +87,7 @@ To install a sticker pack, we need to fetch all sticker packs which are availabl
|
|||
Call `packCount()` on the sticker market contract, will return number of sticker pack registered as `uint256`.
|
||||
|
||||
#### 2. Get sticker pack by id
|
||||
ID's are represented as `uint256` and are incremental from `0` to total number of sticker packs in contract, which we received on previous step. To get a sticker pack we should call `getPackData(sticker-pack-id)`, the return type is `["bytes4[]" "address" "bool" "uint256" "uint256" "bytes"]` which represents the following fields: `[category owner mintable timestamp price contenthash]`. Price is the SNT value in wei setted by sticker pack owner. The contenthash is the IPFS address described in the [submit description](#submit-a-sticker-pack) above. Other fields specification could be found in [Sticker Market spec](https://github.com/status-im/sticker-market/blob/651e88e5f38c690e57ecaad47f46b9641b8b1e27/docs/specification.md)
|
||||
ID's are represented as `uint256` and are incremental from `0` to total number of sticker packs in contract, which we received on previous step. To get a sticker pack we should call `getPackData(sticker-pack-id)`, the return type is `["bytes4[]" "address" "bool" "uint256" "uint256" "bytes"]` which represents the following fields: `[category owner mintable timestamp price contenthash]`. Price is the SNT value in wei set by sticker pack owner. The contenthash is the IPFS address described in the [submit description](#submit-a-sticker-pack) above. Other fields specification could be found in [Sticker Market spec](https://github.com/status-im/sticker-market/blob/651e88e5f38c690e57ecaad47f46b9641b8b1e27/docs/specification.md)
|
||||
|
||||
##### 3. Get owned sticker packs
|
||||
The current Status app fetches owned sticker packs during the open of any sticker view (a screen which shows a sticker pack or the list of sticker packs).
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
layout: default
|
||||
title: Raw specs
|
||||
permanlink: /specs/raw
|
||||
permalink: /specs/raw
|
||||
nav_order: 2
|
||||
has_children: true
|
||||
---
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ have to be implemented in order to be a full Status client. The second gives a d
|
|||
- [Privacy](#privacy)
|
||||
- [Spam resistance](#spam-resistance)
|
||||
- [Censorship resistance](#censorship-resistance)
|
||||
- [Acknowledgements](#acknowledgements)
|
||||
- [Acknowledgments](#acknowledgments)
|
||||
|
||||
### Protocol layers
|
||||
|
||||
|
|
@ -120,7 +120,7 @@ nodes allow you to discover other nodes of the network.
|
|||
Currently the main bootstrap nodes are provided by Status Gmbh, but anyone can
|
||||
run these provided they are connected to the rest of the Whisper network.
|
||||
|
||||
Status maintains a list of production fleet boootstrap nodes in the following locations:
|
||||
Status maintains a list of production fleet bootstrap nodes in the following locations:
|
||||
|
||||
**Hong Kong:**
|
||||
|
||||
|
|
@ -200,11 +200,11 @@ communicate with other Status nodes.
|
|||
### Transport privacy and Whisper usage
|
||||
|
||||
Once a Whisper node is up and running there are some specific settings required
|
||||
to commmunicate with other Status nodes.
|
||||
to communicate with other Status nodes.
|
||||
|
||||
See [3/WHISPER-USAGE](https://specs.status.im/spec/3) for more details.
|
||||
|
||||
For providing offline inboxing, see the complementary [4/WHISPER-MAILSERVER](https://specs.status.im/spec/4).
|
||||
For providing an offline inbox, see the complementary [4/WHISPER-MAILSERVER](https://specs.status.im/spec/4).
|
||||
|
||||
### Secure Transport
|
||||
|
||||
|
|
@ -275,7 +275,7 @@ Whisper is not currently under active development, and it has several drawbacks.
|
|||
Among others:
|
||||
|
||||
- It is very wasteful bandwidth-wise and it doesn't appear to be scalable
|
||||
- Proof of work is a poor spam protection mechanism for heterogenerous devices
|
||||
- Proof of work is a poor spam protection mechanism for heterogeneous devices
|
||||
- The privacy guarantees provided are not rigorous
|
||||
- There's no incentives to run a node
|
||||
|
||||
|
|
@ -353,7 +353,7 @@ The main privacy concern with light nodes is that directly connected peers will
|
|||
|
||||
**Bloom filter privacy:**
|
||||
|
||||
By having a bloom filter where only the topics you are interested in are set, you reveal which messages you are interested in. This is a fundamental tradeoff between bandwidth usage and privacy, though the tradeoff space is likely suboptimal in terms of the [Anonymity](https://eprint.iacr.org/2017/954.pdf) [trilemma](https://petsymposium.org/2019/files/hotpets/slides/coordination-helps-anonymity-slides.pdf).
|
||||
By having a bloom filter where only the topics you are interested in are set, you reveal which messages you are interested in. This is a fundamental trade-off between bandwidth usage and privacy, though the trade-off space is likely suboptimal in terms of the [Anonymity](https://eprint.iacr.org/2017/954.pdf) [trilemma](https://petsymposium.org/2019/files/hotpets/slides/coordination-helps-anonymity-slides.pdf).
|
||||
|
||||
**Mailserver client privacy:**
|
||||
|
||||
|
|
@ -369,7 +369,7 @@ Similar to bloom filter privacy, if you use a very specific topic you reveal mor
|
|||
|
||||
### Spam resistance
|
||||
|
||||
**PoW bad for heterogenerous devices:**
|
||||
**PoW bad for heterogeneous devices:**
|
||||
|
||||
Proof of work is a poor spam prevention mechanism. A mobile device can only have a very low PoW in order not to use too much CPU / burn up its phone battery. This means someone can spin up a powerful node and overwhelm the network.
|
||||
|
||||
|
|
@ -385,6 +385,6 @@ By default Devp2p runs on port `30303`, which is not commonly used for any other
|
|||
|
||||
See <https://github.com/status-im/status-react/issues/6351> for some discussion.
|
||||
|
||||
## Acknowledgements
|
||||
## Acknowledgments
|
||||
|
||||
Jacek Sieka
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ Everything else associated with the contact is either verified or derived from t
|
|||
- A client SHOULD regenerate a new X3DH prekey bundle every 24 hours. This MAY be done in a lazy way, such that a client that does not come online past this time period does not regenerate or broadcast bundles.
|
||||
- The current bundle SHOULD be broadcast on a whisper topic specific to his Identity Key, `{IK}-contact-code`, intermittently. This MAY be done every 6 hours.
|
||||
- A bundle SHOULD accompany every message sent.
|
||||
- TODO: retreival of long-time offline users bundle via `{IK}-contact-code`
|
||||
- TODO: retrieval of long-time offline users bundle via `{IK}-contact-code`
|
||||
|
||||
## Optional Account additions
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ Everything else associated with the contact is either verified or derived from t
|
|||
- A user MAY register a public username on the Ethereum Name System (ENS). This username is a user-chosen subdomain of the `stateofus.eth` ENS registration that maps to their whisper identity key (`IK`).
|
||||
|
||||
<!-- ### User Profile Picture
|
||||
- An account MAY edit the `IK` generated identicon with a chosen picture. This picture will become part of the publicly broadcasted profile of the account. -->
|
||||
- An account MAY edit the `IK` generated identicon with a chosen picture. This picture will become part of the publicly broadcast profile of the account. -->
|
||||
|
||||
<!-- TODO: Elaborate on wallet account and multiaccount -->
|
||||
<!-- TODO: Elaborate on security implications -->
|
||||
|
|
@ -117,7 +117,7 @@ Everything else associated with the contact is either verified or derived from t
|
|||
### Contact Discovery
|
||||
|
||||
#### Public channels
|
||||
- Public group channels in Status are a broadcast/subscription system. All public messages are encrypted with a symmetric key drived from the channel name, `K_{pub,sym}`, which is publicly known.
|
||||
- Public group channels in Status are a broadcast/subscription system. All public messages are encrypted with a symmetric key derived from the channel name, `K_{pub,sym}`, which is publicly known.
|
||||
- A public group channel's symmetric key MUST creation must follow the [web3 API](https://web3js.readthedocs.io/en/1.0/web3-shh.html#generatesymkeyfrompassword)'s `web3.ssh.generateSymKeyFromPassword` function
|
||||
- In order to post to a public group channel, a client MUST have a valid account created.
|
||||
- In order to listen to a public group channel, a client must subscribe to the channel name. The sender of a message is derived from the message's signature.
|
||||
|
|
@ -131,7 +131,7 @@ Everything else associated with the contact is either verified or derived from t
|
|||
This can be done in the following ways:
|
||||
1. scanning a user generated QR code
|
||||
1. discovery through the Status app
|
||||
1. asyncronous X3DH key exchange
|
||||
1. asynchronous X3DH key exchange
|
||||
1. public key via public channel listening
|
||||
- `status-react/src/status_im/contact_code/core.cljs`
|
||||
1. contact codes
|
||||
|
|
@ -160,7 +160,7 @@ This can be done in the following ways:
|
|||
Once you have the information of a contact, the following can be used to verify that the key material is as it should be.
|
||||
|
||||
#### Identicon
|
||||
A low-poly identicon is deterministically generated from the whisper chat public key. This can then be compared out of band to ensure the reciever's public key is the one you have locally.
|
||||
A low-poly identicon is deterministically generated from the whisper chat public key. This can then be compared out of band to ensure the receiver's public key is the one you have locally.
|
||||
|
||||
#### 3 word pseudonym / whisper key fingerprint
|
||||
Status generates a deterministic 3-word random pseudonym from the whisper chat public key. This pseudonym acts as a human readable fingerprint to the whisper chat public key. This name also shows when viewing a contact's public profile and in the chat UI.
|
||||
|
|
@ -187,12 +187,12 @@ possible connections
|
|||
- a mailserver identifies itself by an [enode address](https://github.com/ethereum/wiki/wiki/enode-url-format)
|
||||
- client - whisper node (statusd)
|
||||
- a node identifies itself by an enode address
|
||||
- client - bootnode (geth)
|
||||
- client - bootnode (go-ethereum)
|
||||
- a bootnode identifies itself by
|
||||
- an enode address
|
||||
- `NOTE: redezvous information here`
|
||||
- client - ENS registry (ethereum blockchain -> default to infura)
|
||||
- client - Ethereum RPC (custom geth RPC API -> default to infura API)
|
||||
- client - Ethereum RPC (custom go-ethereum RPC API -> default to infura API)
|
||||
- client - IPFS (Status hosted IPFS gateway -> defaults to ???)
|
||||
- we have a status hosted IPFS gateway for pinning but it currently isn't used much.
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ encryption properties to support asynchronous chat.
|
|||
|
||||
## Terminology
|
||||
|
||||
* *Whisper node*: an Ethereum node with Whisper V6 enabled (in the case of geth, it's `--shh` option)
|
||||
* *Whisper node*: an Ethereum node with Whisper V6 enabled (in the case of go-ethereum, it's `--shh` option)
|
||||
* *Whisper network*: a group of Whisper nodes connected together through the internet connection and forming a graph
|
||||
* *Message*: decrypted Whisper message
|
||||
* *Offline message*: an archived envelope
|
||||
|
|
@ -309,9 +309,9 @@ The Message Response packet is more complex and is followed by a Versioned Messa
|
|||
The supported codes:
|
||||
`1`: means time sync error which happens when an envelope is too old or created in the future (the root cause is no time sync between nodes).
|
||||
|
||||
The drawback of sending message confirmations is that it increases the noise in the network because for each sent message, a corresponding confirmation is broadcasted by one or more peers. To limit that, both Batch Acknowledge packet (`0x0b`) and Message Response packet (`0x0c`) are not broadcasted to peers of the peers, i.e. they do not follow epidemic spread.
|
||||
The drawback of sending message confirmations is that it increases the noise in the network because for each sent message, a corresponding confirmation is broadcast by one or more peers. To limit that, both Batch Acknowledge packet (`0x0b`) and Message Response packet (`0x0c`) are not broadcast to peers of the peers, i.e. they do not follow epidemic spread.
|
||||
|
||||
In the current Status network setup, only Mailservers support message confirmations. A client posting a message to the network and after receiving a confirmation can be sure that the message got processed by the Mailserver. If additionally, sending a message is limited to non-Mailserver peers, it also guarantees that the message got broadcasted through the network and it reached the selected Mailserver.
|
||||
In the current Status network setup, only Mailservers support message confirmations. A client posting a message to the network and after receiving a confirmation can be sure that the message got processed by the Mailserver. If additionally, sending a message is limited to non-Mailserver peers, it also guarantees that the message got broadcast through the network and it reached the selected Mailserver.
|
||||
|
||||
## Whisper V6 extensions
|
||||
|
||||
|
|
|
|||
|
|
@ -14,10 +14,10 @@ title: 6/PAYLOADS
|
|||
|
||||
## Abstract
|
||||
|
||||
This specifications decribes how the payload of each message in Status looks
|
||||
like. It is primarly centered around chat and chat-related use cases.
|
||||
This specifications describes how the payload of each message in Status looks
|
||||
like. It is primarily centered around chat and chat-related use cases.
|
||||
|
||||
The payloads aims be flexible enough to support messaging but also cases
|
||||
The payloads aim to be flexible enough to support messaging but also cases
|
||||
described in the [Status Whitepaper](https://status.im/whitepaper.pdf) as well
|
||||
as various clients created using different technologies.
|
||||
|
||||
|
|
@ -204,7 +204,7 @@ Messages with a `clock` greater than `120` seconds over the whisper timestamp SH
|
|||
|
||||
Messages with a `clock` less than `120` seconds under the whisper timestamp might indicate an attempt to insert messages in the chat history which is not distinguishable from a `datasync` layer re-transit event. A client MAY mark this messages with a warning to the user, or discard them.
|
||||
|
||||
`clock` value is used for the message ordering. Due to the used algorithm and distributed nature of the system, we achieve casual ordering which might produce counterintuitive results in some edge cases. For example, when one joins a public chat and sends a message before receiving the exist messages, their message `clock` value might be lower and the message will end up in the past when the historical messages are fetched.
|
||||
`clock` value is used for the message ordering. Due to the used algorithm and distributed nature of the system, we achieve casual ordering which might produce counter-intuitive results in some edge cases. For example, when one joins a public chat and sends a message before receiving the exist messages, their message `clock` value might be lower and the message will end up in the past when the historical messages are fetched.
|
||||
|
||||
#### Chats
|
||||
|
||||
|
|
@ -296,7 +296,7 @@ message SyncInstallationPublicChat {
|
|||
|
||||
### PairInstallation
|
||||
|
||||
`PairInstallation` messages are used to propagate informations about a device to its paired devices.
|
||||
`PairInstallation` messages are used to propagate information about a device to its paired devices.
|
||||
|
||||
```protobuf
|
||||
message PairInstallation {
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ In this specification, we describe how Status relates with EIPs.
|
|||
- [Security Considerations](#security-considerations)
|
||||
- [Design Rationale](#design-rationale)
|
||||
- [Footnotes](#footnotes)
|
||||
- [Acknowledgements](#acknowledgements)
|
||||
- [Acknowledgments](#acknowledgments)
|
||||
|
||||
## Introduction
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ Observation: BIP44 don't solve privacy issues regarding the transparency of tran
|
|||
|
||||
Support: Full.
|
||||
Reference: https://eips.ethereum.org/EIPS/eip-20
|
||||
Description: Enable wallets to use tokens based on smart contracts compilant with this standard.
|
||||
Description: Enable wallets to use tokens based on smart contracts compliant with this standard.
|
||||
Used for: Wallet feature.
|
||||
Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/tokens.cljs
|
||||
|
||||
|
|
@ -152,7 +152,7 @@ Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im
|
|||
|
||||
Support: Full.
|
||||
Reference: https://eips.ethereum.org/EIPS/eip-191
|
||||
Description: Contract signature standard, adds an obrigatory padding to signed message to differentiate from Ethereum Transaction messages.
|
||||
Description: Contract signature standard, adds an obligatory padding to signed message to differentiate from Ethereum Transaction messages.
|
||||
Used for: Dapp support, security, dependency of ERC712.
|
||||
|
||||
### EIP627 - Whisper Specification
|
||||
|
|
@ -167,7 +167,7 @@ Used for: Chat protocol.
|
|||
Support: Partial.
|
||||
Reference: https://eips.ethereum.org/EIPS/eip-681
|
||||
Description: A link that pop up a transaction in the wallet.
|
||||
Used for: Useful as QRCode data for tranasction requests, chat transaction requests and for dapp links to transaction requests.
|
||||
Used for: Useful as QR code data for transaction requests, chat transaction requests and for dapp links to transaction requests.
|
||||
Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/eip681.cljs
|
||||
Related: [Issue #9183: URL Format for Transaction Requests (EIP681) is poorly supported](https://github.com/status-im/status-react/issues/9183) https://github.com/status-im/status-react/pull/9240 https://github.com/status-im/status-react/issues/9238 https://github.com/status-im/status-react/issues/7214 https://github.com/status-im/status-react/issues/7325 https://github.com/status-im/status-react/issues/8150
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ Related: [Issue #9183: URL Format for Transaction Requests (EIP681) is poorly su
|
|||
|
||||
Support: Partial.
|
||||
Reference: https://eips.ethereum.org/EIPS/eip-712
|
||||
Description: Standarize types for contract siganture, allowing users to easily inspect whats being signed.
|
||||
Description: Standardize types for contract signature, allowing users to easily inspect whats being signed.
|
||||
Used for: User experience, security.
|
||||
Related: https://github.com/status-im/status-react/issues/5461 https://github.com/status-im/status-react/commit/ba37f7b8d029d3358c7b284f6a2383b9ef9526c9
|
||||
|
||||
|
|
@ -183,7 +183,7 @@ Related: https://github.com/status-im/status-react/issues/5461 https://github.co
|
|||
|
||||
Support: Partial.
|
||||
Reference: https://eips.ethereum.org/EIPS/eip-721
|
||||
Description: Enable wallets to use tokens based on smart contracts compilant with this standard.
|
||||
Description: Enable wallets to use tokens based on smart contracts compliant with this standard.
|
||||
Used for: Wallet feature.
|
||||
Related: https://github.com/status-im/status-react/issues/8909
|
||||
Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/erc721.cljs https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/tokens.cljs
|
||||
|
|
@ -225,7 +225,7 @@ Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im
|
|||
Support: Partial.
|
||||
Reference: https://eips.ethereum.org/EIPS/eip-1581
|
||||
Description: Allow wallet to derive keys that are less sensible (non wallet).
|
||||
Used for: Security (dont reuse wallet key) and user experience (dont request keycard every login).
|
||||
Used for: Security (don't reuse wallet key) and user experience (don't request keycard every login).
|
||||
Related: https://github.com/status-im/status-react/issues/9088 https://github.com/status-im/status-react/pull/9096
|
||||
Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/constants.cljs#L242
|
||||
|
||||
|
|
@ -244,4 +244,4 @@ Sourcecode: -
|
|||
|
||||
## Footnotes
|
||||
|
||||
## Acknowledgements
|
||||
## Acknowledgments
|
||||
|
|
|
|||
|
|
@ -213,7 +213,7 @@ Usernames MUST be in a specific format, otherwise they MAY be slashed:
|
|||
- They MUST only contain alphanumeric characters
|
||||
- They MUST NOT be in the form `0x[0-9a-f]{5}.*` and have more than 12 characters
|
||||
- They MUST NOT be in the [reserved list] (https://github.com/status-im/ens-usernames/blob/47c4c6c2058be0d80b7d678e611e166659414a3b/config/ens-usernames/reservedNames.js)
|
||||
- They MUST NOT be too short, this is dinamically set in the contract and can be checked against the [contract](https://github.com/status-im/ens-usernames/blob/master/contracts/registry/UsernameRegistrar.sol#L26)
|
||||
- They MUST NOT be too short, this is dynamically set in the contract and can be checked against the [contract](https://github.com/status-im/ens-usernames/blob/master/contracts/registry/UsernameRegistrar.sol#L26)
|
||||
|
||||
- [Slash a reserved username](https://github.com/status-im/ens-usernames/blob/77d9394d21a5b6213902473b7a16d62a41d9cd09/contracts/registry/UsernameRegistrar.sol#L237)
|
||||
- [Slash an invalid username] (https://github.com/status-im/ens-usernames/blob/77d9394d21a5b6213902473b7a16d62a41d9cd09/contracts/registry/UsernameRegistrar.sol#L261)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
matrix:
|
||||
- name: Markdown
|
||||
apsell:
|
||||
mode: en
|
||||
ignore-case: true
|
||||
dictionary:
|
||||
wordlists:
|
||||
- wordlist.txt
|
||||
output: wordlist.dic
|
||||
encoding: utf-8
|
||||
pipeline:
|
||||
- pyspelling.filters.url:
|
||||
- pyspelling.filters.markdown:
|
||||
- pyspelling.filters.html:
|
||||
comments: false
|
||||
ignores:
|
||||
- code
|
||||
- pre
|
||||
sources:
|
||||
- '**/*.md'
|
||||
|
|
@ -0,0 +1,210 @@
|
|||
Ack
|
||||
activePublicKey
|
||||
AES
|
||||
apis
|
||||
APIs
|
||||
Babik
|
||||
backend
|
||||
BIP
|
||||
BIPs
|
||||
blockable
|
||||
BlockByHash
|
||||
BlockByNumber
|
||||
blockchain
|
||||
BundleContainer
|
||||
chainId
|
||||
Changelog
|
||||
chatid
|
||||
chatId
|
||||
chatID
|
||||
ChatMessage
|
||||
contactCode
|
||||
contactcode
|
||||
contenthash
|
||||
ContentType
|
||||
COSS
|
||||
crypto
|
||||
CryptoCompare
|
||||
cryptocurrencies
|
||||
cryptocurrency
|
||||
cryptographic
|
||||
cryptographically
|
||||
customizable
|
||||
DApp
|
||||
dapp
|
||||
dapps
|
||||
DDoS
|
||||
decrypt
|
||||
decrypted
|
||||
decrypting
|
||||
deserialized
|
||||
deterministically
|
||||
devP
|
||||
devp
|
||||
devP2P
|
||||
dh
|
||||
DHT
|
||||
diffie
|
||||
Diffie
|
||||
discoverable
|
||||
DNS
|
||||
DoS
|
||||
ECDSA
|
||||
ECIES
|
||||
ecies
|
||||
ECR
|
||||
EDN
|
||||
EE
|
||||
Eigenmann
|
||||
EIP
|
||||
EIPs
|
||||
EncodeToString
|
||||
enode
|
||||
enr
|
||||
enum
|
||||
ERC
|
||||
EstimateGas
|
||||
ETH
|
||||
ethereum
|
||||
Etherscan
|
||||
EventType
|
||||
FilterLogs
|
||||
FormatInt
|
||||
GCM
|
||||
GenerateShared
|
||||
gfycat
|
||||
Gheorghe
|
||||
Gmbh
|
||||
golang
|
||||
Guilherme
|
||||
HD
|
||||
HeaderByNumber
|
||||
hellman
|
||||
Helman
|
||||
hexEncode
|
||||
hexEncodedKey
|
||||
HMAC
|
||||
http
|
||||
HTTPS
|
||||
identicon
|
||||
IK
|
||||
im
|
||||
ImageMessage
|
||||
ImportECDSA
|
||||
ImportECDSAPublic
|
||||
infura
|
||||
IPFS
|
||||
IPs
|
||||
Iubenda
|
||||
Jacek
|
||||
JSON
|
||||
kademlia
|
||||
kb
|
||||
keccak
|
||||
Keccak
|
||||
KECCAK
|
||||
keycard
|
||||
keypair
|
||||
keypairs
|
||||
Kozieiev
|
||||
Lamport
|
||||
legislations
|
||||
len
|
||||
libp
|
||||
lifecycle
|
||||
mailserver
|
||||
Mailserver's
|
||||
mailservers
|
||||
Mailservers
|
||||
mainnet
|
||||
MembershipUpdateEvent
|
||||
MembershipUpdateMessage
|
||||
merkle
|
||||
MessageType
|
||||
mixnets
|
||||
multiaccount
|
||||
multicasting
|
||||
multihash
|
||||
MVDS
|
||||
myPrivateKey
|
||||
nav
|
||||
NewInt
|
||||
NonceAt
|
||||
oneof
|
||||
Oskar
|
||||
PairInstallation
|
||||
partitionsNum
|
||||
partitionTopic
|
||||
peerID
|
||||
PendingNonceAt
|
||||
performant
|
||||
permalink
|
||||
permissionless
|
||||
PFS
|
||||
Piana
|
||||
Pinzaru
|
||||
plaintext
|
||||
Pluggable
|
||||
Pombeiro
|
||||
PoW
|
||||
pre
|
||||
prekey
|
||||
prekeys
|
||||
prepending
|
||||
privkey
|
||||
protobuf
|
||||
ProtocolMessage
|
||||
PSS
|
||||
pubkey
|
||||
publicKey
|
||||
relayers
|
||||
requestMessages
|
||||
RLP
|
||||
RLPx
|
||||
RPC
|
||||
scalability
|
||||
scalable
|
||||
secp
|
||||
SendTransaction
|
||||
SHA
|
||||
sharedKey
|
||||
shhext
|
||||
Sieka
|
||||
SIP
|
||||
SIPs
|
||||
SNT
|
||||
Sourcecode
|
||||
SPK
|
||||
StickerMessage
|
||||
stickerpack
|
||||
strconv
|
||||
suboptimal
|
||||
subprotocol
|
||||
subprotocols
|
||||
SuggestGasPrice
|
||||
SyncInstallationContact
|
||||
SyncInstallationPublicChat
|
||||
TCP
|
||||
theirPublicKey
|
||||
Thorén
|
||||
TODO
|
||||
topicLen
|
||||
TransactionByHash
|
||||
TransactionReceipt
|
||||
trilemma
|
||||
TXT
|
||||
UI
|
||||
uint
|
||||
underspecified
|
||||
unencrypted
|
||||
unix
|
||||
Upgradability
|
||||
URI
|
||||
URIs
|
||||
uuid
|
||||
UX
|
||||
Volodymyr
|
||||
Vp
|
||||
Waku
|
||||
wei
|
||||
Whitepaper
|
||||
Loading…
Reference in New Issue