From ac02ced4ede49e1d8823da0af458d2e4d5b3f716 Mon Sep 17 00:00:00 2001 From: status-im-auto Date: Sun, 17 Jul 2022 14:26:47 +0000 Subject: [PATCH] Updates --- assets/js/search-data.json | 10 +++++----- draft/14.html | 2 +- draft/3.html | 2 +- sitemap.xml | 2 +- spec/1.html | 2 +- spec/2.html | 6 +++--- spec/8.html | 2 +- spec/9.html | 2 +- 8 files changed, 14 insertions(+), 14 deletions(-) diff --git a/assets/js/search-data.json b/assets/js/search-data.json index 4743fff..652ccfa 100644 --- a/assets/js/search-data.json +++ b/assets/js/search-data.json @@ -43,13 +43,13 @@ },"7": { "doc": "1/CLIENT", "title": "Footnotes", - "content": ". | https://github.com/status-im/status-protocol-go/ | https://github.com/status-im/status-console-client/ | https://github.com/status-im/status-react/ | . ", + "content": ". | https://github.com/status-im/status-protocol-go/ | https://github.com/status-im/status-console-client/ | https://github.com/status-im/status-mobile/ | . ", "url": "https://specs.status.im/spec/1#footnotes", "relUrl": "/spec/1#footnotes" },"8": { "doc": "1/CLIENT", "title": "Appendix A: Security considerations", - "content": "There are several security considerations to take into account when running Status. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used, such as Mailserver, light node, and so on. Scalability and UX . Bandwidth usage: . In version 1 of Status, bandwidth usage is likely to be an issue. In Status version 1.1 this is partially addressed with Waku usage, see the theoretical scaling model. Mailserver High Availability requirement: . A Mailserver has to be online to receive messages for other nodes, this puts a high availability requirement on it. Gossip-based routing: . Use of gossip-based routing doesn’t necessarily scale. It means each node can see a message multiple times, and having too many light nodes can cause propagation probability that is too low. See Whisper vs PSS for more and a possible Kademlia based alternative. Lack of incentives: . Status currently lacks incentives to run nodes, which means node operators are more likely to create centralized choke points. Privacy . Light node privacy: . The main privacy concern with light nodes is that directly connected peers will know that a message originates from them (as it are the only ones it sends). This means nodes can make assumptions about what messages (topics) their peers are interested in. Bloom filter privacy: . A user reveals which messages they are interested in, by setting only the topics they are interested in on the bloom filter. This is a fundamental trade-off between bandwidth usage and privacy, though the trade-off space is likely suboptimal in terms of the Anonymity trilemma. Mailserver client privacy: . A Mailserver client has to trust a Mailserver, which means they can send direct traffic. This reveals what topics / bloom filter a node is interested in, along with its peerID (with IP). Privacy guarantees not rigorous: . Privacy for Whisper or Waku hasn’t been studied rigorously for various threat models like global passive adversary, local active attacker, etc. This is unlike e.g. Tor and mixnets. Topic hygiene: . Similar to bloom filter privacy, using a very specific topic reveals more information. See scalability model linked above. Spam resistance . 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. Mailserver trusted connection: . A Mailserver has a direct TCP connection, which means they are trusted to send traffic. This means a malicious or malfunctioning Mailserver can overwhelm an individual node. Censorship resistance . Devp2p TCP port blockable: . By default Devp2p runs on port 30303, which is not commonly used for any other service. This means it is easy to censor, e.g. airport WiFi. This can be mitigated somewhat by running on e.g. port 80 or 443, but there are still outstanding issues. See libp2p and Tor’s Pluggable Transport for how this can be improved. See https://github.com/status-im/status-react/issues/6351 for some discussion. ", + "content": "There are several security considerations to take into account when running Status. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used, such as Mailserver, light node, and so on. Scalability and UX . Bandwidth usage: . In version 1 of Status, bandwidth usage is likely to be an issue. In Status version 1.1 this is partially addressed with Waku usage, see the theoretical scaling model. Mailserver High Availability requirement: . A Mailserver has to be online to receive messages for other nodes, this puts a high availability requirement on it. Gossip-based routing: . Use of gossip-based routing doesn’t necessarily scale. It means each node can see a message multiple times, and having too many light nodes can cause propagation probability that is too low. See Whisper vs PSS for more and a possible Kademlia based alternative. Lack of incentives: . Status currently lacks incentives to run nodes, which means node operators are more likely to create centralized choke points. Privacy . Light node privacy: . The main privacy concern with light nodes is that directly connected peers will know that a message originates from them (as it are the only ones it sends). This means nodes can make assumptions about what messages (topics) their peers are interested in. Bloom filter privacy: . A user reveals which messages they are interested in, by setting only the topics they are interested in on the bloom filter. This is a fundamental trade-off between bandwidth usage and privacy, though the trade-off space is likely suboptimal in terms of the Anonymity trilemma. Mailserver client privacy: . A Mailserver client has to trust a Mailserver, which means they can send direct traffic. This reveals what topics / bloom filter a node is interested in, along with its peerID (with IP). Privacy guarantees not rigorous: . Privacy for Whisper or Waku hasn’t been studied rigorously for various threat models like global passive adversary, local active attacker, etc. This is unlike e.g. Tor and mixnets. Topic hygiene: . Similar to bloom filter privacy, using a very specific topic reveals more information. See scalability model linked above. Spam resistance . 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. Mailserver trusted connection: . A Mailserver has a direct TCP connection, which means they are trusted to send traffic. This means a malicious or malfunctioning Mailserver can overwhelm an individual node. Censorship resistance . Devp2p TCP port blockable: . By default Devp2p runs on port 30303, which is not commonly used for any other service. This means it is easy to censor, e.g. airport WiFi. This can be mitigated somewhat by running on e.g. port 80 or 443, but there are still outstanding issues. See libp2p and Tor’s Pluggable Transport for how this can be improved. See https://github.com/status-im/status-mobile/issues/6351 for some discussion. ", "url": "https://specs.status.im/spec/1#appendix-a-security-considerations", "relUrl": "/spec/1#appendix-a-security-considerations" },"9": { @@ -499,13 +499,13 @@ },"83": { "doc": "2/ACCOUNT", "title": "Trust establishment", - "content": "Trust establishment deals with users verifying they are communicating with who they think they are. Terms Glossary . | term | description | . | privkey | ECDSA secp256k1 private key | . | pubkey | ECDSA secp256k1 public key | . | Whisper/Waku key | pubkey for chat with HD derivation path m/43’/60’/1581’/0’/0 | . Contact Discovery . Public channels . | 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’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. | Discovery of channel names is not currently part of the protocol, and is typically done out of band. If a channel name is used that has not been used, it will be created. | A client MUST sign the message otherwise it will be discarded by the recipients. | channel name specification: . | matches [a-z0-9\\-] | is not a public key | . | . Private 1:1 messages . This can be done in the following ways: . | scanning a user generated QR code | discovery through the Status app | asynchronous X3DH key exchange | public key via public channel listening . | status-react/src/status_im/contact_code/core.cljs | . | contact codes | decentralized storage (not implemented) | Whisper/Waku | . Initial Key Exchange . Bundles . | An X3DH prekey bundle is defined as (code): Identity // Identity key SignedPreKeys // a map of installation id to array of signed prekeys by that installation id Signature // Prekey signature Timestamp // When the bundle was lasted created locally . | include BundleContainer | . | a new bundle SHOULD be created at least every 12 hours | a node only generates a bundle when it is used | a bundle SHOULD be distributed on the contact code channel. This is the Whisper and Waku topic {IK}-contact-code, where IK is the hex encoded public key of the user, prefixed with 0x. The node encrypts the channel in the same way it encrypted public chats. | . Contact Verification . To verify that contact key information is as it should be, use the following. Identicon . A low-poly identicon is deterministically generated from the Whisper/Waku chat public key. This can be compared out of band to ensure the receiver’s public key is the one stored locally. 3 word pseudonym / Whisper/Waku key fingerprint . Status generates a deterministic 3-word random pseudonym from the Whisper/Waku chat public key. This pseudonym acts as a human readable fingerprint to the Whisper/Waku chat public key. This name also shows when viewing a contact’s public profile and in the chat UI. | implementation: gfycat | . ENS name . Status offers the ability to register a mapping of a human readable subdomain of stateofus.eth to their Whisper/Waku chat public key. The user purchases this registration (currently by staking 10 SNT) and the node stores it on the Ethereum mainnet blockchain for public lookup. ", + "content": "Trust establishment deals with users verifying they are communicating with who they think they are. Terms Glossary . | term | description | . | privkey | ECDSA secp256k1 private key | . | pubkey | ECDSA secp256k1 public key | . | Whisper/Waku key | pubkey for chat with HD derivation path m/43’/60’/1581’/0’/0 | . Contact Discovery . Public channels . | 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’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. | Discovery of channel names is not currently part of the protocol, and is typically done out of band. If a channel name is used that has not been used, it will be created. | A client MUST sign the message otherwise it will be discarded by the recipients. | channel name specification: . | matches [a-z0-9\\-] | is not a public key | . | . Private 1:1 messages . This can be done in the following ways: . | scanning a user generated QR code | discovery through the Status app | asynchronous X3DH key exchange | public key via public channel listening . | status-mobile/src/status_im/contact_code/core.cljs | . | contact codes | decentralized storage (not implemented) | Whisper/Waku | . Initial Key Exchange . Bundles . | An X3DH prekey bundle is defined as (code): Identity // Identity key SignedPreKeys // a map of installation id to array of signed prekeys by that installation id Signature // Prekey signature Timestamp // When the bundle was lasted created locally . | include BundleContainer | . | a new bundle SHOULD be created at least every 12 hours | a node only generates a bundle when it is used | a bundle SHOULD be distributed on the contact code channel. This is the Whisper and Waku topic {IK}-contact-code, where IK is the hex encoded public key of the user, prefixed with 0x. The node encrypts the channel in the same way it encrypted public chats. | . Contact Verification . To verify that contact key information is as it should be, use the following. Identicon . A low-poly identicon is deterministically generated from the Whisper/Waku chat public key. This can be compared out of band to ensure the receiver’s public key is the one stored locally. 3 word pseudonym / Whisper/Waku key fingerprint . Status generates a deterministic 3-word random pseudonym from the Whisper/Waku chat public key. This pseudonym acts as a human readable fingerprint to the Whisper/Waku chat public key. This name also shows when viewing a contact’s public profile and in the chat UI. | implementation: gfycat | . ENS name . Status offers the ability to register a mapping of a human readable subdomain of stateofus.eth to their Whisper/Waku chat public key. The user purchases this registration (currently by staking 10 SNT) and the node stores it on the Ethereum mainnet blockchain for public lookup. ", "url": "https://specs.status.im/spec/2#trust-establishment", "relUrl": "/spec/2#trust-establishment" },"84": { "doc": "2/ACCOUNT", "title": "Public Key Serialization", - "content": "Idiomatically known as “public key compression” and “public key decompression”. The node SHOULD provide functionality for the serialization and deserialization of public / chat keys. For maximum flexibility, when implementing this functionality, the node MUST support public keys encoded in a range of encoding formats, detailed below. Basic Serialization Example . In the example of a typical hexadecimal encoded elliptical curve (EC) public key (such as a secp256k1 pk), . 0x04261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 . minor modification for compatibility and flexibility makes the key self-identifiable and easily parsable, . fe70104261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 . EC serialization and compact encoding produces a much smaller string representation of the original key. zQ3shPyZJnxZK4Bwyx9QsaksNKDYTPmpwPvGSjMYVHoXHeEgB . Public Key “Compression” Rationale . Serialized and compactly encoded (“compressed”) public keys have a number of UI / UX advantages over non-serialized less densely encoded public keys. Compressed public keys are smaller, and users may perceive them as less intimidating and less unnecessarily large. Compare the “compressed” and “uncompressed” version of the same public key from above example: . | 0xe70104261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 | zQ3shPyZJnxZK4Bwyx9QsaksNKDYTPmpwPvGSjMYVHoXHeEgB | . The user can transmit and share the same data, but at one third of the original size. 136 characters uncompressed vs 49 characters compressed, giving a significant character length reduction of 64%. The user client app MAY use the compressed public keys throughout the user interface. For example in the status-react implementation of the user interface the following places could take advantage of a significantly smaller public key: . | Onboarding > Choose a chat name | Profile > Header | Profile > Share icon > QR code popover | Invite friends url from Invite friends button and + -button > Invite friends | Other user Profile details | Profile details > Share icon > QR code popover | . In the case of QR codes a compressed public key can reduce the complexity of the derived codes: . | Uncompressed | Compressed | . | | | . Key Encoding . When implementing the pk de/serialization functionality, the node MUST use the multiformats/multibase encoding protocol to interpret incoming key data and to return key data in a desired encoding. The node SHOULD support the following multibase encoding formats. encoding, code, description, status identity, 0x00, 8-bit binary (encoder and decoder keeps data unmodified), default base2, 0, binary (01010101), candidate base8, 7, octal, draft base10, 9, decimal, draft base16, f, hexadecimal, default base16upper, F, hexadecimal, default base32hex, v, rfc4648 case-insensitive - no padding - highest char, candidate base32hexupper, V, rfc4648 case-insensitive - no padding - highest char, candidate base32hexpad, t, rfc4648 case-insensitive - with padding, candidate base32hexpadupper, T, rfc4648 case-insensitive - with padding, candidate base32, b, rfc4648 case-insensitive - no padding, default base32upper, B, rfc4648 case-insensitive - no padding, default base32pad, c, rfc4648 case-insensitive - with padding, candidate base32padupper, C, rfc4648 case-insensitive - with padding, candidate base32z, h, z-base-32 (used by Tahoe-LAFS), draft base36, k, base36 [0-9a-z] case-insensitive - no padding, draft base36upper, K, base36 [0-9a-z] case-insensitive - no padding, draft base58btc, z, base58 bitcoin, default base58flickr, Z, base58 flicker, candidate base64, m, rfc4648 no padding, default base64pad, M, rfc4648 with padding - MIME encoding, candidate base64url, u, rfc4648 no padding, default base64urlpad, U, rfc4648 with padding, default . Note this specification RECOMMENDs that implementations extend the standard multibase protocol to parse strings prepended with 0x as f hexadecimal encoded bytes. Implementing this recommendation will allow the node to correctly interpret traditionally identified hexadecimal strings (e.g. 0x1337c0de). Example: . 0xe70102261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc . SHOULD be interpreted as . fe70102261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc . This specification RECOMMENDs that the consuming service of the node uses a compact encoding type, such as base64 or base58 to allow for as short representations of the key as possible. Public Key Types . When implementing the pk de/serialization functionality, The node MUST support the multiformats/multicodec key type identifiers for the following public key type. | Name | Tag | Code | Description | . | secp256k1-pub | key | 0xe7 | Secp256k1 public key | . For a public key to be identifiable to the node the public key data MUST be prepended with the relevant multiformats/unsigned-varint formatted code. Example: . Below is a representation of an deserialized secp256k1 public key. 04 26 | 1c | 55 | 67 | 5e | 55 | ff | 25 ed | b5 | 0b | 34 | 5c | fb | 3a | 3f 35 | f6 | 07 | 12 | d2 | 51 | cb | aa ab | 97 | bd | 50 | 05 | 4c | 6e | bc 3c | d4 | e2 | 22 | 00 | c6 | 8d | af 74 | 93 | e1 | f8 | da | 6a | 19 | 0a 68 | a6 | 71 | e2 | d3 | 97 | 78 | 09 61 | 24 | 24 | c7 | c3 | 88 | 8b | c6 . The multicodec code for a secp256k1 public key is 0xe7. After parsing the code 0xe7 as a multiformats/uvarint, the byte value is 0xe7 0x01, prepending this to the public key results in the below representation. e7 | 01 | 04 26 | 1c | 55 | 67 | 5e | 55 | ff | 25 ed | b5 | 0b | 34 | 5c | fb | 3a | 3f 35 | f6 | 07 | 12 | d2 | 51 | cb | aa ab | 97 | bd | 50 | 05 | 4c | 6e | bc 3c | d4 | e2 | 22 | 00 | c6 | 8d | af 74 | 93 | e1 | f8 | da | 6a | 19 | 0a 68 | a6 | 71 | e2 | d3 | 97 | 78 | 09 61 | 24 | 24 | c7 | c3 | 88 | 8b | c6 . De/Serialization Process Flow . When implementing the pk de/serialization functionality, the node MUST be passed a multicodec identified public key, of the above supported types, encoded with a valid multibase identifier. This specification RECOMMENDs that the node also accept an encoding type parameter to encode the output data. This provides for the case where the user requires the de/serialization key to be in a different encoding to the encoding of the given key. Serialization Example . A hexadecimal encoded secp256k1 public chat key typically is represented as below: . 0x04261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 . To be properly interpreted by the node for serialization the public key MUST be prepended with the multicodec uvarint code 0xea 0x01 and encoded with a valid multibase encoding, therefore giving the following: . fea0104261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 . If adhering to the specification recommendation to provide the user with an output encoding parameter, the above string would be passed to the node with the following multibase encoding identifier. In this example the output encoding is defined as base58 bitcoin. z . The return value in this case would be . zQ3shPyZJnxZK4Bwyx9QsaksNKDYTPmpwPvGSjMYVHoXHeEgB . Which after multibase decoding can be represented in bytes as below: . e7 | 01 | 02 26 | 1c | 55 | 67 | 5e | 55 | ff | 25 ed | b5 | 0b | 34 | 5c | fb | 3a | 3f 35 | f6 | 07 | 12 | d2 | 51 | cb | aa ab | 97 | bd | 50 | 05 | 4c | 6e | bc . Deserialization Example . For the user, the deserialization process is exactly the same as serialization with the exception that the user MUST provide a serialized public key for deserialization. Else the deserialization algorithm will fail. For further guidance on the implementation of public key de/serialization consult the status-go implementation and tests. ", + "content": "Idiomatically known as “public key compression” and “public key decompression”. The node SHOULD provide functionality for the serialization and deserialization of public / chat keys. For maximum flexibility, when implementing this functionality, the node MUST support public keys encoded in a range of encoding formats, detailed below. Basic Serialization Example . In the example of a typical hexadecimal encoded elliptical curve (EC) public key (such as a secp256k1 pk), . 0x04261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 . minor modification for compatibility and flexibility makes the key self-identifiable and easily parsable, . fe70104261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 . EC serialization and compact encoding produces a much smaller string representation of the original key. zQ3shPyZJnxZK4Bwyx9QsaksNKDYTPmpwPvGSjMYVHoXHeEgB . Public Key “Compression” Rationale . Serialized and compactly encoded (“compressed”) public keys have a number of UI / UX advantages over non-serialized less densely encoded public keys. Compressed public keys are smaller, and users may perceive them as less intimidating and less unnecessarily large. Compare the “compressed” and “uncompressed” version of the same public key from above example: . | 0xe70104261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 | zQ3shPyZJnxZK4Bwyx9QsaksNKDYTPmpwPvGSjMYVHoXHeEgB | . The user can transmit and share the same data, but at one third of the original size. 136 characters uncompressed vs 49 characters compressed, giving a significant character length reduction of 64%. The user client app MAY use the compressed public keys throughout the user interface. For example in the status-mobile implementation of the user interface the following places could take advantage of a significantly smaller public key: . | Onboarding > Choose a chat name | Profile > Header | Profile > Share icon > QR code popover | Invite friends url from Invite friends button and + -button > Invite friends | Other user Profile details | Profile details > Share icon > QR code popover | . In the case of QR codes a compressed public key can reduce the complexity of the derived codes: . | Uncompressed | Compressed | . | | | . Key Encoding . When implementing the pk de/serialization functionality, the node MUST use the multiformats/multibase encoding protocol to interpret incoming key data and to return key data in a desired encoding. The node SHOULD support the following multibase encoding formats. encoding, code, description, status identity, 0x00, 8-bit binary (encoder and decoder keeps data unmodified), default base2, 0, binary (01010101), candidate base8, 7, octal, draft base10, 9, decimal, draft base16, f, hexadecimal, default base16upper, F, hexadecimal, default base32hex, v, rfc4648 case-insensitive - no padding - highest char, candidate base32hexupper, V, rfc4648 case-insensitive - no padding - highest char, candidate base32hexpad, t, rfc4648 case-insensitive - with padding, candidate base32hexpadupper, T, rfc4648 case-insensitive - with padding, candidate base32, b, rfc4648 case-insensitive - no padding, default base32upper, B, rfc4648 case-insensitive - no padding, default base32pad, c, rfc4648 case-insensitive - with padding, candidate base32padupper, C, rfc4648 case-insensitive - with padding, candidate base32z, h, z-base-32 (used by Tahoe-LAFS), draft base36, k, base36 [0-9a-z] case-insensitive - no padding, draft base36upper, K, base36 [0-9a-z] case-insensitive - no padding, draft base58btc, z, base58 bitcoin, default base58flickr, Z, base58 flicker, candidate base64, m, rfc4648 no padding, default base64pad, M, rfc4648 with padding - MIME encoding, candidate base64url, u, rfc4648 no padding, default base64urlpad, U, rfc4648 with padding, default . Note this specification RECOMMENDs that implementations extend the standard multibase protocol to parse strings prepended with 0x as f hexadecimal encoded bytes. Implementing this recommendation will allow the node to correctly interpret traditionally identified hexadecimal strings (e.g. 0x1337c0de). Example: . 0xe70102261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc . SHOULD be interpreted as . fe70102261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc . This specification RECOMMENDs that the consuming service of the node uses a compact encoding type, such as base64 or base58 to allow for as short representations of the key as possible. Public Key Types . When implementing the pk de/serialization functionality, The node MUST support the multiformats/multicodec key type identifiers for the following public key type. | Name | Tag | Code | Description | . | secp256k1-pub | key | 0xe7 | Secp256k1 public key | . For a public key to be identifiable to the node the public key data MUST be prepended with the relevant multiformats/unsigned-varint formatted code. Example: . Below is a representation of an deserialized secp256k1 public key. 04 26 | 1c | 55 | 67 | 5e | 55 | ff | 25 ed | b5 | 0b | 34 | 5c | fb | 3a | 3f 35 | f6 | 07 | 12 | d2 | 51 | cb | aa ab | 97 | bd | 50 | 05 | 4c | 6e | bc 3c | d4 | e2 | 22 | 00 | c6 | 8d | af 74 | 93 | e1 | f8 | da | 6a | 19 | 0a 68 | a6 | 71 | e2 | d3 | 97 | 78 | 09 61 | 24 | 24 | c7 | c3 | 88 | 8b | c6 . The multicodec code for a secp256k1 public key is 0xe7. After parsing the code 0xe7 as a multiformats/uvarint, the byte value is 0xe7 0x01, prepending this to the public key results in the below representation. e7 | 01 | 04 26 | 1c | 55 | 67 | 5e | 55 | ff | 25 ed | b5 | 0b | 34 | 5c | fb | 3a | 3f 35 | f6 | 07 | 12 | d2 | 51 | cb | aa ab | 97 | bd | 50 | 05 | 4c | 6e | bc 3c | d4 | e2 | 22 | 00 | c6 | 8d | af 74 | 93 | e1 | f8 | da | 6a | 19 | 0a 68 | a6 | 71 | e2 | d3 | 97 | 78 | 09 61 | 24 | 24 | c7 | c3 | 88 | 8b | c6 . De/Serialization Process Flow . When implementing the pk de/serialization functionality, the node MUST be passed a multicodec identified public key, of the above supported types, encoded with a valid multibase identifier. This specification RECOMMENDs that the node also accept an encoding type parameter to encode the output data. This provides for the case where the user requires the de/serialization key to be in a different encoding to the encoding of the given key. Serialization Example . A hexadecimal encoded secp256k1 public chat key typically is represented as below: . 0x04261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 . To be properly interpreted by the node for serialization the public key MUST be prepended with the multicodec uvarint code 0xea 0x01 and encoded with a valid multibase encoding, therefore giving the following: . fea0104261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6 . If adhering to the specification recommendation to provide the user with an output encoding parameter, the above string would be passed to the node with the following multibase encoding identifier. In this example the output encoding is defined as base58 bitcoin. z . The return value in this case would be . zQ3shPyZJnxZK4Bwyx9QsaksNKDYTPmpwPvGSjMYVHoXHeEgB . Which after multibase decoding can be represented in bytes as below: . e7 | 01 | 02 26 | 1c | 55 | 67 | 5e | 55 | ff | 25 ed | b5 | 0b | 34 | 5c | fb | 3a | 3f 35 | f6 | 07 | 12 | d2 | 51 | cb | aa ab | 97 | bd | 50 | 05 | 4c | 6e | bc . Deserialization Example . For the user, the deserialization process is exactly the same as serialization with the exception that the user MUST provide a serialized public key for deserialization. Else the deserialization algorithm will fail. For further guidance on the implementation of public key de/serialization consult the status-go implementation and tests. ", "url": "https://specs.status.im/spec/2#public-key-serialization", "relUrl": "/spec/2#public-key-serialization" },"85": { @@ -985,7 +985,7 @@ },"164": { "doc": "8/EIPS", "title": "Components", - "content": "BIP32 - Hierarchical Deterministic Wallets . Support: Dependency. Reference: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki Description: Enable wallets to derive multiple private keys from the same seed. Used for: Dependency of BIP39 and BIP43. BIP39 - Mnemonic code for generating deterministic keys . Support: Dependency. Reference: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki Description: Enable wallet to create private key based on a safe seed phrase. Used for: Security and user experience. BIP43 - Purpose Field for Deterministic Wallets . Support: Dependency. Reference: https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki Description: Enable wallet to create private keys branched for a specific purpose. Used for: Dependency of BIP44, uses “ethereum” coin. BIP44 - Multi-Account Hierarchy for Deterministic Wallets . Support: Dependency. Reference: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki Description: Enable wallet to derive multiple accounts in top of BIP39. Used for: Privacy. Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/constants.cljs#L240 Observation: BIP44 don’t solve privacy issues regarding the transparency of transactions, therefore directly connected addresses through a transactions can be identifiable by a “network reconnaissance attack” over transaction history, this attack together with leakage of information from centralized services, such as exchanges, would be fatal against the whole privacy of users, regardless of BIP44. EIP20 - Fungible Token . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-20 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 . EIP55 - Mixed-case checksum address encoding . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-55 Description: Checksum standard that uses lowercase and uppercase inside address hex value. Used for: Sanity check of forms using ethereum address. Related: https://github.com/status-im/status-react/issues/4959 https://github.com/status-im/status-react/issues/8707 Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/eip55.cljs . EIP67 - Standard URI scheme with metadata, value and byte code . Support: Partial. Reference: https://github.com/ethereum/EIPs/issues/67 Description: A standard way of creating Ethereum URIs for various use-cases. Used for: Legacy support. https://github.com/status-im/status-react/issues/875 . EIP137 - Ethereum Domain Name Service - Specification . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-137 Description: Enable wallets to lookup ENS names. Used for: User experience, as a wallet and identity feature, usernames. Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/ens.cljs#L86 . EIP155 - Simple replay attack protection . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-155 Description: Defined chainId parameter in the singed ethereum transaction payload. Used for: Signing transactions, crucial to safety of users against replay attacks. Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/core.cljs . EIP165 - Standard Interface Detection . Support: Dependency/Partial. Reference: https://eips.ethereum.org/EIPS/eip-165 Description: Standard interface for contract to answer if it supports other interfaces. Used for: Dependency of ENS and EIP721. Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/eip165.cljs . EIP181 - ENS support for reverse resolution of Ethereum addresses . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-181 Description: Enable wallets to render reverse resolution of Ethereum addresses. Used for: Wallet feature. Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/ens.cljs#L86 . EIP191 - Signed Message . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-191 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 . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-627 Description: format of Whisper messages within the ÐΞVp2p Wire Protocol. Used for: Chat protocol. EIP681 - URL Format for Transaction Requests . 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 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/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 . EIP712 - Typed Signed Message . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-712 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 . EIP721 - Non Fungible Token . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-721 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 . EIP945 - Web 3 QR Code Scanning API . Support: Full. Reference: https://github.com/ethereum/EIPs/issues/945 Used for: Sharing contactcode, reading transaction requests. Related: https://github.com/status-im/status-react/issues/5870 . EIP1102 - Opt-in account exposure . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-1102 Description: Allow users to opt-in the exposure of their ethereum address to dapps they browse. Used for: Privacy, DApp support. Related: https://github.com/status-im/status-react/issues/7985 . EIP1193 - Ethereum Provider JavaScript API . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-1193 Description: Allows dapps to recognize event changes on wallet. Used for: DApp support. Related: https://github.com/status-im/status-react/pull/7246 . EIP1577 - contenthash field for ENS . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-1577 Description: Allows users browse ENS domains using contenthash standard. Used for: Browser, DApp support. Related: https://github.com/status-im/status-react/issues/6688 Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/utils/contenthash.cljs https://github.com/status-im/status-react/blob/develop/test/cljs/status_im/test/utils/contenthash.cljs#L5 . EIP1581 - Non-wallet usage of keys derived from BIP-32 trees . 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 (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 . EIP1459 - Node Discovery via DNS . Support: - Reference: https://eips.ethereum.org/EIPS/eip-1459 Description: Allows the storing and retrieving of nodes through merkle trees stored in TXT records of a domain. Used for: Finding Waku nodes. Related: - Sourcecode: - . ", + "content": "BIP32 - Hierarchical Deterministic Wallets . Support: Dependency. Reference: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki Description: Enable wallets to derive multiple private keys from the same seed. Used for: Dependency of BIP39 and BIP43. BIP39 - Mnemonic code for generating deterministic keys . Support: Dependency. Reference: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki Description: Enable wallet to create private key based on a safe seed phrase. Used for: Security and user experience. BIP43 - Purpose Field for Deterministic Wallets . Support: Dependency. Reference: https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki Description: Enable wallet to create private keys branched for a specific purpose. Used for: Dependency of BIP44, uses “ethereum” coin. BIP44 - Multi-Account Hierarchy for Deterministic Wallets . Support: Dependency. Reference: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki Description: Enable wallet to derive multiple accounts in top of BIP39. Used for: Privacy. Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/constants.cljs#L240 Observation: BIP44 don’t solve privacy issues regarding the transparency of transactions, therefore directly connected addresses through a transactions can be identifiable by a “network reconnaissance attack” over transaction history, this attack together with leakage of information from centralized services, such as exchanges, would be fatal against the whole privacy of users, regardless of BIP44. EIP20 - Fungible Token . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-20 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-mobile/blob/develop/src/status_im/ethereum/tokens.cljs . EIP55 - Mixed-case checksum address encoding . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-55 Description: Checksum standard that uses lowercase and uppercase inside address hex value. Used for: Sanity check of forms using ethereum address. Related: https://github.com/status-im/status-mobile/issues/4959 https://github.com/status-im/status-mobile/issues/8707 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/eip55.cljs . EIP67 - Standard URI scheme with metadata, value and byte code . Support: Partial. Reference: https://github.com/ethereum/EIPs/issues/67 Description: A standard way of creating Ethereum URIs for various use-cases. Used for: Legacy support. https://github.com/status-im/status-mobile/issues/875 . EIP137 - Ethereum Domain Name Service - Specification . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-137 Description: Enable wallets to lookup ENS names. Used for: User experience, as a wallet and identity feature, usernames. Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/ens.cljs#L86 . EIP155 - Simple replay attack protection . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-155 Description: Defined chainId parameter in the singed ethereum transaction payload. Used for: Signing transactions, crucial to safety of users against replay attacks. Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/core.cljs . EIP165 - Standard Interface Detection . Support: Dependency/Partial. Reference: https://eips.ethereum.org/EIPS/eip-165 Description: Standard interface for contract to answer if it supports other interfaces. Used for: Dependency of ENS and EIP721. Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/eip165.cljs . EIP181 - ENS support for reverse resolution of Ethereum addresses . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-181 Description: Enable wallets to render reverse resolution of Ethereum addresses. Used for: Wallet feature. Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/ens.cljs#L86 . EIP191 - Signed Message . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-191 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 . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-627 Description: format of Whisper messages within the ÐΞVp2p Wire Protocol. Used for: Chat protocol. EIP681 - URL Format for Transaction Requests . 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 QR code data for transaction requests, chat transaction requests and for dapp links to transaction requests. Sourcecode: https://github.com/status-im/status-mobile/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-mobile/pull/9240 https://github.com/status-im/status-mobile/issues/9238 https://github.com/status-im/status-mobile/issues/7214 https://github.com/status-im/status-mobile/issues/7325 https://github.com/status-im/status-mobile/issues/8150 . EIP712 - Typed Signed Message . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-712 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-mobile/issues/5461 https://github.com/status-im/status-mobile/commit/ba37f7b8d029d3358c7b284f6a2383b9ef9526c9 . EIP721 - Non Fungible Token . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-721 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-mobile/issues/8909 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/erc721.cljs https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/tokens.cljs . EIP945 - Web 3 QR Code Scanning API . Support: Full. Reference: https://github.com/ethereum/EIPs/issues/945 Used for: Sharing contactcode, reading transaction requests. Related: https://github.com/status-im/status-mobile/issues/5870 . EIP1102 - Opt-in account exposure . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-1102 Description: Allow users to opt-in the exposure of their ethereum address to dapps they browse. Used for: Privacy, DApp support. Related: https://github.com/status-im/status-mobile/issues/7985 . EIP1193 - Ethereum Provider JavaScript API . Support: Full. Reference: https://eips.ethereum.org/EIPS/eip-1193 Description: Allows dapps to recognize event changes on wallet. Used for: DApp support. Related: https://github.com/status-im/status-mobile/pull/7246 . EIP1577 - contenthash field for ENS . Support: Partial. Reference: https://eips.ethereum.org/EIPS/eip-1577 Description: Allows users browse ENS domains using contenthash standard. Used for: Browser, DApp support. Related: https://github.com/status-im/status-mobile/issues/6688 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/utils/contenthash.cljs https://github.com/status-im/status-mobile/blob/develop/test/cljs/status_im/test/utils/contenthash.cljs#L5 . EIP1581 - Non-wallet usage of keys derived from BIP-32 trees . 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 (don’t reuse wallet key) and user experience (don’t request keycard every login). Related: https://github.com/status-im/status-mobile/issues/9088 https://github.com/status-im/status-mobile/pull/9096 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/constants.cljs#L242 . EIP1459 - Node Discovery via DNS . Support: - Reference: https://eips.ethereum.org/EIPS/eip-1459 Description: Allows the storing and retrieving of nodes through merkle trees stored in TXT records of a domain. Used for: Finding Waku nodes. Related: - Sourcecode: - . ", "url": "https://specs.status.im/spec/8#components", "relUrl": "/spec/8#components" },"165": { diff --git a/draft/14.html b/draft/14.html index bc52e9b..2840cf9 100644 --- a/draft/14.html +++ b/draft/14.html @@ -1 +1 @@ - 14/Dapp browser API usage - Status Specification 14/Dapp browser API usage | Status Specification Link Search Menu Expand Document
Status Specification
This site uses Just the Docs, a documentation theme for Jekyll.

Dapp browser API usage

Table of Contents

  1. Abstract
  2. Definitions
  3. Overview
  4. Usage
  5. Implementation
  6. Compatibility
  7. Changelog
  8. Copyright

Abstract

This document describes requirements that an application must fulfill in order to provide a proper environment for Dapps running inside a browser. A description of the Status Dapp API is provided, along with an overview of bidirectional communication underlying the API implementation. The document also includes a list of EIPs that this API implements.

Definitions

Term Description
Webview Platform-specific browser core implementation.
Ethereum Provider A JS object (window.ethereum) injected into each web page opened in the browser providing web3 compatible provider.
Bridge A set of facilities allow bidirectional communication between JS code and the application.

Overview

The application should expose an Ethereum Provider object (window.ethereum) to JS code running inside the browser. It is important to have the window.ethereum object available before the page loads, otherwise Dapps might not work correctly.

Additionally, the browser component should also provide bidirectional communication between JS code and the application.

Usage in Dapps

Dapps can use the below properties and methods of window.ethereum object.

Properties

isStatus

Returns true. Can be used by the Dapp to find out whether it’s running inside Status.

status

Returns a StatusAPI object. For now it supports one method: getContactCode that sends a contact-code request to Status.

Methods

isConnected

Similarly to Ethereum JS API docs, it should be called to check if connection to a node exists. On Status, this fn always returns true, as once Status is up and running, node is automatically started.

scanQRCode

Sends a qr-code Status API request.

request

request method as defined by EIP-1193.

Unused

Below are some legacy methods that some Dapps might still use.

enable (DEPRECATED)

Sends a web3 Status API request. It returns a first entry in the list of available accounts.

Legacy enable method as defined by EIP1102.

send (DEPRECATED)

Legacy send method as defined by EIP1193.

sendAsync (DEPRECATED)

Legacy sendAsync method as defined by EIP1193.

sendSync (DEPRECATED)

Legacy send method.

Implementation

Status uses a forked version of react-native-webview to display web or dapps content. The fork provides an Android implementation of JS injection before page load. It is required in order to properly inject Ethereum Provider object.

Status injects two JS scripts:

Dapps running inside a browser communicate with Status Ethereum node by means of a bridge provided by react-native-webview library. The bridge allows for bidirectional communication between browser and Status. In order to do so, it injects a special ReactNativeWebview object into each page it loads.

On Status (React Native) end, react-native-webview library provides WebView.injectJavascript function on a webview component that allows to execute arbitrary code inside the webview. Thus it is possible to inject a function call passing Status node response back to the Dapp.

Below is the table briefly describing what functions/properties are used. More details available in package docs.

Direction Side Method
Browser->Status JS ReactNativeWebView.postMessage()
Browser->Status RN WebView.onMessage()
Status->Browser JS ReactNativeWebView.onMessage()
Status->Browser RN WebView.injectJavascript()

Compatibility

Status browser supports the following EIPs:

  • EIP1102: eth_requestAccounts support
  • EIP1193: connect, disconnect, chainChanged, and accountsChanged event support is not implemented

Changelog

Version Comment
0.1.0 Initial Release

Copyright and related rights waived via CC0.

+ 14/Dapp browser API usage - Status Specification 14/Dapp browser API usage | Status Specification Link Search Menu Expand Document
Status Specification
This site uses Just the Docs, a documentation theme for Jekyll.

Dapp browser API usage

Table of Contents

  1. Abstract
  2. Definitions
  3. Overview
  4. Usage
  5. Implementation
  6. Compatibility
  7. Changelog
  8. Copyright

Abstract

This document describes requirements that an application must fulfill in order to provide a proper environment for Dapps running inside a browser. A description of the Status Dapp API is provided, along with an overview of bidirectional communication underlying the API implementation. The document also includes a list of EIPs that this API implements.

Definitions

Term Description
Webview Platform-specific browser core implementation.
Ethereum Provider A JS object (window.ethereum) injected into each web page opened in the browser providing web3 compatible provider.
Bridge A set of facilities allow bidirectional communication between JS code and the application.

Overview

The application should expose an Ethereum Provider object (window.ethereum) to JS code running inside the browser. It is important to have the window.ethereum object available before the page loads, otherwise Dapps might not work correctly.

Additionally, the browser component should also provide bidirectional communication between JS code and the application.

Usage in Dapps

Dapps can use the below properties and methods of window.ethereum object.

Properties

isStatus

Returns true. Can be used by the Dapp to find out whether it’s running inside Status.

status

Returns a StatusAPI object. For now it supports one method: getContactCode that sends a contact-code request to Status.

Methods

isConnected

Similarly to Ethereum JS API docs, it should be called to check if connection to a node exists. On Status, this fn always returns true, as once Status is up and running, node is automatically started.

scanQRCode

Sends a qr-code Status API request.

request

request method as defined by EIP-1193.

Unused

Below are some legacy methods that some Dapps might still use.

enable (DEPRECATED)

Sends a web3 Status API request. It returns a first entry in the list of available accounts.

Legacy enable method as defined by EIP1102.

send (DEPRECATED)

Legacy send method as defined by EIP1193.

sendAsync (DEPRECATED)

Legacy sendAsync method as defined by EIP1193.

sendSync (DEPRECATED)

Legacy send method.

Implementation

Status uses a forked version of react-native-webview to display web or dapps content. The fork provides an Android implementation of JS injection before page load. It is required in order to properly inject Ethereum Provider object.

Status injects two JS scripts:

Dapps running inside a browser communicate with Status Ethereum node by means of a bridge provided by react-native-webview library. The bridge allows for bidirectional communication between browser and Status. In order to do so, it injects a special ReactNativeWebview object into each page it loads.

On Status (React Native) end, react-native-webview library provides WebView.injectJavascript function on a webview component that allows to execute arbitrary code inside the webview. Thus it is possible to inject a function call passing Status node response back to the Dapp.

Below is the table briefly describing what functions/properties are used. More details available in package docs.

Direction Side Method
Browser->Status JS ReactNativeWebView.postMessage()
Browser->Status RN WebView.onMessage()
Status->Browser JS ReactNativeWebView.onMessage()
Status->Browser RN WebView.injectJavascript()

Compatibility

Status browser supports the following EIPs:

  • EIP1102: eth_requestAccounts support
  • EIP1193: connect, disconnect, chainChanged, and accountsChanged event support is not implemented

Changelog

Version Comment
0.1.0 Initial Release

Copyright and related rights waived via CC0.

diff --git a/draft/3.html b/draft/3.html index 3819644..91f3399 100644 --- a/draft/3.html +++ b/draft/3.html @@ -1,4 +1,4 @@ - 3/WHISPER-USAGE - Status Specification 3/WHISPER-USAGE | Status Specification Link Search Menu Expand Document
Status Specification
This site uses Just the Docs, a documentation theme for Jekyll.

3/WHISPER-USAGE

Version: 0.3

Status: Draft

Authors: Adam Babik adam@status.im, Andrea Maria Piana andreap@status.im, Corey Petty corey@status.im, Oskar Thorén oskar@status.im (alphabetical order)

Abstract

Status uses Whisper to provide privacy-preserving routing and messaging on top of devP2P. Whisper uses topics to partition its messages, and these are leveraged for all chat capabilities. In the case of public chats, the channel name maps directly to its Whisper topic. This allows anyone to listen on a single channel.

Additionally, since anyone can receive Whisper envelopes, it relies on the ability to decrypt messages to decide who is the correct recipient. Status nodes do not rely upon this property, and implement another secure transport layer on top of Whisper.

Finally, using an extension of Whisper provides the ability to do offline messaging.

Reason

Provide routing, metadata protection, topic-based multicasting and basic 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 network: a group of Whisper nodes connected together through the internet connection and forming a graph
  • Message: a decrypted Whisper message
  • Offline message: an archived envelope
  • Envelope: an encrypted message with metadata like topic and Time-To-Live

Whisper packets

Packet Name Code EIP-627 References
Status 0 ✔ Handshake
Messages 1 ✔ EIP-627
PoW Requirement 2 ✔ EIP-627
Bloom Filter 3 ✔ EIP-627
Batch Ack 11 𝘅 Undocumented
Message Response 12 𝘅 Undocumented
P2P Sync Request 123 𝘅 Undocumented
P2P Sync Response 124 𝘅 Undocumented
P2P Request Complete 125 𝘅 4/WHISPER-MAILSERVER
P2P Request 126 ✔ 4/WHISPER-MAILSERVER
P2P Messages 127 ✔/𝘅 (EIP-627 supports only single envelope in a packet) 4/WHISPER-MAILSERVER

Whisper node configuration

A Whisper node must be properly configured to receive messages from Status clients.

Whisper’s Proof Of Work algorithm is used to deter denial of service and various spam/flood attacks against the Whisper network. The sender of a message must perform some work which in this case means processing time. Because Status’ main client is a mobile client, this easily leads to battery draining and poor performance of the app itself. Hence, all clients MUST use the following Whisper node settings:

  • proof-of-work requirement not larger than 0.00001
  • time-to-live not lower than 10 (in seconds)
  • any payload below 50000 bytes MUST be sent with a PoW Target of at least 0.002, in order to maintain backward compatibility with version 0.2 and Status app version 1.3 and below

Handshake

Handshake is a RLP-encoded packet sent to a newly connected peer. It MUST start with a Status Code (0x00) and follow up with items:

[ protocolVersion, PoW, bloom, isLightNode, confirmationsEnabled, rateLimits ]
+     3/WHISPER-USAGE - Status Specification       3/WHISPER-USAGE | Status Specification               Link      Search      Menu      Expand      Document      
 
  Status Specification     
  
 This site uses Just the Docs, a documentation theme for Jekyll. 
 
 
 
 
 
   
 
 
 
 
  
 
  3/WHISPER-USAGE 
 
 
Version: 0.3
 
Status: Draft
 
Authors: Adam Babik adam@status.im, Andrea Maria Piana andreap@status.im, Corey Petty corey@status.im, Oskar Thorén oskar@status.im (alphabetical order)
 
  
  Abstract 
 
Status uses Whisper to provide privacy-preserving routing and messaging on top of devP2P. Whisper uses topics to partition its messages, and these are leveraged for all chat capabilities. In the case of public chats, the channel name maps directly to its Whisper topic. This allows anyone to listen on a single channel.
 
Additionally, since anyone can receive Whisper envelopes, it relies on the ability to decrypt messages to decide who is the correct recipient. Status nodes do not rely upon this property, and implement another secure transport layer on top of Whisper.
 
Finally, using an extension of Whisper provides the ability to do offline messaging.
 
  Reason 
 
Provide routing, metadata protection, topic-based multicasting and basic 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 network: a group of Whisper nodes connected together through the internet connection and forming a graph
    •  
  • Message: a decrypted Whisper message
    •  
  • Offline message: an archived envelope
    •  
  • Envelope: an encrypted message with metadata like topic and Time-To-Live
    •  
 
  Whisper packets 
 
  
 Packet Name Code EIP-627 References 
   
 Status 0 ✔ Handshake 
 
 Messages 1 ✔ EIP-627 
 
 PoW Requirement 2 ✔ EIP-627 
 
 Bloom Filter 3 ✔ EIP-627 
 
 Batch Ack 11 𝘅 Undocumented 
 
 Message Response 12 𝘅 Undocumented 
 
 P2P Sync Request 123 𝘅 Undocumented 
 
 P2P Sync Response 124 𝘅 Undocumented 
 
 P2P Request Complete 125 𝘅 4/WHISPER-MAILSERVER 
 
 P2P Request 126 ✔ 4/WHISPER-MAILSERVER 
 
 P2P Messages 127 ✔/𝘅 (EIP-627 supports only single envelope in a packet) 4/WHISPER-MAILSERVER 
  
 
  Whisper node configuration 
 
A Whisper node must be properly configured to receive messages from Status clients.
 
Whisper’s Proof Of Work algorithm is used to deter denial of service and various spam/flood attacks against the Whisper network. The sender of a message must perform some work which in this case means processing time. Because Status’ main client is a mobile client, this easily leads to battery draining and poor performance of the app itself. Hence, all clients MUST use the following Whisper node settings:
 
     
  • proof-of-work requirement not larger than 0.00001
    •  
  • time-to-live not lower than 10 (in seconds)
    •  
  • any payload below 50000 bytes MUST be sent with a PoW Target of at least 0.002, in order to maintain backward compatibility with version 0.2 and Status app version 1.3 and below
    •  
 
  Handshake 
 
Handshake is a RLP-encoded packet sent to a newly connected peer. It MUST start with a Status Code (0x00) and follow up with items:
 
[ protocolVersion, PoW, bloom, isLightNode, confirmationsEnabled, rateLimits ]
 
 
protocolVersion: version of the Whisper protocol PoW: minimum PoW accepted by the peer bloom: bloom filter of Whisper topic accepted by the peer isLightNode: when true, the peer won’t forward messages confirmationsEnabled: when true, the peer will send message confirmations rateLimits: is [ RateLimitIP, RateLimitPeerID, RateLimitTopic ] where each values is an integer with a number of accepted packets per second per IP, Peer ID, and Topic respectively
 
bloom, isLightNode, confirmationsEnabled, and rateLimits are all optional arguments in the handshake. However, if an optional field is specified, all optional fields preceding it MUST also be specified in order to be unambiguous.
 
  Rate limiting 
 
In order to provide an optional very basic Denial-of-Service attack protection, each node SHOULD define its own rate limits. The rate limits SHOULD be applied on IPs, peer IDs, and envelope topics.
 
Each node MAY decide to whitelist, i.e. do not rate limit, selected IPs or peer IDs.
 
If a peer exceeds node’s rate limits, the connection between them MAY be dropped.
 
Each node SHOULD broadcast its rate limits to its peers using rate limits packet code (0x14). The rate limits is RLP-encoded information:
 
[ IP limits, PeerID limits, Topic limits ]
 
 
IP limits: 4-byte wide unsigned integer PeerID limits: 4-byte wide unsigned integer Topic limits: 4-byte wide unsigned integer
 
The rate limits MAY also be sent as an optional parameter in the handshake.
 
Each node SHOULD respect rate limits advertised by its peers. The number of packets SHOULD be throttled in order not to exceed peer’s rate limits. If the limit gets exceeded, the connection MAY be dropped by the peer.
 
  Keys management 
 
The protocol requires a key (symmetric or asymmetric) for the following actions:
 
     
  • signing & verifying messages (asymmetric key)
    •  
  • encrypting & decrypting messages (asymmetric or symmetric key).
    •  
 
As nodes require asymmetric keys and symmetric keys to process incoming messages, they must be available all the time and are stored in memory.
 
Keys management for PFS is described in 5/SECURE-TRANSPORT.
 
The Status protocols uses a few particular Whisper topics to achieve its goals.
 
  Contact code topic 
 
Nodes use the contact code topic to facilitate the discovery of X3DH bundles so that the first message can be PFS-encrypted.
 
Each user publishes periodically to this topic. If user A wants to contact user B, she SHOULD look for their bundle on this contact code topic.
 
Contact code topic MUST be created following the algorithm below:
 
contactCode := "0x" + hexEncode(activePublicKey) + "-contact-code"
 
diff --git a/sitemap.xml b/sitemap.xml
index 8cfe8ac..2651de8 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -83,6 +83,6 @@
 
 
 https://specs.status.im/default.html
-2021-11-16T14:28:01+00:00
+2022-07-17T14:26:26+00:00
 
 
diff --git a/spec/1.html b/spec/1.html
index 499a36f..769bb64 100644
--- a/spec/1.html
+++ b/spec/1.html
@@ -1 +1 @@
-     1/CLIENT - Status Specification       1/CLIENT | Status Specification               Link      Search      Menu      Expand      Document      
 
  Status Specification     
  
 This site uses Just the Docs, a documentation theme for Jekyll. 
 
 
 
 
 
   
 
 
 
 
  
 
  1/CLIENT 
 
 
Version: 0.3
 
Status: Stable
 
Authors: Adam Babik adam@status.im, Andrea Maria Piana andreap@status.im, Dean Eigenmann dean@status.im, Corey Petty corey@status.im, Oskar Thorén oskar@status.im, Samuel Hawksby-Robinson samuel@status.im (alphabetical order)
 
 
  Abstract 
 
This specification describes how to write a Status client for communicating with other Status clients.
 
This specification presents a reference implementation of the protocol 1 that is used in a command line client 2 and a mobile app 3.
 
This document consists of two parts. The first outlines the specifications that have to be implemented in order to be a full Status client. The second gives a design rationale and answers some common questions.
 
  Table of Contents 
  
  Introduction 
 
  Protocol layers 
 
Implementing a Status clients largely means implementing the following layers. Additionally, there are separate specifications for things like key management and account lifecycle.
 
Other aspects, such as how a node uses IPFS for stickers or how the browser works, are currently underspecified. These specifications facilitate the implementation of a Status client for basic private communication.
 
  
 Layer Purpose Technology 
   
 Data and payloads End user functionality 1:1, group chat, public chat 
 
 Data sync Data consistency MVDS. 
 
 Secure transport Confidentiality, PFS, etc Double Ratchet 
 
 Transport privacy Routing, Metadata protection Waku / Whisper 
 
 P2P Overlay Overlay routing, NAT traversal devp2p 
  
 
  Protobuf 
 
protobuf is used in different layers, version proto3 used is unless stated otherwise.
 
  Components 
 
  P2P Overlay 
 
Status clients run on a public, permissionless peer-to-peer network, as specified by the devP2P network protocols. devP2P provides a protocol for node discovery which is in draft mode here. See more on node discovery and management in the next section.
 
To communicate between Status nodes, the RLPx Transport Protocol, v5 is used, which allows for TCP-based communication between nodes.
 
On top of this RLPx-based subprotocols are ran, the client SHOULD NOT use Whisper V6, the client SHOULD use Waku V1 for privacy-preserving messaging and efficient usage of a node’s bandwidth.
 
  Node discovery and roles 
 
There are four types of node roles:
 
     
  1. Bootstrap node
    2.  
  2. Whisper/Waku relayer
    3.  
  3. Mailserver (servers and clients)
    4.  
  4. Mobile node (Status Clients)
    5.  
 
A standard Status client MUST implement both Whisper/Waku relayer and Mobile node node types. The other node types are optional, but it is RECOMMEND to implement a Mailserver client mode, otherwise the user experience is likely to be poor.
 
  Bootstrapping 
 
Bootstrap nodes allow Status nodes to discover and connect to other Status nodes in the network.
 
Currently, Status Gmbh provides the main bootstrap nodes, but anyone can run these provided they are connected to the rest of the Whisper/Waku network.
 
Status maintains a list of production fleet bootstrap nodes in the following locations:
 
Hong Kong:
 
     
  • enode://6e6554fb3034b211398fcd0f0082cbb6bd13619e1a7e76ba66e1809aaa0c5f1ac53c9ae79cf2fd4a7bacb10d12010899b370c75fed19b991d9c0cdd02891abad@47.75.99.169:443
    •  
  • enode://23d0740b11919358625d79d4cac7d50a34d79e9c69e16831c5c70573757a1f5d7d884510bc595d7ee4da3c1508adf87bbc9e9260d804ef03f8c1e37f2fb2fc69@47.52.106.107:443
    •  
 
Amsterdam:
 
     
  • enode://436cc6f674928fdc9a9f7990f2944002b685d1c37f025c1be425185b5b1f0900feaf1ccc2a6130268f9901be4a7d252f37302c8335a2c1a62736e9232691cc3a@178.128.138.128:443
    •  
  • enode://5395aab7833f1ecb671b59bf0521cf20224fe8162fc3d2675de4ee4d5636a75ec32d13268fc184df8d1ddfa803943906882da62a4df42d4fccf6d17808156a87@178.128.140.188:443
    •  
 
Central US:
 
     
  • enode://32ff6d88760b0947a3dee54ceff4d8d7f0b4c023c6dad34568615fcae89e26cc2753f28f12485a4116c977be937a72665116596265aa0736b53d46b27446296a@34.70.75.208:443
    •  
  • enode://5405c509df683c962e7c9470b251bb679dd6978f82d5b469f1f6c64d11d50fbd5dd9f7801c6ad51f3b20a5f6c7ffe248cc9ab223f8bcbaeaf14bb1c0ef295fd0@35.223.215.156:443
    •  
 
These bootstrap nodes MAY change and are not guaranteed to stay this way forever and at some point circumstances might force them to change.
 
  Discovery 
 
A Status client MUST discover or have a list of peers to connect to. Status uses a light discovery mechanism based on a combination of Discovery v5 and Rendezvous Protocol, (with some modifications). Additionally, some static nodes MAY also be used.
 
A Status client MUST use at least one discovery method or use static nodes to communicate with other clients.
 
Discovery V5 uses bootstrap nodes to discover other peers. Bootstrap nodes MUST support Discovery V5 protocol as well in order to provide peers. It is kademlia-based discovery mechanism and it might consume significant (at least on mobile) amount of network traffic to operate.
 
In order to take advantage from simpler and more mobile-friendly peers discovery mechanism, i.e. Rendezvous protocol, one MUST provide a list of Rendezvous nodes which speak Rendezvous protocol. Rendezvous protocol is request-response discovery mechanism. It uses Ethereum Node Records (ENR) to report discovered peers.
 
Both peers discovery mechanisms use topics to provide peers with certain capabilities. There is no point in returning peers that do not support a particular protocol. Status nodes that want to be discovered MUST register to Discovery V5 and/or Rendezvous with the whisper topic. Status nodes that are Mailservers and want to be discoverable MUST additionally register with the whispermail topic.
 
It is RECOMMENDED to use both mechanisms but at the same time implement a structure called PeerPool. PeerPool is responsible for maintaining an optimal number of peers. For mobile nodes, there is no significant advantage to have more than 2-3 peers and one Mailserver. PeerPool can notify peers discovery protocol implementations that they should suspend their execution because the optimal number of peers is found. They should resume if the number of connected peers drops or a Mailserver disconnects.
 
It is worth noticing that an efficient caching strategy MAY be of great use, especially, on mobile devices. Discovered peers can be cached as they rarely change and used when the client starts again. In such a case, there might be no need to even start peers discovery protocols because cached peers will satisfy the optimal number of peers.
 
Alternatively, a client MAY rely exclusively on a list of static peers. This is the most efficient way because there are no peers discovery algorithm overhead introduced. The disadvantage is that these peers might be gone and without peers discovery mechanism, it won’t be possible to find new ones.
 
The current list of static peers is published on https://fleets.status.im/. eth.prod is the current group of peers the official Status client uses. The others are test networks.
 
Finally, Waku node addresses can be retrieved by traversing the merkle tree found at fleets.status.im, as described in EIP-1459.
 
  Mobile nodes 
 
A Mobile node is a Whisper and/or Waku node which connects to part of the respective Whisper and/or Waku network(s). A Mobile node MAY relay messages. See next section for more details on how to use Whisper and/or Waku to communicate with other Status nodes.
 
  Transport privacy and Whisper / Waku usage 
 
Once a Whisper and/or Waku node is up and running there are some specific settings required to communicate with other Status nodes.
 
See 3/WHISPER-USAGE and 10/WAKU-USAGE for more details.
 
For providing an offline inbox, see the complementary 4/WHISPER-MAILSERVER and 11/WAKU-MAILSERVER.
 
  Secure Transport 
 
In order to provide confidentiality, integrity, authentication and forward secrecy of messages the node implements a secure transport on top of Whisper and Waku. This is used in 1:1 chats and group chats, but not for public chats. See 5/SECURE-TRANSPORT for more.
 
  Data Sync 
 
MVDS is used for 1:1 and group chats, however it is currently not in use for public chats. Status payloads are serialized and then wrapped inside an MVDS message which is added to an MVDS payload, the node encrypts this payload (if necessary for 1-to-1 / group-chats) and sends it using Whisper or Waku which also encrypts it.
 
  Payloads and clients 
 
On top of secure transport, various types of data sync clients and the node uses payload formats for things like 1:1 chat, group chat and public chat. These have various degrees of standardization. Please refer to 6/PAYLOADS for more details.
 
  BIPs and EIPs Standards support 
 
For a list of EIPs and BIPs that SHOULD be supported by Status client, please see 8/EIPS.
 
  Security Considerations 
 
See Appendix A
 
  Design Rationale 
 
  P2P Overlay 
 
  Why devp2p? Why not use libp2p? 
 
At the time Status developed the main Status clients, devp2p was the most mature. However, in the future libp2p is likely to be used, as it’ll provide us with multiple transports, better protocol negotiation, NAT traversal, etc.
 
For very experimental bridge support, see the bridge between libp2p and devp2p in Murmur.
 
  What about other RLPx subprotocols like LES, and Swarm? 
 
Status is primarily optimized for resource restricted devices, and at present time light client support for these protocols are suboptimal. This is a work in progress.
 
For better Ethereum light client support, see Re-enable LES as option. For better Swarm support, see Swarm adaptive nodes.
 
For transaction support, Status clients currently have to rely on Infura.
 
Status clients currently do not offer native support for file storage.
 
  Why do you use Whisper? 
 
Whisper is one of the three parts of the vision of Ethereum as the world computer, Ethereum and Swarm being the other two. Status was started as an encapsulation of and a clear window to this world computer.
 
  Why do you use Waku? 
 
Waku is a direct upgrade and replacement for Whisper, the main motivation for developing and implementing Waku can be found in the Waku specs.
 
 
Waku was created to incrementally improve in areas that Whisper is lacking in, with special attention to resource restricted devices. We specify the standard for Waku messages in order to ensure forward compatibility of different Waku clients, backwards compatibility with Whisper clients, as well as to allow multiple implementations of Waku and its capabilities. We also modify the language to be more unambiguous, concise and consistent.
 
 
Considerable work has gone into the active development of Ethereum, in contrast Whisper is not currently under active development, and it has several drawbacks. Among others:
 
     
  • Whisper is very wasteful bandwidth-wise and doesn’t appear to be scalable
    •  
  • Proof of work is a poor spam protection mechanism for heterogeneous devices
    •  
  • The privacy guarantees provided are not rigorous
    •  
  • There are no incentives to run a node
    •  
 
Finding a more suitable transport privacy is an ongoing research effort, together with Vac and other teams in the space.
 
  Why is PoW for Waku set so low? 
 
A higher PoW would be desirable, but this kills the battery on mobile phones, which is a prime target for Status clients.
 
This means the network is currently vulnerable to DDoS attacks. Alternative methods of spam protection are currently being researched.
 
  Why do you not use Discovery v5 for node discovery? 
 
At the time of implementing dynamic node discovery, Discovery v5 wasn’t completed yet. Additionally, running a DHT on a mobile leads to slow node discovery, bad battery and poor bandwidth usage. Instead, each client can choose to turn on Discovery v5 for a short period until the node populates their peer list.
 
For some further investigation, see here.
 
  I heard something about Mailservers being trusted somehow? 
 
In order to use a Mailserver, a given node needs to connect to it directly, i.e. add the Mailserver as its peer and mark it as trusted. This means that the Mailserver is able to send direct p2p messages to the node instead of broadcasting them. Effectively, it knows the bloom filter of the topics the node is interested in, when it is online as well as many metadata like IP address.
 
  Data sync 
 
  Why is MVDS not used for public chats? 
 
Currently, public chats are broadcast-based, and there’s no direct way of finding out who is receiving messages. Hence there’s no clear group sync state context whereby participants can sync. Additionally, MVDS is currently not optimized for large group contexts, which means bandwidth usage will be a lot higher than reasonable. See P2P Data Sync for Mobile for more. This is an active area of research.
 
  Footnotes 
 
     
  1. https://github.com/status-im/status-protocol-go/
    2.  
  2. https://github.com/status-im/status-console-client/
    3.  
  3. https://github.com/status-im/status-react/
    4.  
 
  Appendix A: Security considerations 
 
There are several security considerations to take into account when running Status. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used, such as Mailserver, light node, and so on.
 
  Scalability and UX 
 
Bandwidth usage:
 
In version 1 of Status, bandwidth usage is likely to be an issue. In Status version 1.1 this is partially addressed with Waku usage, see the theoretical scaling model.
 
Mailserver High Availability requirement:
 
A Mailserver has to be online to receive messages for other nodes, this puts a high availability requirement on it.
 
Gossip-based routing:
 
Use of gossip-based routing doesn’t necessarily scale. It means each node can see a message multiple times, and having too many light nodes can cause propagation probability that is too low. See Whisper vs PSS for more and a possible Kademlia based alternative.
 
Lack of incentives:
 
Status currently lacks incentives to run nodes, which means node operators are more likely to create centralized choke points.
 
  Privacy 
 
Light node privacy:
 
The main privacy concern with light nodes is that directly connected peers will know that a message originates from them (as it are the only ones it sends). This means nodes can make assumptions about what messages (topics) their peers are interested in.
 
Bloom filter privacy:
 
A user reveals which messages they are interested in, by setting only the topics they are interested in on the bloom filter. This is a fundamental trade-off between bandwidth usage and privacy, though the trade-off space is likely suboptimal in terms of the Anonymity trilemma.
 
Mailserver client privacy:
 
A Mailserver client has to trust a Mailserver, which means they can send direct traffic. This reveals what topics / bloom filter a node is interested in, along with its peerID (with IP).
 
Privacy guarantees not rigorous:
 
Privacy for Whisper or Waku hasn’t been studied rigorously for various threat models like global passive adversary, local active attacker, etc. This is unlike e.g. Tor and mixnets.
 
Topic hygiene:
 
Similar to bloom filter privacy, using a very specific topic reveals more information. See scalability model linked above.
 
  Spam resistance 
 
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.
 
Mailserver trusted connection:
 
A Mailserver has a direct TCP connection, which means they are trusted to send traffic. This means a malicious or malfunctioning Mailserver can overwhelm an individual node.
 
  Censorship resistance 
 
Devp2p TCP port blockable:
 
By default Devp2p runs on port 30303, which is not commonly used for any other service. This means it is easy to censor, e.g. airport WiFi. This can be mitigated somewhat by running on e.g. port 80 or 443, but there are still outstanding issues. See libp2p and Tor’s Pluggable Transport for how this can be improved.
 
See https://github.com/status-im/status-react/issues/6351 for some discussion.
 
  Acknowledgments 
 
Jacek Sieka
 
  Changelog 
 
  Version 0.3 
 
Released May 22, 2020
 
     
  • Added that Waku SHOULD be used
    •  
  • Added that Whisper SHOULD NOT be used
    •  
  • Added language to include Waku in all relevant places
    •  
  • Change to keep Mailserver term consistent
    •  
  
Copyright and related rights waived via CC0.
 
 
 
 
  
+     1/CLIENT - Status Specification       1/CLIENT | Status Specification               Link      Search      Menu      Expand      Document      
 
  Status Specification     
  
 This site uses Just the Docs, a documentation theme for Jekyll. 
 
 
 
 
 
   
 
 
 
 
  
 
  1/CLIENT 
 
 
Version: 0.3
 
Status: Stable
 
Authors: Adam Babik adam@status.im, Andrea Maria Piana andreap@status.im, Dean Eigenmann dean@status.im, Corey Petty corey@status.im, Oskar Thorén oskar@status.im, Samuel Hawksby-Robinson samuel@status.im (alphabetical order)
 
 
  Abstract 
 
This specification describes how to write a Status client for communicating with other Status clients.
 
This specification presents a reference implementation of the protocol 1 that is used in a command line client 2 and a mobile app 3.
 
This document consists of two parts. The first outlines the specifications that have to be implemented in order to be a full Status client. The second gives a design rationale and answers some common questions.
 
  Table of Contents 
  
  Introduction 
 
  Protocol layers 
 
Implementing a Status clients largely means implementing the following layers. Additionally, there are separate specifications for things like key management and account lifecycle.
 
Other aspects, such as how a node uses IPFS for stickers or how the browser works, are currently underspecified. These specifications facilitate the implementation of a Status client for basic private communication.
 
  
 Layer Purpose Technology 
   
 Data and payloads End user functionality 1:1, group chat, public chat 
 
 Data sync Data consistency MVDS. 
 
 Secure transport Confidentiality, PFS, etc Double Ratchet 
 
 Transport privacy Routing, Metadata protection Waku / Whisper 
 
 P2P Overlay Overlay routing, NAT traversal devp2p 
  
 
  Protobuf 
 
protobuf is used in different layers, version proto3 used is unless stated otherwise.
 
  Components 
 
  P2P Overlay 
 
Status clients run on a public, permissionless peer-to-peer network, as specified by the devP2P network protocols. devP2P provides a protocol for node discovery which is in draft mode here. See more on node discovery and management in the next section.
 
To communicate between Status nodes, the RLPx Transport Protocol, v5 is used, which allows for TCP-based communication between nodes.
 
On top of this RLPx-based subprotocols are ran, the client SHOULD NOT use Whisper V6, the client SHOULD use Waku V1 for privacy-preserving messaging and efficient usage of a node’s bandwidth.
 
  Node discovery and roles 
 
There are four types of node roles:
 
     
  1. Bootstrap node
    2.  
  2. Whisper/Waku relayer
    3.  
  3. Mailserver (servers and clients)
    4.  
  4. Mobile node (Status Clients)
    5.  
 
A standard Status client MUST implement both Whisper/Waku relayer and Mobile node node types. The other node types are optional, but it is RECOMMEND to implement a Mailserver client mode, otherwise the user experience is likely to be poor.
 
  Bootstrapping 
 
Bootstrap nodes allow Status nodes to discover and connect to other Status nodes in the network.
 
Currently, Status Gmbh provides the main bootstrap nodes, but anyone can run these provided they are connected to the rest of the Whisper/Waku network.
 
Status maintains a list of production fleet bootstrap nodes in the following locations:
 
Hong Kong:
 
     
  • enode://6e6554fb3034b211398fcd0f0082cbb6bd13619e1a7e76ba66e1809aaa0c5f1ac53c9ae79cf2fd4a7bacb10d12010899b370c75fed19b991d9c0cdd02891abad@47.75.99.169:443
    •  
  • enode://23d0740b11919358625d79d4cac7d50a34d79e9c69e16831c5c70573757a1f5d7d884510bc595d7ee4da3c1508adf87bbc9e9260d804ef03f8c1e37f2fb2fc69@47.52.106.107:443
    •  
 
Amsterdam:
 
     
  • enode://436cc6f674928fdc9a9f7990f2944002b685d1c37f025c1be425185b5b1f0900feaf1ccc2a6130268f9901be4a7d252f37302c8335a2c1a62736e9232691cc3a@178.128.138.128:443
    •  
  • enode://5395aab7833f1ecb671b59bf0521cf20224fe8162fc3d2675de4ee4d5636a75ec32d13268fc184df8d1ddfa803943906882da62a4df42d4fccf6d17808156a87@178.128.140.188:443
    •  
 
Central US:
 
     
  • enode://32ff6d88760b0947a3dee54ceff4d8d7f0b4c023c6dad34568615fcae89e26cc2753f28f12485a4116c977be937a72665116596265aa0736b53d46b27446296a@34.70.75.208:443
    •  
  • enode://5405c509df683c962e7c9470b251bb679dd6978f82d5b469f1f6c64d11d50fbd5dd9f7801c6ad51f3b20a5f6c7ffe248cc9ab223f8bcbaeaf14bb1c0ef295fd0@35.223.215.156:443
    •  
 
These bootstrap nodes MAY change and are not guaranteed to stay this way forever and at some point circumstances might force them to change.
 
  Discovery 
 
A Status client MUST discover or have a list of peers to connect to. Status uses a light discovery mechanism based on a combination of Discovery v5 and Rendezvous Protocol, (with some modifications). Additionally, some static nodes MAY also be used.
 
A Status client MUST use at least one discovery method or use static nodes to communicate with other clients.
 
Discovery V5 uses bootstrap nodes to discover other peers. Bootstrap nodes MUST support Discovery V5 protocol as well in order to provide peers. It is kademlia-based discovery mechanism and it might consume significant (at least on mobile) amount of network traffic to operate.
 
In order to take advantage from simpler and more mobile-friendly peers discovery mechanism, i.e. Rendezvous protocol, one MUST provide a list of Rendezvous nodes which speak Rendezvous protocol. Rendezvous protocol is request-response discovery mechanism. It uses Ethereum Node Records (ENR) to report discovered peers.
 
Both peers discovery mechanisms use topics to provide peers with certain capabilities. There is no point in returning peers that do not support a particular protocol. Status nodes that want to be discovered MUST register to Discovery V5 and/or Rendezvous with the whisper topic. Status nodes that are Mailservers and want to be discoverable MUST additionally register with the whispermail topic.
 
It is RECOMMENDED to use both mechanisms but at the same time implement a structure called PeerPool. PeerPool is responsible for maintaining an optimal number of peers. For mobile nodes, there is no significant advantage to have more than 2-3 peers and one Mailserver. PeerPool can notify peers discovery protocol implementations that they should suspend their execution because the optimal number of peers is found. They should resume if the number of connected peers drops or a Mailserver disconnects.
 
It is worth noticing that an efficient caching strategy MAY be of great use, especially, on mobile devices. Discovered peers can be cached as they rarely change and used when the client starts again. In such a case, there might be no need to even start peers discovery protocols because cached peers will satisfy the optimal number of peers.
 
Alternatively, a client MAY rely exclusively on a list of static peers. This is the most efficient way because there are no peers discovery algorithm overhead introduced. The disadvantage is that these peers might be gone and without peers discovery mechanism, it won’t be possible to find new ones.
 
The current list of static peers is published on https://fleets.status.im/. eth.prod is the current group of peers the official Status client uses. The others are test networks.
 
Finally, Waku node addresses can be retrieved by traversing the merkle tree found at fleets.status.im, as described in EIP-1459.
 
  Mobile nodes 
 
A Mobile node is a Whisper and/or Waku node which connects to part of the respective Whisper and/or Waku network(s). A Mobile node MAY relay messages. See next section for more details on how to use Whisper and/or Waku to communicate with other Status nodes.
 
  Transport privacy and Whisper / Waku usage 
 
Once a Whisper and/or Waku node is up and running there are some specific settings required to communicate with other Status nodes.
 
See 3/WHISPER-USAGE and 10/WAKU-USAGE for more details.
 
For providing an offline inbox, see the complementary 4/WHISPER-MAILSERVER and 11/WAKU-MAILSERVER.
 
  Secure Transport 
 
In order to provide confidentiality, integrity, authentication and forward secrecy of messages the node implements a secure transport on top of Whisper and Waku. This is used in 1:1 chats and group chats, but not for public chats. See 5/SECURE-TRANSPORT for more.
 
  Data Sync 
 
MVDS is used for 1:1 and group chats, however it is currently not in use for public chats. Status payloads are serialized and then wrapped inside an MVDS message which is added to an MVDS payload, the node encrypts this payload (if necessary for 1-to-1 / group-chats) and sends it using Whisper or Waku which also encrypts it.
 
  Payloads and clients 
 
On top of secure transport, various types of data sync clients and the node uses payload formats for things like 1:1 chat, group chat and public chat. These have various degrees of standardization. Please refer to 6/PAYLOADS for more details.
 
  BIPs and EIPs Standards support 
 
For a list of EIPs and BIPs that SHOULD be supported by Status client, please see 8/EIPS.
 
  Security Considerations 
 
See Appendix A
 
  Design Rationale 
 
  P2P Overlay 
 
  Why devp2p? Why not use libp2p? 
 
At the time Status developed the main Status clients, devp2p was the most mature. However, in the future libp2p is likely to be used, as it’ll provide us with multiple transports, better protocol negotiation, NAT traversal, etc.
 
For very experimental bridge support, see the bridge between libp2p and devp2p in Murmur.
 
  What about other RLPx subprotocols like LES, and Swarm? 
 
Status is primarily optimized for resource restricted devices, and at present time light client support for these protocols are suboptimal. This is a work in progress.
 
For better Ethereum light client support, see Re-enable LES as option. For better Swarm support, see Swarm adaptive nodes.
 
For transaction support, Status clients currently have to rely on Infura.
 
Status clients currently do not offer native support for file storage.
 
  Why do you use Whisper? 
 
Whisper is one of the three parts of the vision of Ethereum as the world computer, Ethereum and Swarm being the other two. Status was started as an encapsulation of and a clear window to this world computer.
 
  Why do you use Waku? 
 
Waku is a direct upgrade and replacement for Whisper, the main motivation for developing and implementing Waku can be found in the Waku specs.
 
 
Waku was created to incrementally improve in areas that Whisper is lacking in, with special attention to resource restricted devices. We specify the standard for Waku messages in order to ensure forward compatibility of different Waku clients, backwards compatibility with Whisper clients, as well as to allow multiple implementations of Waku and its capabilities. We also modify the language to be more unambiguous, concise and consistent.
 
 
Considerable work has gone into the active development of Ethereum, in contrast Whisper is not currently under active development, and it has several drawbacks. Among others:
 
     
  • Whisper is very wasteful bandwidth-wise and doesn’t appear to be scalable
    •  
  • Proof of work is a poor spam protection mechanism for heterogeneous devices
    •  
  • The privacy guarantees provided are not rigorous
    •  
  • There are no incentives to run a node
    •  
 
Finding a more suitable transport privacy is an ongoing research effort, together with Vac and other teams in the space.
 
  Why is PoW for Waku set so low? 
 
A higher PoW would be desirable, but this kills the battery on mobile phones, which is a prime target for Status clients.
 
This means the network is currently vulnerable to DDoS attacks. Alternative methods of spam protection are currently being researched.
 
  Why do you not use Discovery v5 for node discovery? 
 
At the time of implementing dynamic node discovery, Discovery v5 wasn’t completed yet. Additionally, running a DHT on a mobile leads to slow node discovery, bad battery and poor bandwidth usage. Instead, each client can choose to turn on Discovery v5 for a short period until the node populates their peer list.
 
For some further investigation, see here.
 
  I heard something about Mailservers being trusted somehow? 
 
In order to use a Mailserver, a given node needs to connect to it directly, i.e. add the Mailserver as its peer and mark it as trusted. This means that the Mailserver is able to send direct p2p messages to the node instead of broadcasting them. Effectively, it knows the bloom filter of the topics the node is interested in, when it is online as well as many metadata like IP address.
 
  Data sync 
 
  Why is MVDS not used for public chats? 
 
Currently, public chats are broadcast-based, and there’s no direct way of finding out who is receiving messages. Hence there’s no clear group sync state context whereby participants can sync. Additionally, MVDS is currently not optimized for large group contexts, which means bandwidth usage will be a lot higher than reasonable. See P2P Data Sync for Mobile for more. This is an active area of research.
 
  Footnotes 
 
     
  1. https://github.com/status-im/status-protocol-go/
    2.  
  2. https://github.com/status-im/status-console-client/
    3.  
  3. https://github.com/status-im/status-mobile/
    4.  
 
  Appendix A: Security considerations 
 
There are several security considerations to take into account when running Status. Chief among them are: scalability, DDoS-resistance and privacy. These also vary depending on what capabilities are used, such as Mailserver, light node, and so on.
 
  Scalability and UX 
 
Bandwidth usage:
 
In version 1 of Status, bandwidth usage is likely to be an issue. In Status version 1.1 this is partially addressed with Waku usage, see the theoretical scaling model.
 
Mailserver High Availability requirement:
 
A Mailserver has to be online to receive messages for other nodes, this puts a high availability requirement on it.
 
Gossip-based routing:
 
Use of gossip-based routing doesn’t necessarily scale. It means each node can see a message multiple times, and having too many light nodes can cause propagation probability that is too low. See Whisper vs PSS for more and a possible Kademlia based alternative.
 
Lack of incentives:
 
Status currently lacks incentives to run nodes, which means node operators are more likely to create centralized choke points.
 
  Privacy 
 
Light node privacy:
 
The main privacy concern with light nodes is that directly connected peers will know that a message originates from them (as it are the only ones it sends). This means nodes can make assumptions about what messages (topics) their peers are interested in.
 
Bloom filter privacy:
 
A user reveals which messages they are interested in, by setting only the topics they are interested in on the bloom filter. This is a fundamental trade-off between bandwidth usage and privacy, though the trade-off space is likely suboptimal in terms of the Anonymity trilemma.
 
Mailserver client privacy:
 
A Mailserver client has to trust a Mailserver, which means they can send direct traffic. This reveals what topics / bloom filter a node is interested in, along with its peerID (with IP).
 
Privacy guarantees not rigorous:
 
Privacy for Whisper or Waku hasn’t been studied rigorously for various threat models like global passive adversary, local active attacker, etc. This is unlike e.g. Tor and mixnets.
 
Topic hygiene:
 
Similar to bloom filter privacy, using a very specific topic reveals more information. See scalability model linked above.
 
  Spam resistance 
 
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.
 
Mailserver trusted connection:
 
A Mailserver has a direct TCP connection, which means they are trusted to send traffic. This means a malicious or malfunctioning Mailserver can overwhelm an individual node.
 
  Censorship resistance 
 
Devp2p TCP port blockable:
 
By default Devp2p runs on port 30303, which is not commonly used for any other service. This means it is easy to censor, e.g. airport WiFi. This can be mitigated somewhat by running on e.g. port 80 or 443, but there are still outstanding issues. See libp2p and Tor’s Pluggable Transport for how this can be improved.
 
See https://github.com/status-im/status-mobile/issues/6351 for some discussion.
 
  Acknowledgments 
 
Jacek Sieka
 
  Changelog 
 
  Version 0.3 
 
Released May 22, 2020
 
     
  • Added that Waku SHOULD be used
    •  
  • Added that Whisper SHOULD NOT be used
    •  
  • Added language to include Waku in all relevant places
    •  
  • Change to keep Mailserver term consistent
    •  
  
Copyright and related rights waived via CC0.
 
 
 
 
  
diff --git a/spec/2.html b/spec/2.html
index ba32943..2b2dcc2 100644
--- a/spec/2.html
+++ b/spec/2.html
@@ -1,11 +1,11 @@
-     2/ACCOUNT - Status Specification       2/ACCOUNT | Status Specification               Link      Search      Menu      Expand      Document      
 
  Status Specification     
  
 This site uses Just the Docs, a documentation theme for Jekyll. 
 
 
 
 
 
   
 
 
 
 
  
 
  2/ACCOUNT 
 
 
Version: 0.4
 
Status: Stable
 
Authors: Corey Petty corey@status.im, Oskar Thorén oskar@status.im, Samuel Hawksby-Robinson samuel@status.im (alphabetical order)
 
 
  Abstract 
 
This specification explains what Status account is, and how a node establishes trust.
 
  Table of Contents 
   
  Introduction 
 
The core concept of an account in Status is a set of cryptographic keypairs. Namely, the combination of the following:
 
     
  1. a Whisper/Waku chat identity keypair
    2.  
  2. a set of cryptocurrency wallet keypairs
    3.  
 
The node verifies or derives everything else associated with the contact from the above items, including:
 
     
  • Ethereum address (future verification, currently the same base keypair)
    •  
  • 3 word mnemonic name
    •  
  • identicon
    •  
  • message signatures
    •  
 
  Initial Key Generation 
 
  Public/Private Keypairs 
 
     
  • An ECDSA (secp256k1 curve) public/private keypair MUST be generated via a BIP43 derived path from a BIP39 mnemonic seed phrase.
    •  
  • The default paths are defined as such: 
       
    • Whisper/Waku Chat Key (IK): m/43'/60'/1581'/0'/0 (post Multiaccount integration)  
      •  
    • Status Wallet paths: m/44'/60'/0'/0/i starting at i=0 
         
      • following BIP44
        •  
      • NOTE: this (i=0) is also the current (and only) path for Whisper/Waku key before Multiaccount integration
        •  
       
      •  
     
    •  
 
  X3DH Prekey bundle creation 
 
     
  • Status follows the X3DH prekey bundle scheme that Open Whisper Systems (not to be confused with the Whisper sub-protocol) outlines in their documentation with the following exceptions: 
       
    • Status does not publish one-time keys OPK or perform DH including them, because there are no central servers in the Status implementation.
      •  
     
    •  
  • A client MUST create X3DH prekey bundles, each defined by the following items: 
       
    • Identity Key: IK
      •  
    • Signed prekey: SPK
      •  
    • Prekey signature: Sig(IK, Encode(SPK))
      •  
    • Timestamp
      •  
     
    •  
  • These bundles are made available in a variety of ways, as defined in section 2.1.
    •  
 
  Account Broadcasting 
 
     
  • A user is responsible for broadcasting certain information publicly so that others may contact them.
    •  
 
  X3DH Prekey bundles 
 
     
  • 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/Waku 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: retrieval of long-time offline users bundle via {IK}-contact-code
    •  
 
  Optional Account additions 
 
  ENS Username 
 
     
  • 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/Waku identity key (IK).
    •  
    
  Trust establishment 
 
Trust establishment deals with users verifying they are communicating with who they think they are.
 
  Terms Glossary 
 
  
 term description 
   
 privkey ECDSA secp256k1 private key 
 
 pubkey ECDSA secp256k1 public key 
 
 Whisper/Waku key pubkey for chat with HD derivation path m/43’/60’/1581’/0’/0 
  
 
  Contact Discovery 
 
  Public channels 
 
     
  • 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’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.
    •  
  • Discovery of channel names is not currently part of the protocol, and is typically done out of band. If a channel name is used that has not been used, it will be created.
    •  
  • A client MUST sign the message otherwise it will be discarded by the recipients.
    •  
  • channel name specification: 
       
    • matches [a-z0-9\-]
      •  
    • is not a public key
      •  
     
    •  
 
  Private 1:1 messages 
 
This can be done in the following ways:
 
     
  1. scanning a user generated QR code
    2.  
  2. discovery through the Status app
    3.  
  3. asynchronous X3DH key exchange
    4.  
  4. public key via public channel listening 
       
    • status-react/src/status_im/contact_code/core.cljs
      •  
     
    5.  
  5. contact codes
    6.  
  6. decentralized storage (not implemented)
    7.  
  7. Whisper/Waku
    8.  
 
  Initial Key Exchange 
 
  Bundles 
 
     
  • An X3DH prekey bundle is defined as (code): 
    Identity                // Identity key
+     2/ACCOUNT - Status Specification       2/ACCOUNT | Status Specification               Link      Search      Menu      Expand      Document      
     
      Status Specification     
      
     This site uses Just the Docs, a documentation theme for Jekyll. 
     
     
     
     
     
       
     
     
     
     
      
     
      2/ACCOUNT 
     
     
    Version: 0.4
     
    Status: Stable
     
    Authors: Corey Petty corey@status.im, Oskar Thorén oskar@status.im, Samuel Hawksby-Robinson samuel@status.im (alphabetical order)
     
     
      Abstract 
     
    This specification explains what Status account is, and how a node establishes trust.
     
      Table of Contents 
       
      Introduction 
     
    The core concept of an account in Status is a set of cryptographic keypairs. Namely, the combination of the following:
     
       
    1. a Whisper/Waku chat identity keypair
      2.  
    2. a set of cryptocurrency wallet keypairs
      3.  
     
    The node verifies or derives everything else associated with the contact from the above items, including:
     
       
    • Ethereum address (future verification, currently the same base keypair)
      •  
    • 3 word mnemonic name
      •  
    • identicon
      •  
    • message signatures
      •  
     
      Initial Key Generation 
     
      Public/Private Keypairs 
     
       
    • An ECDSA (secp256k1 curve) public/private keypair MUST be generated via a BIP43 derived path from a BIP39 mnemonic seed phrase.
      •  
    • The default paths are defined as such: 
         
      • Whisper/Waku Chat Key (IK): m/43'/60'/1581'/0'/0 (post Multiaccount integration)  
        •  
      • Status Wallet paths: m/44'/60'/0'/0/i starting at i=0 
           
        • following BIP44
          •  
        • NOTE: this (i=0) is also the current (and only) path for Whisper/Waku key before Multiaccount integration
          •  
         
        •  
       
      •  
     
      X3DH Prekey bundle creation 
     
       
    • Status follows the X3DH prekey bundle scheme that Open Whisper Systems (not to be confused with the Whisper sub-protocol) outlines in their documentation with the following exceptions: 
         
      • Status does not publish one-time keys OPK or perform DH including them, because there are no central servers in the Status implementation.
        •  
       
      •  
    • A client MUST create X3DH prekey bundles, each defined by the following items: 
         
      • Identity Key: IK
        •  
      • Signed prekey: SPK
        •  
      • Prekey signature: Sig(IK, Encode(SPK))
        •  
      • Timestamp
        •  
       
      •  
    • These bundles are made available in a variety of ways, as defined in section 2.1.
      •  
     
      Account Broadcasting 
     
       
    • A user is responsible for broadcasting certain information publicly so that others may contact them.
      •  
     
      X3DH Prekey bundles 
     
       
    • 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/Waku 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: retrieval of long-time offline users bundle via {IK}-contact-code
      •  
     
      Optional Account additions 
     
      ENS Username 
     
       
    • 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/Waku identity key (IK).
      •  
        
      Trust establishment 
     
    Trust establishment deals with users verifying they are communicating with who they think they are.
     
      Terms Glossary 
     
      
     term description 
           
     privkey ECDSA secp256k1 private key 
     
     pubkey ECDSA secp256k1 public key 
     
     Whisper/Waku key pubkey for chat with HD derivation path m/43’/60’/1581’/0’/0 
          
     
      Contact Discovery 
     
      Public channels 
     
       
    • 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’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.
      •  
    • Discovery of channel names is not currently part of the protocol, and is typically done out of band. If a channel name is used that has not been used, it will be created.
      •  
    • A client MUST sign the message otherwise it will be discarded by the recipients.
      •  
    • channel name specification: 
         
      • matches [a-z0-9\-]
        •  
      • is not a public key
        •  
       
      •  
     
      Private 1:1 messages 
     
    This can be done in the following ways:
     
       
    1. scanning a user generated QR code
      2.  
    2. discovery through the Status app
      3.  
    3. asynchronous X3DH key exchange
      4.  
    4. public key via public channel listening 
         
      • status-mobile/src/status_im/contact_code/core.cljs
        •  
       
      5.  
    5. contact codes
      6.  
    6. decentralized storage (not implemented)
      7.  
    7. Whisper/Waku
      8.  
     
      Initial Key Exchange 
     
      Bundles 
     
       
    • An X3DH prekey bundle is defined as (code): 
      Identity                // Identity key
 SignedPreKeys           // a map of installation id to array of signed prekeys by that installation id
 Signature               // Prekey signature
 Timestamp               // When the bundle was lasted created locally
-
       
       
         
      • include BundleContainer
        •  
       
      •  
    • a new bundle SHOULD be created at least every 12 hours
      •  
    • a node only generates a bundle when it is used
      •  
    • a bundle SHOULD be distributed on the contact code channel. This is the Whisper and Waku topic {IK}-contact-code, where IK is the hex encoded public key of the user, prefixed with 0x. The node encrypts the channel in the same way it encrypted public chats.
      •  
     
      Contact Verification 
     
    To verify that contact key information is as it should be, use the following.
     
      Identicon 
     
    A low-poly identicon is deterministically generated from the Whisper/Waku chat public key. This can be compared out of band to ensure the receiver’s public key is the one stored locally.
     
      3 word pseudonym / Whisper/Waku key fingerprint 
     
    Status generates a deterministic 3-word random pseudonym from the Whisper/Waku chat public key. This pseudonym acts as a human readable fingerprint to the Whisper/Waku chat public key. This name also shows when viewing a contact’s public profile and in the chat UI.
      
      ENS name 
     
    Status offers the ability to register a mapping of a human readable subdomain of stateofus.eth to their Whisper/Waku chat public key. The user purchases this registration (currently by staking 10 SNT) and the node stores it on the Ethereum mainnet blockchain for public lookup.
       
      Public Key Serialization 
     
    Idiomatically known as “public key compression” and “public key decompression”.
     
    The node SHOULD provide functionality for the serialization and deserialization of public / chat keys.
     
    For maximum flexibility, when implementing this functionality, the node MUST support public keys encoded in a range of encoding formats, detailed below.
     
      Basic Serialization Example 
     
    In the example of a typical hexadecimal encoded elliptical curve (EC) public key (such as a secp256k1 pk),
     
    0x04261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6
+
     
     
       
    • include BundleContainer
      •  
     
    •  
  • a new bundle SHOULD be created at least every 12 hours
    •  
  • a node only generates a bundle when it is used
    •  
  • a bundle SHOULD be distributed on the contact code channel. This is the Whisper and Waku topic {IK}-contact-code, where IK is the hex encoded public key of the user, prefixed with 0x. The node encrypts the channel in the same way it encrypted public chats.
    •  
 
  Contact Verification 
 
To verify that contact key information is as it should be, use the following.
 
  Identicon 
 
A low-poly identicon is deterministically generated from the Whisper/Waku chat public key. This can be compared out of band to ensure the receiver’s public key is the one stored locally.
 
  3 word pseudonym / Whisper/Waku key fingerprint 
 
Status generates a deterministic 3-word random pseudonym from the Whisper/Waku chat public key. This pseudonym acts as a human readable fingerprint to the Whisper/Waku chat public key. This name also shows when viewing a contact’s public profile and in the chat UI.
  
  ENS name 
 
Status offers the ability to register a mapping of a human readable subdomain of stateofus.eth to their Whisper/Waku chat public key. The user purchases this registration (currently by staking 10 SNT) and the node stores it on the Ethereum mainnet blockchain for public lookup.
   
  Public Key Serialization 
 
Idiomatically known as “public key compression” and “public key decompression”.
 
The node SHOULD provide functionality for the serialization and deserialization of public / chat keys.
 
For maximum flexibility, when implementing this functionality, the node MUST support public keys encoded in a range of encoding formats, detailed below.
 
  Basic Serialization Example 
 
In the example of a typical hexadecimal encoded elliptical curve (EC) public key (such as a secp256k1 pk),
 
0x04261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6
 
 
minor modification for compatibility and flexibility makes the key self-identifiable and easily parsable,
 
fe70104261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6
 
 
EC serialization and compact encoding produces a much smaller string representation of the original key.
 
zQ3shPyZJnxZK4Bwyx9QsaksNKDYTPmpwPvGSjMYVHoXHeEgB
-
 
  Public Key “Compression” Rationale 
 
Serialized and compactly encoded (“compressed”) public keys have a number of UI / UX advantages over non-serialized less densely encoded public keys.
 
Compressed public keys are smaller, and users may perceive them as less intimidating and less unnecessarily large. Compare the “compressed” and “uncompressed” version of the same public key from above example:
 
     
  • 0xe70104261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6
    •  
  • zQ3shPyZJnxZK4Bwyx9QsaksNKDYTPmpwPvGSjMYVHoXHeEgB
    •  
 
The user can transmit and share the same data, but at one third of the original size. 136 characters uncompressed vs 49 characters compressed, giving a significant character length reduction of 64%.
 
The user client app MAY use the compressed public keys throughout the user interface. For example in the status-react implementation of the user interface the following places could take advantage of a significantly smaller public key:
 
     
  • Onboarding > Choose a chat name
    •  
  • Profile > Header
    •  
  • Profile > Share icon > QR code popover
    •  
  • Invite friends url from Invite friends button and + -button > Invite friends
    •  
  • Other user Profile details
    •  
  • Profile details > Share icon > QR code popover
    •  
 
In the case of QR codes a compressed public key can reduce the complexity of the derived codes:
 
  
 Uncompressed Compressed 
   
   
  
 
  Key Encoding 
 
When implementing the pk de/serialization functionality, the node MUST use the multiformats/multibase encoding protocol to interpret incoming key data and to return key data in a desired encoding.
 
The node SHOULD support the following multibase encoding formats.
encoding,          code, description,                                              status
+
 
  Public Key “Compression” Rationale 
 
Serialized and compactly encoded (“compressed”) public keys have a number of UI / UX advantages over non-serialized less densely encoded public keys.
 
Compressed public keys are smaller, and users may perceive them as less intimidating and less unnecessarily large. Compare the “compressed” and “uncompressed” version of the same public key from above example:
 
     
  • 0xe70104261c55675e55ff25edb50b345cfb3a3f35f60712d251cbaaab97bd50054c6ebc3cd4e22200c68daf7493e1f8da6a190a68a671e2d3977809612424c7c3888bc6
    •  
  • zQ3shPyZJnxZK4Bwyx9QsaksNKDYTPmpwPvGSjMYVHoXHeEgB
    •  
 
The user can transmit and share the same data, but at one third of the original size. 136 characters uncompressed vs 49 characters compressed, giving a significant character length reduction of 64%.
 
The user client app MAY use the compressed public keys throughout the user interface. For example in the status-mobile implementation of the user interface the following places could take advantage of a significantly smaller public key:
 
     
  • Onboarding > Choose a chat name
    •  
  • Profile > Header
    •  
  • Profile > Share icon > QR code popover
    •  
  • Invite friends url from Invite friends button and + -button > Invite friends
    •  
  • Other user Profile details
    •  
  • Profile details > Share icon > QR code popover
    •  
 
In the case of QR codes a compressed public key can reduce the complexity of the derived codes:
 
  
 Uncompressed Compressed 
   
   
  
 
  Key Encoding 
 
When implementing the pk de/serialization functionality, the node MUST use the multiformats/multibase encoding protocol to interpret incoming key data and to return key data in a desired encoding.
 
The node SHOULD support the following multibase encoding formats.
encoding,          code, description,                                              status
 identity,          0x00, 8-bit binary (encoder and decoder keeps data unmodified), default
 base2,             0,    binary (01010101),                                        candidate
 base8,             7,    octal,                                                    draft
diff --git a/spec/8.html b/spec/8.html
index faff276..62fd3c8 100644
--- a/spec/8.html
+++ b/spec/8.html
@@ -1 +1 @@
-     8/EIPS - Status Specification       8/EIPS | Status Specification               Link      Search      Menu      Expand      Document      
 
  Status Specification     
  
 This site uses Just the Docs, a documentation theme for Jekyll. 
 
 
 
 
 
   
 
 
 
 
  
 
  8/EIPS 
 
 
Version: 0.2
 
Status: Stable
 
Authors: Ricardo Guilherme Schmidt ricardo3@status.im
 
 
  Abstract 
 
This specification describes how Status relates with EIPs.
 
  Table of Contents 
  
  Introduction 
 
Status should follow all standards as possible. Whenever the Status app needs a feature, it should be first checked if there is a standard for that, if not, Status should propose a standard.
 
  Support table 
 
  
   Status v0 Status v1 Other State 
   
 BIP32 N Y N stable 
 
 BIP39 Y Y Y stable 
 
 BIP43 N Y N stable 
 
 BIP44 N Y N stable 
 
 EIP20 Y Y Y stable 
 
 EIP55 Y Y Y stable 
 
 EIP67 P P N stable 
 
 EIP137 P P N stable 
 
 EIP155 Y Y Y stable 
 
 EIP165 P N N stable 
 
 EIP181 P N N stable 
 
 EIP191 Y? N Y stable 
 
 EIP627 Y Y N stable 
 
 EIP681 Y N Y stable 
 
 EIP712 P P Y stable 
 
 EIP721 P P Y stable 
 
 EIP831 N Y N stable 
 
 EIP945 Y Y N stable 
 
 EIP1102 Y Y Y stable 
 
 EIP1193 Y Y Y stable 
 
 EIP1577 Y P N stable 
 
 EIP1581 N Y N stable 
 
 EIP1459 N   N raw 
  
 
  Components 
 
  BIP32 - Hierarchical Deterministic Wallets 
 
Support: Dependency.
 Reference: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
 Description: Enable wallets to derive multiple private keys from the same seed.
 Used for: Dependency of BIP39 and BIP43.
 
  BIP39 - Mnemonic code for generating deterministic keys 
 
Support: Dependency.
 Reference: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
 Description: Enable wallet to create private key based on a safe seed phrase. Used for: Security and user experience.
 
  BIP43 - Purpose Field for Deterministic Wallets 
 
Support: Dependency.
 Reference: https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
 Description: Enable wallet to create private keys branched for a specific purpose.
 Used for: Dependency of BIP44, uses “ethereum” coin.
 
  BIP44 - Multi-Account Hierarchy for Deterministic Wallets 
 
Support: Dependency.
 Reference: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
 Description: Enable wallet to derive multiple accounts in top of BIP39.
 Used for: Privacy.
 Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/constants.cljs#L240 
 Observation: BIP44 don’t solve privacy issues regarding the transparency of transactions, therefore directly connected addresses through a transactions can be identifiable by a “network reconnaissance attack” over transaction history, this attack together with leakage of information from centralized services, such as exchanges, would be fatal against the whole privacy of users, regardless of BIP44.
 
  EIP20 - Fungible Token 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-20
 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
 
  EIP55 - Mixed-case checksum address encoding 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-55
 Description: Checksum standard that uses lowercase and uppercase inside address hex value.
 Used for: Sanity check of forms using ethereum address.
 Related: https://github.com/status-im/status-react/issues/4959 https://github.com/status-im/status-react/issues/8707
 Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/eip55.cljs
 
  EIP67 - Standard URI scheme with metadata, value and byte code 
 
Support: Partial.
 Reference: https://github.com/ethereum/EIPs/issues/67
 Description: A standard way of creating Ethereum URIs for various use-cases.
 Used for: Legacy support.
 https://github.com/status-im/status-react/issues/875
 
  EIP137 - Ethereum Domain Name Service - Specification 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-137
 Description: Enable wallets to lookup ENS names.
 Used for: User experience, as a wallet and identity feature, usernames.
 Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/ens.cljs#L86
 
  EIP155 - Simple replay attack protection 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-155
 Description: Defined chainId parameter in the singed ethereum transaction payload.
 Used for: Signing transactions, crucial to safety of users against replay attacks.
 Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/core.cljs
 
  EIP165 - Standard Interface Detection 
 
Support: Dependency/Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-165
 Description: Standard interface for contract to answer if it supports other interfaces.
 Used for: Dependency of ENS and EIP721.
 Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/eip165.cljs
 
  EIP181 - ENS support for reverse resolution of Ethereum addresses 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-181
 Description: Enable wallets to render reverse resolution of Ethereum addresses.
 Used for: Wallet feature.
 Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/ethereum/ens.cljs#L86
 
  EIP191 - Signed Message 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-191
 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 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-627
 Description: format of Whisper messages within the ÐΞVp2p Wire Protocol.
 Used for: Chat protocol.
 
  EIP681 - URL Format for Transaction Requests 
 
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 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/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
 
  EIP712 - Typed Signed Message 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-712
 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
 
  EIP721 - Non Fungible Token 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-721
 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
 
  EIP945 - Web 3 QR Code Scanning API 
 
Support: Full.
 Reference: https://github.com/ethereum/EIPs/issues/945
 Used for: Sharing contactcode, reading transaction requests.
 Related: https://github.com/status-im/status-react/issues/5870
 
  EIP1102 - Opt-in account exposure 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-1102
 Description: Allow users to opt-in the exposure of their ethereum address to dapps they browse.
 Used for: Privacy, DApp support.
 Related: https://github.com/status-im/status-react/issues/7985
 
  EIP1193 - Ethereum Provider JavaScript API 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-1193
 Description: Allows dapps to recognize event changes on wallet.
 Used for: DApp support.
 Related: https://github.com/status-im/status-react/pull/7246
 
  EIP1577 - contenthash field for ENS 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-1577
 Description: Allows users browse ENS domains using contenthash standard.
 Used for: Browser, DApp support.
 Related: https://github.com/status-im/status-react/issues/6688
 Sourcecode: https://github.com/status-im/status-react/blob/develop/src/status_im/utils/contenthash.cljs https://github.com/status-im/status-react/blob/develop/test/cljs/status_im/test/utils/contenthash.cljs#L5
 
  EIP1581 - Non-wallet usage of keys derived from BIP-32 trees 
 
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 (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
 
  EIP1459 - Node Discovery via DNS 
 
Support: - Reference: https://eips.ethereum.org/EIPS/eip-1459 Description: Allows the storing and retrieving of nodes through merkle trees stored in TXT records of a domain. Used for: Finding Waku nodes. Related: - Sourcecode: -
  
Copyright and related rights waived via CC0.
 
 
 
 
  
+     8/EIPS - Status Specification       8/EIPS | Status Specification               Link      Search      Menu      Expand      Document      
 
  Status Specification     
  
 This site uses Just the Docs, a documentation theme for Jekyll. 
 
 
 
 
 
   
 
 
 
 
  
 
  8/EIPS 
 
 
Version: 0.2
 
Status: Stable
 
Authors: Ricardo Guilherme Schmidt ricardo3@status.im
 
 
  Abstract 
 
This specification describes how Status relates with EIPs.
 
  Table of Contents 
  
  Introduction 
 
Status should follow all standards as possible. Whenever the Status app needs a feature, it should be first checked if there is a standard for that, if not, Status should propose a standard.
 
  Support table 
 
  
   Status v0 Status v1 Other State 
   
 BIP32 N Y N stable 
 
 BIP39 Y Y Y stable 
 
 BIP43 N Y N stable 
 
 BIP44 N Y N stable 
 
 EIP20 Y Y Y stable 
 
 EIP55 Y Y Y stable 
 
 EIP67 P P N stable 
 
 EIP137 P P N stable 
 
 EIP155 Y Y Y stable 
 
 EIP165 P N N stable 
 
 EIP181 P N N stable 
 
 EIP191 Y? N Y stable 
 
 EIP627 Y Y N stable 
 
 EIP681 Y N Y stable 
 
 EIP712 P P Y stable 
 
 EIP721 P P Y stable 
 
 EIP831 N Y N stable 
 
 EIP945 Y Y N stable 
 
 EIP1102 Y Y Y stable 
 
 EIP1193 Y Y Y stable 
 
 EIP1577 Y P N stable 
 
 EIP1581 N Y N stable 
 
 EIP1459 N   N raw 
  
 
  Components 
 
  BIP32 - Hierarchical Deterministic Wallets 
 
Support: Dependency.
 Reference: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
 Description: Enable wallets to derive multiple private keys from the same seed.
 Used for: Dependency of BIP39 and BIP43.
 
  BIP39 - Mnemonic code for generating deterministic keys 
 
Support: Dependency.
 Reference: https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
 Description: Enable wallet to create private key based on a safe seed phrase. Used for: Security and user experience.
 
  BIP43 - Purpose Field for Deterministic Wallets 
 
Support: Dependency.
 Reference: https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki
 Description: Enable wallet to create private keys branched for a specific purpose.
 Used for: Dependency of BIP44, uses “ethereum” coin.
 
  BIP44 - Multi-Account Hierarchy for Deterministic Wallets 
 
Support: Dependency.
 Reference: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
 Description: Enable wallet to derive multiple accounts in top of BIP39.
 Used for: Privacy.
 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/constants.cljs#L240 
 Observation: BIP44 don’t solve privacy issues regarding the transparency of transactions, therefore directly connected addresses through a transactions can be identifiable by a “network reconnaissance attack” over transaction history, this attack together with leakage of information from centralized services, such as exchanges, would be fatal against the whole privacy of users, regardless of BIP44.
 
  EIP20 - Fungible Token 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-20
 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-mobile/blob/develop/src/status_im/ethereum/tokens.cljs
 
  EIP55 - Mixed-case checksum address encoding 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-55
 Description: Checksum standard that uses lowercase and uppercase inside address hex value.
 Used for: Sanity check of forms using ethereum address.
 Related: https://github.com/status-im/status-mobile/issues/4959 https://github.com/status-im/status-mobile/issues/8707
 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/eip55.cljs
 
  EIP67 - Standard URI scheme with metadata, value and byte code 
 
Support: Partial.
 Reference: https://github.com/ethereum/EIPs/issues/67
 Description: A standard way of creating Ethereum URIs for various use-cases.
 Used for: Legacy support.
 https://github.com/status-im/status-mobile/issues/875
 
  EIP137 - Ethereum Domain Name Service - Specification 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-137
 Description: Enable wallets to lookup ENS names.
 Used for: User experience, as a wallet and identity feature, usernames.
 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/ens.cljs#L86
 
  EIP155 - Simple replay attack protection 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-155
 Description: Defined chainId parameter in the singed ethereum transaction payload.
 Used for: Signing transactions, crucial to safety of users against replay attacks.
 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/core.cljs
 
  EIP165 - Standard Interface Detection 
 
Support: Dependency/Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-165
 Description: Standard interface for contract to answer if it supports other interfaces.
 Used for: Dependency of ENS and EIP721.
 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/eip165.cljs
 
  EIP181 - ENS support for reverse resolution of Ethereum addresses 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-181
 Description: Enable wallets to render reverse resolution of Ethereum addresses.
 Used for: Wallet feature.
 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/ens.cljs#L86
 
  EIP191 - Signed Message 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-191
 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 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-627
 Description: format of Whisper messages within the ÐΞVp2p Wire Protocol.
 Used for: Chat protocol.
 
  EIP681 - URL Format for Transaction Requests 
 
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 QR code data for transaction requests, chat transaction requests and for dapp links to transaction requests.
 Sourcecode: https://github.com/status-im/status-mobile/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-mobile/pull/9240 https://github.com/status-im/status-mobile/issues/9238 https://github.com/status-im/status-mobile/issues/7214 https://github.com/status-im/status-mobile/issues/7325 https://github.com/status-im/status-mobile/issues/8150
 
  EIP712 - Typed Signed Message 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-712
 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-mobile/issues/5461 https://github.com/status-im/status-mobile/commit/ba37f7b8d029d3358c7b284f6a2383b9ef9526c9
 
  EIP721 - Non Fungible Token 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-721
 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-mobile/issues/8909
 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/erc721.cljs https://github.com/status-im/status-mobile/blob/develop/src/status_im/ethereum/tokens.cljs
 
  EIP945 - Web 3 QR Code Scanning API 
 
Support: Full.
 Reference: https://github.com/ethereum/EIPs/issues/945
 Used for: Sharing contactcode, reading transaction requests.
 Related: https://github.com/status-im/status-mobile/issues/5870
 
  EIP1102 - Opt-in account exposure 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-1102
 Description: Allow users to opt-in the exposure of their ethereum address to dapps they browse.
 Used for: Privacy, DApp support.
 Related: https://github.com/status-im/status-mobile/issues/7985
 
  EIP1193 - Ethereum Provider JavaScript API 
 
Support: Full.
 Reference: https://eips.ethereum.org/EIPS/eip-1193
 Description: Allows dapps to recognize event changes on wallet.
 Used for: DApp support.
 Related: https://github.com/status-im/status-mobile/pull/7246
 
  EIP1577 - contenthash field for ENS 
 
Support: Partial.
 Reference: https://eips.ethereum.org/EIPS/eip-1577
 Description: Allows users browse ENS domains using contenthash standard.
 Used for: Browser, DApp support.
 Related: https://github.com/status-im/status-mobile/issues/6688
 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/utils/contenthash.cljs https://github.com/status-im/status-mobile/blob/develop/test/cljs/status_im/test/utils/contenthash.cljs#L5
 
  EIP1581 - Non-wallet usage of keys derived from BIP-32 trees 
 
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 (don’t reuse wallet key) and user experience (don’t request keycard every login).
 Related: https://github.com/status-im/status-mobile/issues/9088 https://github.com/status-im/status-mobile/pull/9096
 Sourcecode: https://github.com/status-im/status-mobile/blob/develop/src/status_im/constants.cljs#L242
 
  EIP1459 - Node Discovery via DNS 
 
Support: - Reference: https://eips.ethereum.org/EIPS/eip-1459 Description: Allows the storing and retrieving of nodes through merkle trees stored in TXT records of a domain. Used for: Finding Waku nodes. Related: - Sourcecode: -
  
Copyright and related rights waived via CC0.
 
 
 
 
  
diff --git a/spec/9.html b/spec/9.html
index 8d69f5f..09c980f 100644
--- a/spec/9.html
+++ b/spec/9.html
@@ -2,7 +2,7 @@
 
 
https://github.com/ethereum/go-ethereum/blob/26d271dfbba1367326dec38068f9df828d462c61/ethclient/ethclient.go#L499
 
  PendingNonceAt 
 
PendingNonceAt returns the account nonce of the given account in the pending state. This is the nonce that should be used for the next transaction.
 
func (ec *Client) PendingNonceAt(ctx context.Context, account common.Address) (uint64, error)
 
 
https://github.com/ethereum/go-ethereum/blob/26d271dfbba1367326dec38068f9df828d462c61/ethclient/ethclient.go#L440
 
  SuggestGasPrice 
 
SuggestGasPrice retrieves the currently suggested gas price to allow a timely execution of a transaction.
 
func (ec *Client) SuggestGasPrice(ctx context.Context) (*big.Int, error)
 
 
https://github.com/ethereum/go-ethereum/blob/26d271dfbba1367326dec38068f9df828d462c61/ethclient/ethclient.go#L487
 
  SendTransaction 
 
SendTransaction injects a signed transaction into the pending pool for execution.
 
If the transaction was a contract creation use the TransactionReceipt method to get the contract address after the transaction has been mined.
 
func (ec *Client) SendTransaction(ctx context.Context, tx *types.Transaction) error 
-
 
https://github.com/ethereum/go-ethereum/blob/26d271dfbba1367326dec38068f9df828d462c61/ethclient/ethclient.go#L512
 
  Fetching balance 
 
A Status node fetches the current and historical [ECR20] (https://eips.ethereum.org/EIPS/eip-20) and ETH balance for the user wallet address. Collectibles following the ECR-721 are also fetched if enabled.
 
A Status node supports by default the following tokens. Custom tokens can be added by specifying the address, symbol and decimals.
 
  BlockByHash 
 
BlockByHash returns the given full block.
 
It is used by status to fetch a given block which will then be inspected for transfers to the user address, both tokens and ETH.
 
func (ec *Client) BlockByHash(ctx context.Context, hash common.Hash) (*types.Block, error)
+
 
https://github.com/ethereum/go-ethereum/blob/26d271dfbba1367326dec38068f9df828d462c61/ethclient/ethclient.go#L512
 
  Fetching balance 
 
A Status node fetches the current and historical [ECR20] (https://eips.ethereum.org/EIPS/eip-20) and ETH balance for the user wallet address. Collectibles following the ECR-721 are also fetched if enabled.
 
A Status node supports by default the following tokens. Custom tokens can be added by specifying the address, symbol and decimals.
 
  BlockByHash 
 
BlockByHash returns the given full block.
 
It is used by status to fetch a given block which will then be inspected for transfers to the user address, both tokens and ETH.
 
func (ec *Client) BlockByHash(ctx context.Context, hash common.Hash) (*types.Block, error)
 
 
https://github.com/ethereum/go-ethereum/blob/26d271dfbba1367326dec38068f9df828d462c61/ethclient/ethclient.go#L78
 
  BlockByNumber 
 
BlockByNumber returns a block from the current canonical chain. If number is nil, the latest known block is returned.
 
func (ec *Client) BlockByNumber(ctx context.Context, number *big.Int) (*types.Block, error)
 
 
https://github.com/ethereum/go-ethereum/blob/26d271dfbba1367326dec38068f9df828d462c61/ethclient/ethclient.go#L82
 
  FilterLogs 
 
FilterLogs executes a filter query.
 
Status uses this function to filter out logs, using the hash of the block and the address of interest, both inbound and outbound.
 
func (ec *Client) FilterLogs(ctx context.Context, q ethereum.FilterQuery) ([]types.Log, error) 
 
 
https://github.com/ethereum/go-ethereum/blob/26d271dfbba1367326dec38068f9df828d462c61/ethclient/ethclient.go#L377
 
  NonceAt 
 
NonceAt returns the account nonce of the given account.
 
func (ec *Client) NonceAt(ctx context.Context, account common.Address, blockNumber *big.Int) (uint64, error)