Document not found (404)
+This URL is invalid, sorry. Please use the navigation bar or search to continue.
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/about/FAQ.html b/about/FAQ.html
new file mode 100644
index 0000000000..bc2d19fe70
--- /dev/null
+++ b/about/FAQ.html
@@ -0,0 +1,296 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Changelog
+5.0.1
+Android version release, minor fixes
+New in version 5.0.0
+Architecture
+No more typescript or react native. Backend is completely in Rust, frontend is in native.
+Building
+Dependencies
+Number of dependencies was greatly reduced; no npm/yarn/nodejs/cocoapods, etc. All dependencies are handled by:
+-
+
- Cargo (rust packages) +
- Xcode (only default iOS frameworks are used) +
- Gradle +
Rust backend
+Rust libraries were moved back into the repository. Crypto functions are imported from Substrate. All logic and most of storage is written in Rust. An important hack here is that rust/signer crate has 2 versions of Cargo.toml for android and iOS architectures, as target library features could not be adjusted by normal means.
Native frontend
+Frontend for both iOS and Android re-written in native frameworks. Thus, standard out-of-the-box build scripts could be used for building once Rust libraries are built and linked
+Features
+Secure seed storage
+Secrets are stored in devices' encrypted storage and some effort is made to prevent them leaking in system memory. Thus, all is as safe as the phone is - the same credentials used for unlocking the phone are used to unlock seeds. User is responsible to keep them adequate.
+Transaction preview
+Transactions content is shown before signing; no hash signing is allowed, but signing messages is possible.
+History feature
+The Vault now logs all operations it performs. It it important to remember that this is not log of account operations, but log of device history. This history could be cleared if needed, but not modified by other means. Detected presence of network connection is also logged.
+N+1 derivation
+Much requested feature that makes Vault automatically increment numbered seeds on creation.
+Network and metadata updates
+All network data updates now could be performed through scanning QR codes. Whenever some update is needed, most probably you should just scan some QR video. Don't worry about skipped frames, it's fountain code so you only need enough frames.
+All updates could be signed, and signing key will be trusted on first use, so Vault device should be linked to single source of authority on correct metadata.
+Key re-use in different networks
+Keys could be used only in one network. Need to re-use key in another network? Just create key with the same derivation path in that network to allow re-use and it will work.
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/about/Security-And-Privacy.html b/about/Security-And-Privacy.html
new file mode 100644
index 0000000000..884ad2ebf8
--- /dev/null
+++ b/about/Security-And-Privacy.html
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Can I import my keys from
+
+
+
+
+ FAQ
+-
+
- About +
- Networks +
- Seeds and keys +
About
+What is Vault?
+Vault is an app for an air-gapped device, it turns an offline device — usually a smartphone — into a secure hardware wallet. Vault offers you a way to securely generate, store, manage and use your blockchain credentials.
+Should I use Vault?
+Vault is optimized for the highest security requirements. If you already manage many accounts on multiple networks, Vault is great for you. If you have little experience with blockchain networks but still want good security affordances, you might find the learning curve steep. We strive to make Vault as intuitive as possible; get in touch via signer@parity.io or GitHub Issues if you can help us get there!
+How does an offline device communicate with the outside world?
+Communication happens through scanning and generating QR codes. Scanned with Vault input-QRs interact with keys stored in Vault to, generate response-QRs on behalf of those keys. Usually, input-QR is a blockchain transaction, and a response-QR is a signature for this transaction. There are tried and true cryptographic algorithms that power these QR codes, as well as some smart engineering that make your dedicated device safe to use.
+How do I keep my keys secure?
+Vault is a safe way to use your keys. However, that alone won't be enough to keep your keys secure. Devices break and get lost. This is why we always recommend backing up your seed phrases and derivation paths on paper. We are such big fans of paper backups that we even support a special tool to power your paper backup game by splitting your backups into shards called Banana Split.
+How do I know I am not interacting with malicious apps or actors?
+The Vault does not interact with a network. The app itself does not have a way to check if an app or an account you're interacting with is malicious. +If you use Vault with PolkadotJS Browser Extension, PolkadotJS Apps, or Signer Component Browser Extension they will rely on a community-driven curated list of potentially less-than-honest operators: https://polkadot.js.org/phishing/# to prevent you from interacting with certain sites and addresses. However, there are no limitations on the use of Vault with other tools.
+I want to play with Vault to get a better feeling of how it works. Is there a way to do it without spending valuable tokens?
+Yes. In Vault, you should add a key for an address on Westend network and request test tokens for that address, see the step-by-step guide on Polkadot Network Wiki.
+You can use test tokens in the same way you would use value-bearing tokens.
+For example with PolkadotJS Apps you can create a transaction on behalf of your account, generate a signature with Vault and submit it to the network. All of this without keys ever leaving your offline device.
+Networks
+What networks does Vault support?
+From-the-shelf Polkadot Vault supports Polkadot, Kusama, and Westend networks. But it's not limited to these networks. More experienced users can generate metadata for any network to expand the capability of Polkadot Vault.
+How can I update metadata version for a network?
+Parity verifies and publishes recent metadata versions on Metadata Update Portal. With off-the-shelf Vault you can scan one of the multipart QR-"movies" same way you scan transaction QR:
+in Vault open scanner, scan the QR for the respective network and accept new metadata.
Currently, Metadata Update Portal follows Polkadot, Kusama, and Westend network metadata updates. Parity is open to collaboration with participants of other networks and is currently exploring safe and more decentralized ways of publishing verified metadata.
+If you want to update networks that you've added manually, please follow the Add Metadata steps in Add New Network guide.
+Why do I need to update network metadata versions at all?
+It's a safety feature. Substrate-based blockchain networks can be updated and otherwise changed; without recent metadata version of a network Vault won't be able to parse a transaction correctly, and you won't be able to read it and verify what you sign. Given that Vault is an app for an air-gapped device, you have to update the network version by using camera.
+How can I add a new network to Vault?
+Parity verifies and publishes network specs on Metadata Update Portal. To add one of the listed networks, in Metadata Update Portal click "Chain Specs", scan the network specs QR same way you scan transaction QR: in Vault open scanner, scan the QR and accept new network spec. Then scan the multipart QR-"movie" containing recent metadata for this network.
+Can I add a network that does not have network specs and metadata QR published anywhere?
+Yes. Follow the Add New Network step-by-step guide.
+Currently, the process requires you to have rust, subkey and parity-signer repository on your machine.
+Seeds and keys
+Can I import my keys from polkadot{.js} apps or extension to Polkadot Vault?
+Yes. Keys are compatible between polkadot{.js} and Polkadot Vault, except for the keys generated with Ledger (BIP39). To import seed keys into Polkadot Vault, you need to know:
-
+
- Seed phrase
+It should always be backed up in paper!
+ - Network you are adding address to and whether Polkadot Vault installed on your device has metadata for the respective network.
+If (2) is not one of the default built-in networks, you will need to add network yourself or find a distribution center for adding networks.
+ - Derivation path
+Only if you are importing a derived key, usually keys generated withpolkadot{.js}are seed keys.
+
In Polkadot Vault go to Keys, then press "Plus" icon in the top right of the screen, select "Recover seed", enter display name to identify your seed, press "Next", enter the seed phrase. Done, you've got your seed key imported!
+If you are importing a derived key select the seed from which your key is derived, select account's network, press "Plus" icon next to "Derived keys", enter your derivation path.
What is the difference between seed key and derived key? Why should I use derived keys?
+A seed key is a single key pair generated from a seed phrase. You can “grow” as many derived keys from a single seed by adding derivation paths to your seed phrase.
+Learn more about types of derivation paths on substrate.io.
+Derivation path is sensitive information, but knowing the derivation path is not enough to recover a key. Derived keys cannot be backed up without both of the ingredients: seed phrase (can be shared between multiple keys) and a derivation path (unique for each of the keys “grown” from that seed).
+The main reason to use derived keys is how easy it is to back up (and restore from a backup) a derivation path compared to seed phrase.
+What is an identicon, the image next to my keys?
+An identicon is a visual hash of a public key — a unique picture generated from your public key. The same public key should have the same identicon regardless of the application. It is a good tool to distinguish quickly between keys. However, when interacting with keys, i.g. verifying a recipient of a transaction, do not rely only on identicons, it is better to check the full public address.
+How can I rename one of my seeds?
+Due to security considerations, you cannot rename a seed. Please back up the seed and derived keys, remove it and add the seed again with a new name instead.
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/ace.js b/ace.js
new file mode 100644
index 0000000000..e8435a507d
--- /dev/null
+++ b/ace.js
@@ -0,0 +1,43 @@
+/*
+Copyright (c) 2010, Ajax.org B.V.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+ * Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+ * Neither the name of Ajax.org B.V. nor the
+ names of its contributors may be used to endorse or promote products
+ derived from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL AJAX.ORG B.V. BE LIABLE FOR ANY
+DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+*/
+
+(function(){function o(n){var i=e;n&&(e[n]||(e[n]={}),i=e[n]);if(!i.define||!i.define.packaged)t.original=i.define,i.define=t,i.define.packaged=!0;if(!i.require||!i.require.packaged)r.original=i.require,i.require=r,i.require.packaged=!0}var ACE_NAMESPACE = "ace",e=function(){return this}();!e&&typeof window!="undefined"&&(e=window);if(!ACE_NAMESPACE&&typeof requirejs!="undefined")return;var t=function(e,n,r){if(typeof e!="string"){t.original?t.original.apply(this,arguments):(console.error("dropping module because define wasn't a string."),console.trace());return}arguments.length==2&&(r=n),t.modules[e]||(t.payloads[e]=r,t.modules[e]=null)};t.modules={},t.payloads={};var n=function(e,t,n){if(typeof t=="string"){var i=s(e,t);if(i!=undefined)return n&&n(),i}else if(Object.prototype.toString.call(t)==="[object Array]"){var o=[];for(var u=0,a=t.length;u
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Security and Privacy
+Device security
+Polkadot Vault is built to be used offline. The mobile device used to run the app will hold important information that needs to be kept securely stored. It is therefore advised to:
+-
+
- Get a separate mobile device. +
- Make a factory reset. +
- Enable full-disk encryption on the device, with a reasonable password (might not be on by default, for example for older Android devices). +
- Do not use any kind of biometrics such as fingerprint or face recognition for device decryption/unlocking, as those may be less secure than regular passwords. +
- Once the app has been installed, enable airplane mode and make sure to switch off Wifi, Bluetooth or any connection ability of the device. +
- Only charge the phone on a power outlet that is never connected to the internet. Only charge the phone with the manufacturer's charging adapter. Do not charge the phone on public USB chargers. +
How to get it and use it?
+Install the app
+The app is available in beta for Android and iOS :
+ +Please double check carefully the origin of the app, and make sure that the company distributing it is Parity Technologies. Usual security advice apply to this air-gapped wallet:
+-
+
- When creating an account using Polkadot Vault Mobile app, make sure to write down the recovery phrase and store it in safe places. +
- Always double check the information of the transactions you are about to sign or send. +
- Make sure to first transfer a small amount of Ether with the app and verify that everything is working as expected before transferring larger amounts of Ether. +
How to update Polkadot Vault securely
+Once Polkadot Vault is installed, your device should never go online. This would put your private keys at threat. To update, you will need to :
+-
+
- Make sure you possess the recovery phrase for each of your accounts. You can find it on Polkadot Vault by : +
-
+
v4.0choosing an identity > click the user icon at the top right > “Show Recovery Phrase”
+v2.2tapping an account > 3 dots menu at the top right > “Backup Recovery Phrase”
+v2.0tapping an account > tap on the account address > “Backup Recovery Phrase”
+
-
+
- Factory reset the device. +
- Enable full-disk encryption on the device and set a strong password (might not be on by default, for example for older Android devices). +
- Do not use any kind of biometrics such as fingerprint or face recognition for device decryption/unlocking, as those may be less secure than regular passwords. +
- Install Polkadot Vault from the Apple store or Android store or download the APK from Polkadot Vault's Github repository (make sure you are on the right website and verify the checksum) +
- Once the app has been installed, enable airplane mode and make sure to switch off Wifi, Bluetooth, and any other connection ability the device has. +
- Only charge the phone on a power outlet that is never connected to the internet. Only charge the phone with the manufacturer's charging adapter. Do not charge the phone on public USB chargers. +
- Recover your accounts. +
What data does it collect?
+None, it's as simple as that. The Polkadot Vault Mobile Android and iOS apps do not send any sort of data to Parity Technologies or any partner and work completely offline once installed.
+ +"),i.setHtml(f),i.show(),t._signal("showGutterTooltip",i),t.on("mousewheel",c);if(e.$tooltipFollowsMouse)h(u);else{var p=u.domEvent.target,d=p.getBoundingClientRect(),v=i.getElement().style;v.left=d.right+"px",v.top=d.bottom+"px"}}function c(){o&&(o=clearTimeout(o)),f&&(i.hide(),f=null,t._signal("hideGutterTooltip",i),t.removeEventListener("mousewheel",c))}function h(e){i.setPosition(e.x,e.y)}var t=e.editor,n=t.renderer.$gutterLayer,i=new a(t.container);e.editor.setDefaultHandler("guttermousedown",function(r){if(!t.isFocused()||r.getButton()!=0)return;var i=n.getRegion(r);if(i=="foldWidgets")return;var s=r.getDocumentPosition().row,o=t.session.selection;if(r.getShiftKey())o.selectTo(s,0);else{if(r.domEvent.detail==2)return t.selectAll(),r.preventDefault();e.$clickSelection=t.selection.getLineRange(s)}return e.setState("selectByLines"),e.captureMouse(r),r.preventDefault()});var o,u,f;e.editor.setDefaultHandler("guttermousemove",function(t){var n=t.domEvent.target||t.domEvent.srcElement;if(r.hasCssClass(n,"ace_fold-widget"))return c();f&&e.$tooltipFollowsMouse&&h(t),u=t;if(o)return;o=setTimeout(function(){o=null,u&&!e.isMousePressed?l():c()},50)}),s.addListener(t.renderer.$gutter,"mouseout",function(e){u=null;if(!f||o)return;o=setTimeout(function(){o=null,c()},50)}),t.on("changeSession",c)}function a(e){o.call(this,e)}var r=e("../lib/dom"),i=e("../lib/oop"),s=e("../lib/event"),o=e("../tooltip").Tooltip;i.inherits(a,o),function(){this.setPosition=function(e,t){var n=window.innerWidth||document.documentElement.clientWidth,r=window.innerHeight||document.documentElement.clientHeight,i=this.getWidth(),s=this.getHeight();e+=15,t+=15,e+i>n&&(e-=e+i-n),t+s>r&&(t-=20+s),o.prototype.setPosition.call(this,e,t)}}.call(a.prototype),t.GutterHandler=u}),ace.define("ace/mouse/mouse_event",["require","exports","module","ace/lib/event","ace/lib/useragent"],function(e,t,n){"use strict";var r=e("../lib/event"),i=e("../lib/useragent"),s=t.MouseEvent=function(e,t){this.domEvent=e,this.editor=t,this.x=this.clientX=e.clientX,this.y=this.clientY=e.clientY,this.$pos=null,this.$inSelection=null,this.propagationStopped=!1,this.defaultPrevented=!1};(function(){this.stopPropagation=function(){r.stopPropagation(this.domEvent),this.propagationStopped=!0},this.preventDefault=function(){r.preventDefault(this.domEvent),this.defaultPrevented=!0},this.stop=function(){this.stopPropagation(),this.preventDefault()},this.getDocumentPosition=function(){return this.$pos?this.$pos:(this.$pos=this.editor.renderer.screenToTextCoordinates(this.clientX,this.clientY),this.$pos)},this.inSelection=function(){if(this.$inSelection!==null)return this.$inSelection;var e=this.editor,t=e.getSelectionRange();if(t.isEmpty())this.$inSelection=!1;else{var n=this.getDocumentPosition();this.$inSelection=t.contains(n.row,n.column)}return this.$inSelection},this.getButton=function(){return r.getButton(this.domEvent)},this.getShiftKey=function(){return this.domEvent.shiftKey},this.getAccelKey=i.isMac?function(){return this.domEvent.metaKey}:function(){return this.domEvent.ctrlKey}}).call(s.prototype)}),ace.define("ace/mouse/dragdrop_handler",["require","exports","module","ace/lib/dom","ace/lib/event","ace/lib/useragent"],function(e,t,n){"use strict";function f(e){function T(e,n){var r=Date.now(),i=!n||e.row!=n.row,s=!n||e.column!=n.column;if(!S||i||s)t.moveCursorToPosition(e),S=r,x={x:p,y:d};else{var o=l(x.x,x.y,p,d);o>a?S=null:r-S>=u&&(t.renderer.scrollCursorIntoView(),S=null)}}function N(e,n){var r=Date.now(),i=t.renderer.layerConfig.lineHeight,s=t.renderer.layerConfig.characterWidth,u=t.renderer.scroller.getBoundingClientRect(),a={x:{left:p-u.left,right:u.right-p},y:{top:d-u.top,bottom:u.bottom-d}},f=Math.min(a.x.left,a.x.right),l=Math.min(a.y.top,a.y.bottom),c={row:e.row,column:e.column};f/s<=2&&(c.column+=a.x.left
"),p.appendChild(i.createElement("div"));var m=function(e,t,n){if(t===0&&(n==="esc"||n==="return"))return h.destroy(),{command:"null"}};h.destroy=function(){if(e.$mouseHandler.isMousePressed)return;e.keyBinding.removeKeyboardHandler(m),n.widgetManager.removeLineWidget(h),e.off("changeSelection",h.destroy),e.off("changeSession",h.destroy),e.off("mouseup",h.destroy),e.off("change",h.destroy)},e.keyBinding.addKeyboardHandler(m),e.on("changeSelection",h.destroy),e.on("changeSession",h.destroy),e.on("mouseup",h.destroy),e.on("change",h.destroy),e.session.widgetManager.addLineWidget(h),h.el.onmousedown=e.focus.bind(e),e.renderer.scrollCursorIntoView(null,.5,{bottom:h.el.offsetHeight})},i.importCssString(" .error_widget_wrapper { background: inherit; color: inherit; border:none } .error_widget { border-top: solid 2px; border-bottom: solid 2px; margin: 5px 0; padding: 10px 40px; white-space: pre-wrap; } .error_widget.ace_error, .error_widget_arrow.ace_error{ border-color: #ff5a5a } .error_widget.ace_warning, .error_widget_arrow.ace_warning{ border-color: #F1D817 } .error_widget.ace_info, .error_widget_arrow.ace_info{ border-color: #5a5a5a } .error_widget.ace_ok, .error_widget_arrow.ace_ok{ border-color: #5aaa5a } .error_widget_arrow { position: absolute; border: solid 5px; border-top-color: transparent!important; border-right-color: transparent!important; border-left-color: transparent!important; top: -5px; }","")}),ace.define("ace/ace",["require","exports","module","ace/lib/fixoldbrowsers","ace/lib/dom","ace/lib/event","ace/range","ace/editor","ace/edit_session","ace/undomanager","ace/virtual_renderer","ace/worker/worker_client","ace/keyboard/hash_handler","ace/placeholder","ace/multi_select","ace/mode/folding/fold_mode","ace/theme/textmate","ace/ext/error_marker","ace/config"],function(e,t,n){"use strict";e("./lib/fixoldbrowsers");var r=e("./lib/dom"),i=e("./lib/event"),s=e("./range").Range,o=e("./editor").Editor,u=e("./edit_session").EditSession,a=e("./undomanager").UndoManager,f=e("./virtual_renderer").VirtualRenderer;e("./worker/worker_client"),e("./keyboard/hash_handler"),e("./placeholder"),e("./multi_select"),e("./mode/folding/fold_mode"),e("./theme/textmate"),e("./ext/error_marker"),t.config=e("./config"),t.require=e,typeof define=="function"&&(t.define=define),t.edit=function(e,n){if(typeof e=="string"){var s=e;e=document.getElementById(s);if(!e)throw new Error("ace.edit can't find div #"+s)}if(e&&e.env&&e.env.editor instanceof o)return e.env.editor;var u="";if(e&&/input|textarea/i.test(e.tagName)){var a=e;u=a.value,e=r.createElement("pre"),a.parentNode.replaceChild(e,a)}else e&&(u=e.textContent,e.innerHTML="");var l=t.createEditSession(u),c=new o(new f(e),l,n),h={document:l,editor:c,onResize:c.resize.bind(c,null)};return a&&(h.textarea=a),i.addListener(window,"resize",h.onResize),c.on("destroy",function(){i.removeListener(window,"resize",h.onResize),h.editor.container.env=null}),c.container.env=c.env=h,c},t.createEditSession=function(e,t){var n=new u(e,t);return n.setUndoManager(new a),n},t.Range=s,t.Editor=o,t.EditSession=u,t.UndoManager=a,t.VirtualRenderer=f,t.version="1.4.4"}); (function() { + ace.require(["ace/ace"], function(a) { + if (a) { + a.config.init(true); + a.define = ace.define; + } + if (!window.ace) + window.ace = a; + for (var key in a) if (a.hasOwnProperty(key)) + window.ace[key] = a[key]; + window.ace["default"] = window.ace; + if (typeof module == "object" && typeof exports == "object" && module) { + module.exports = window.ace; + } + }); + })(); diff --git a/ayu-highlight.css b/ayu-highlight.css new file mode 100644 index 0000000000..32c9432224 --- /dev/null +++ b/ayu-highlight.css @@ -0,0 +1,78 @@ +/* +Based off of the Ayu theme +Original by Dempfi (https://github.com/dempfi/ayu) +*/ + +.hljs { + display: block; + overflow-x: auto; + background: #191f26; + color: #e6e1cf; +} + +.hljs-comment, +.hljs-quote { + color: #5c6773; + font-style: italic; +} + +.hljs-variable, +.hljs-template-variable, +.hljs-attribute, +.hljs-attr, +.hljs-regexp, +.hljs-link, +.hljs-selector-id, +.hljs-selector-class { + color: #ff7733; +} + +.hljs-number, +.hljs-meta, +.hljs-builtin-name, +.hljs-literal, +.hljs-type, +.hljs-params { + color: #ffee99; +} + +.hljs-string, +.hljs-bullet { + color: #b8cc52; +} + +.hljs-title, +.hljs-built_in, +.hljs-section { + color: #ffb454; +} + +.hljs-keyword, +.hljs-selector-tag, +.hljs-symbol { + color: #ff7733; +} + +.hljs-name { + color: #36a3d9; +} + +.hljs-tag { + color: #00568d; +} + +.hljs-emphasis { + font-style: italic; +} + +.hljs-strong { + font-weight: bold; +} + +.hljs-addition { + color: #91b362; +} + +.hljs-deletion { + color: #d96c75; +} diff --git a/book.js b/book.js new file mode 100644 index 0000000000..aa12e7eccf --- /dev/null +++ b/book.js @@ -0,0 +1,697 @@ +"use strict"; + +// Fix back button cache problem +window.onunload = function () { }; + +// Global variable, shared between modules +function playground_text(playground, hidden = true) { + let code_block = playground.querySelector("code"); + + if (window.ace && code_block.classList.contains("editable")) { + let editor = window.ace.edit(code_block); + return editor.getValue(); + } else if (hidden) { + return code_block.textContent; + } else { + return code_block.innerText; + } +} + +(function codeSnippets() { + function fetch_with_timeout(url, options, timeout = 6000) { + return Promise.race([ + fetch(url, options), + new Promise((_, reject) => setTimeout(() => reject(new Error('timeout')), timeout)) + ]); + } + + var playgrounds = Array.from(document.querySelectorAll(".playground")); + if (playgrounds.length > 0) { + fetch_with_timeout("https://play.rust-lang.org/meta/crates", { + headers: { + 'Content-Type': "application/json", + }, + method: 'POST', + mode: 'cors', + }) + .then(response => response.json()) + .then(response => { + // get list of crates available in the rust playground + let playground_crates = response.crates.map(item => item["id"]); + playgrounds.forEach(block => handle_crate_list_update(block, playground_crates)); + }); + } + + function handle_crate_list_update(playground_block, playground_crates) { + // update the play buttons after receiving the response + update_play_button(playground_block, playground_crates); + + // and install on change listener to dynamically update ACE editors + if (window.ace) { + let code_block = playground_block.querySelector("code"); + if (code_block.classList.contains("editable")) { + let editor = window.ace.edit(code_block); + editor.addEventListener("change", function (e) { + update_play_button(playground_block, playground_crates); + }); + // add Ctrl-Enter command to execute rust code + editor.commands.addCommand({ + name: "run", + bindKey: { + win: "Ctrl-Enter", + mac: "Ctrl-Enter" + }, + exec: _editor => run_rust_code(playground_block) + }); + } + } + } + + // updates the visibility of play button based on `no_run` class and + // used crates vs ones available on https://play.rust-lang.org + function update_play_button(pre_block, playground_crates) { + var play_button = pre_block.querySelector(".play-button"); + + // skip if code is `no_run` + if (pre_block.querySelector('code').classList.contains("no_run")) { + play_button.classList.add("hidden"); + return; + } + + // get list of `extern crate`'s from snippet + var txt = playground_text(pre_block); + var re = /extern\s+crate\s+([a-zA-Z_0-9]+)\s*;/g; + var snippet_crates = []; + var item; + while (item = re.exec(txt)) { + snippet_crates.push(item[1]); + } + + // check if all used crates are available on play.rust-lang.org + var all_available = snippet_crates.every(function (elem) { + return playground_crates.indexOf(elem) > -1; + }); + + if (all_available) { + play_button.classList.remove("hidden"); + } else { + play_button.classList.add("hidden"); + } + } + + function run_rust_code(code_block) { + var result_block = code_block.querySelector(".result"); + if (!result_block) { + result_block = document.createElement('code'); + result_block.className = 'result hljs language-bash'; + + code_block.append(result_block); + } + + let text = playground_text(code_block); + let classes = code_block.querySelector('code').classList; + let edition = "2015"; + if(classes.contains("edition2018")) { + edition = "2018"; + } else if(classes.contains("edition2021")) { + edition = "2021"; + } + var params = { + version: "stable", + optimize: "0", + code: text, + edition: edition + }; + + if (text.indexOf("#![feature") !== -1) { + params.version = "nightly"; + } + + result_block.innerText = "Running..."; + + fetch_with_timeout("https://play.rust-lang.org/evaluate.json", { + headers: { + 'Content-Type': "application/json", + }, + method: 'POST', + mode: 'cors', + body: JSON.stringify(params) + }) + .then(response => response.json()) + .then(response => { + if (response.result.trim() === '') { + result_block.innerText = "No output"; + result_block.classList.add("result-no-output"); + } else { + result_block.innerText = response.result; + result_block.classList.remove("result-no-output"); + } + }) + .catch(error => result_block.innerText = "Playground Communication: " + error.message); + } + + // Syntax highlighting Configuration + hljs.configure({ + tabReplace: ' ', // 4 spaces + languages: [], // Languages used for auto-detection + }); + + let code_nodes = Array + .from(document.querySelectorAll('code')) + // Don't highlight `inline code` blocks in headers. + .filter(function (node) {return !node.parentElement.classList.contains("header"); }); + + if (window.ace) { + // language-rust class needs to be removed for editable + // blocks or highlightjs will capture events + code_nodes + .filter(function (node) {return node.classList.contains("editable"); }) + .forEach(function (block) { block.classList.remove('language-rust'); }); + + code_nodes + .filter(function (node) {return !node.classList.contains("editable"); }) + .forEach(function (block) { hljs.highlightBlock(block); }); + } else { + code_nodes.forEach(function (block) { hljs.highlightBlock(block); }); + } + + // Adding the hljs class gives code blocks the color css + // even if highlighting doesn't apply + code_nodes.forEach(function (block) { block.classList.add('hljs'); }); + + Array.from(document.querySelectorAll("code.hljs")).forEach(function (block) { + + var lines = Array.from(block.querySelectorAll('.boring')); + // If no lines were hidden, return + if (!lines.length) { return; } + block.classList.add("hide-boring"); + + var buttons = document.createElement('div'); + buttons.className = 'buttons'; + buttons.innerHTML = ""; + + // add expand button + var pre_block = block.parentNode; + pre_block.insertBefore(buttons, pre_block.firstChild); + + pre_block.querySelector('.buttons').addEventListener('click', function (e) { + if (e.target.classList.contains('fa-eye')) { + e.target.classList.remove('fa-eye'); + e.target.classList.add('fa-eye-slash'); + e.target.title = 'Hide lines'; + e.target.setAttribute('aria-label', e.target.title); + + block.classList.remove('hide-boring'); + } else if (e.target.classList.contains('fa-eye-slash')) { + e.target.classList.remove('fa-eye-slash'); + e.target.classList.add('fa-eye'); + e.target.title = 'Show hidden lines'; + e.target.setAttribute('aria-label', e.target.title); + + block.classList.add('hide-boring'); + } + }); + }); + + if (window.playground_copyable) { + Array.from(document.querySelectorAll('pre code')).forEach(function (block) { + var pre_block = block.parentNode; + if (!pre_block.classList.contains('playground')) { + var buttons = pre_block.querySelector(".buttons"); + if (!buttons) { + buttons = document.createElement('div'); + buttons.className = 'buttons'; + pre_block.insertBefore(buttons, pre_block.firstChild); + } + + var clipButton = document.createElement('button'); + clipButton.className = 'fa fa-copy clip-button'; + clipButton.title = 'Copy to clipboard'; + clipButton.setAttribute('aria-label', clipButton.title); + clipButton.innerHTML = ''; + + buttons.insertBefore(clipButton, buttons.firstChild); + } + }); + } + + // Process playground code blocks + Array.from(document.querySelectorAll(".playground")).forEach(function (pre_block) { + // Add play button + var buttons = pre_block.querySelector(".buttons"); + if (!buttons) { + buttons = document.createElement('div'); + buttons.className = 'buttons'; + pre_block.insertBefore(buttons, pre_block.firstChild); + } + + var runCodeButton = document.createElement('button'); + runCodeButton.className = 'fa fa-play play-button'; + runCodeButton.hidden = true; + runCodeButton.title = 'Run this code'; + runCodeButton.setAttribute('aria-label', runCodeButton.title); + + buttons.insertBefore(runCodeButton, buttons.firstChild); + runCodeButton.addEventListener('click', function (e) { + run_rust_code(pre_block); + }); + + if (window.playground_copyable) { + var copyCodeClipboardButton = document.createElement('button'); + copyCodeClipboardButton.className = 'fa fa-copy clip-button'; + copyCodeClipboardButton.innerHTML = ''; + copyCodeClipboardButton.title = 'Copy to clipboard'; + copyCodeClipboardButton.setAttribute('aria-label', copyCodeClipboardButton.title); + + buttons.insertBefore(copyCodeClipboardButton, buttons.firstChild); + } + + let code_block = pre_block.querySelector("code"); + if (window.ace && code_block.classList.contains("editable")) { + var undoChangesButton = document.createElement('button'); + undoChangesButton.className = 'fa fa-history reset-button'; + undoChangesButton.title = 'Undo changes'; + undoChangesButton.setAttribute('aria-label', undoChangesButton.title); + + buttons.insertBefore(undoChangesButton, buttons.firstChild); + + undoChangesButton.addEventListener('click', function () { + let editor = window.ace.edit(code_block); + editor.setValue(editor.originalCode); + editor.clearSelection(); + }); + } + }); +})(); + +(function themes() { + var html = document.querySelector('html'); + var themeToggleButton = document.getElementById('theme-toggle'); + var themePopup = document.getElementById('theme-list'); + var themeColorMetaTag = document.querySelector('meta[name="theme-color"]'); + var stylesheets = { + ayuHighlight: document.querySelector("[href$='ayu-highlight.css']"), + tomorrowNight: document.querySelector("[href$='tomorrow-night.css']"), + highlight: document.querySelector("[href$='highlight.css']"), + }; + + function showThemes() { + themePopup.style.display = 'block'; + themeToggleButton.setAttribute('aria-expanded', true); + themePopup.querySelector("button#" + get_theme()).focus(); + } + + function updateThemeSelected() { + themePopup.querySelectorAll('.theme-selected').forEach(function (el) { + el.classList.remove('theme-selected'); + }); + themePopup.querySelector("button#" + get_theme()).classList.add('theme-selected'); + } + + function hideThemes() { + themePopup.style.display = 'none'; + themeToggleButton.setAttribute('aria-expanded', false); + themeToggleButton.focus(); + } + + function get_theme() { + var theme; + try { theme = localStorage.getItem('mdbook-theme'); } catch (e) { } + if (theme === null || theme === undefined) { + return default_theme; + } else { + return theme; + } + } + + function set_theme(theme, store = true) { + let ace_theme; + + if (theme == 'coal' || theme == 'navy') { + stylesheets.ayuHighlight.disabled = true; + stylesheets.tomorrowNight.disabled = false; + stylesheets.highlight.disabled = true; + + ace_theme = "ace/theme/tomorrow_night"; + } else if (theme == 'ayu') { + stylesheets.ayuHighlight.disabled = false; + stylesheets.tomorrowNight.disabled = true; + stylesheets.highlight.disabled = true; + ace_theme = "ace/theme/tomorrow_night"; + } else { + stylesheets.ayuHighlight.disabled = true; + stylesheets.tomorrowNight.disabled = true; + stylesheets.highlight.disabled = false; + ace_theme = "ace/theme/dawn"; + } + + setTimeout(function () { + themeColorMetaTag.content = getComputedStyle(document.documentElement).backgroundColor; + }, 1); + + if (window.ace && window.editors) { + window.editors.forEach(function (editor) { + editor.setTheme(ace_theme); + }); + } + + var previousTheme = get_theme(); + + if (store) { + try { localStorage.setItem('mdbook-theme', theme); } catch (e) { } + } + + html.classList.remove(previousTheme); + html.classList.add(theme); + updateThemeSelected(); + } + + // Set theme + var theme = get_theme(); + + set_theme(theme, false); + + themeToggleButton.addEventListener('click', function () { + if (themePopup.style.display === 'block') { + hideThemes(); + } else { + showThemes(); + } + }); + + themePopup.addEventListener('click', function (e) { + var theme; + if (e.target.className === "theme") { + theme = e.target.id; + } else if (e.target.parentElement.className === "theme") { + theme = e.target.parentElement.id; + } else { + return; + } + set_theme(theme); + }); + + themePopup.addEventListener('focusout', function(e) { + // e.relatedTarget is null in Safari and Firefox on macOS (see workaround below) + if (!!e.relatedTarget && !themeToggleButton.contains(e.relatedTarget) && !themePopup.contains(e.relatedTarget)) { + hideThemes(); + } + }); + + // Should not be needed, but it works around an issue on macOS & iOS: https://github.com/rust-lang/mdBook/issues/628 + document.addEventListener('click', function(e) { + if (themePopup.style.display === 'block' && !themeToggleButton.contains(e.target) && !themePopup.contains(e.target)) { + hideThemes(); + } + }); + + document.addEventListener('keydown', function (e) { + if (e.altKey || e.ctrlKey || e.metaKey || e.shiftKey) { return; } + if (!themePopup.contains(e.target)) { return; } + + switch (e.key) { + case 'Escape': + e.preventDefault(); + hideThemes(); + break; + case 'ArrowUp': + e.preventDefault(); + var li = document.activeElement.parentElement; + if (li && li.previousElementSibling) { + li.previousElementSibling.querySelector('button').focus(); + } + break; + case 'ArrowDown': + e.preventDefault(); + var li = document.activeElement.parentElement; + if (li && li.nextElementSibling) { + li.nextElementSibling.querySelector('button').focus(); + } + break; + case 'Home': + e.preventDefault(); + themePopup.querySelector('li:first-child button').focus(); + break; + case 'End': + e.preventDefault(); + themePopup.querySelector('li:last-child button').focus(); + break; + } + }); +})(); + +(function sidebar() { + var body = document.querySelector("body"); + var sidebar = document.getElementById("sidebar"); + var sidebarLinks = document.querySelectorAll('#sidebar a'); + var sidebarToggleButton = document.getElementById("sidebar-toggle"); + var sidebarResizeHandle = document.getElementById("sidebar-resize-handle"); + var firstContact = null; + + function showSidebar() { + body.classList.remove('sidebar-hidden') + body.classList.add('sidebar-visible'); + Array.from(sidebarLinks).forEach(function (link) { + link.setAttribute('tabIndex', 0); + }); + sidebarToggleButton.setAttribute('aria-expanded', true); + sidebar.setAttribute('aria-hidden', false); + try { localStorage.setItem('mdbook-sidebar', 'visible'); } catch (e) { } + } + + + var sidebarAnchorToggles = document.querySelectorAll('#sidebar a.toggle'); + + function toggleSection(ev) { + ev.currentTarget.parentElement.classList.toggle('expanded'); + } + + Array.from(sidebarAnchorToggles).forEach(function (el) { + el.addEventListener('click', toggleSection); + }); + + function hideSidebar() { + body.classList.remove('sidebar-visible') + body.classList.add('sidebar-hidden'); + Array.from(sidebarLinks).forEach(function (link) { + link.setAttribute('tabIndex', -1); + }); + sidebarToggleButton.setAttribute('aria-expanded', false); + sidebar.setAttribute('aria-hidden', true); + try { localStorage.setItem('mdbook-sidebar', 'hidden'); } catch (e) { } + } + + // Toggle sidebar + sidebarToggleButton.addEventListener('click', function sidebarToggle() { + if (body.classList.contains("sidebar-hidden")) { + var current_width = parseInt( + document.documentElement.style.getPropertyValue('--sidebar-width'), 10); + if (current_width < 150) { + document.documentElement.style.setProperty('--sidebar-width', '150px'); + } + showSidebar(); + } else if (body.classList.contains("sidebar-visible")) { + hideSidebar(); + } else { + if (getComputedStyle(sidebar)['transform'] === 'none') { + hideSidebar(); + } else { + showSidebar(); + } + } + }); + + sidebarResizeHandle.addEventListener('mousedown', initResize, false); + + function initResize(e) { + window.addEventListener('mousemove', resize, false); + window.addEventListener('mouseup', stopResize, false); + body.classList.add('sidebar-resizing'); + } + function resize(e) { + var pos = (e.clientX - sidebar.offsetLeft); + if (pos < 20) { + hideSidebar(); + } else { + if (body.classList.contains("sidebar-hidden")) { + showSidebar(); + } + pos = Math.min(pos, window.innerWidth - 100); + document.documentElement.style.setProperty('--sidebar-width', pos + 'px'); + } + } + //on mouseup remove windows functions mousemove & mouseup + function stopResize(e) { + body.classList.remove('sidebar-resizing'); + window.removeEventListener('mousemove', resize, false); + window.removeEventListener('mouseup', stopResize, false); + } + + document.addEventListener('touchstart', function (e) { + firstContact = { + x: e.touches[0].clientX, + time: Date.now() + }; + }, { passive: true }); + + document.addEventListener('touchmove', function (e) { + if (!firstContact) + return; + + var curX = e.touches[0].clientX; + var xDiff = curX - firstContact.x, + tDiff = Date.now() - firstContact.time; + + if (tDiff < 250 && Math.abs(xDiff) >= 150) { + if (xDiff >= 0 && firstContact.x < Math.min(document.body.clientWidth * 0.25, 300)) + showSidebar(); + else if (xDiff < 0 && curX < 300) + hideSidebar(); + + firstContact = null; + } + }, { passive: true }); +})(); + +(function chapterNavigation() { + document.addEventListener('keydown', function (e) { + if (e.altKey || e.ctrlKey || e.metaKey || e.shiftKey) { return; } + if (window.search && window.search.hasFocus()) { return; } + var html = document.querySelector('html'); + + function next() { + var nextButton = document.querySelector('.nav-chapters.next'); + if (nextButton) { + window.location.href = nextButton.href; + } + } + function prev() { + var previousButton = document.querySelector('.nav-chapters.previous'); + if (previousButton) { + window.location.href = previousButton.href; + } + } + switch (e.key) { + case 'ArrowRight': + e.preventDefault(); + if (html.dir == 'rtl') { + prev(); + } else { + next(); + } + break; + case 'ArrowLeft': + e.preventDefault(); + if (html.dir == 'rtl') { + next(); + } else { + prev(); + } + break; + } + }); +})(); + +(function clipboard() { + var clipButtons = document.querySelectorAll('.clip-button'); + + function hideTooltip(elem) { + elem.firstChild.innerText = ""; + elem.className = 'fa fa-copy clip-button'; + } + + function showTooltip(elem, msg) { + elem.firstChild.innerText = msg; + elem.className = 'fa fa-copy tooltipped'; + } + + var clipboardSnippets = new ClipboardJS('.clip-button', { + text: function (trigger) { + hideTooltip(trigger); + let playground = trigger.closest("pre"); + return playground_text(playground, false); + } + }); + + Array.from(clipButtons).forEach(function (clipButton) { + clipButton.addEventListener('mouseout', function (e) { + hideTooltip(e.currentTarget); + }); + }); + + clipboardSnippets.on('success', function (e) { + e.clearSelection(); + showTooltip(e.trigger, "Copied!"); + }); + + clipboardSnippets.on('error', function (e) { + showTooltip(e.trigger, "Clipboard error!"); + }); +})(); + +(function scrollToTop () { + var menuTitle = document.querySelector('.menu-title'); + + menuTitle.addEventListener('click', function () { + document.scrollingElement.scrollTo({ top: 0, behavior: 'smooth' }); + }); +})(); + +(function controllMenu() { + var menu = document.getElementById('menu-bar'); + + (function controllPosition() { + var scrollTop = document.scrollingElement.scrollTop; + var prevScrollTop = scrollTop; + var minMenuY = -menu.clientHeight - 50; + // When the script loads, the page can be at any scroll (e.g. if you reforesh it). + menu.style.top = scrollTop + 'px'; + // Same as parseInt(menu.style.top.slice(0, -2), but faster + var topCache = menu.style.top.slice(0, -2); + menu.classList.remove('sticky'); + var stickyCache = false; // Same as menu.classList.contains('sticky'), but faster + document.addEventListener('scroll', function () { + scrollTop = Math.max(document.scrollingElement.scrollTop, 0); + // `null` means that it doesn't need to be updated + var nextSticky = null; + var nextTop = null; + var scrollDown = scrollTop > prevScrollTop; + var menuPosAbsoluteY = topCache - scrollTop; + if (scrollDown) { + nextSticky = false; + if (menuPosAbsoluteY > 0) { + nextTop = prevScrollTop; + } + } else { + if (menuPosAbsoluteY > 0) { + nextSticky = true; + } else if (menuPosAbsoluteY < minMenuY) { + nextTop = prevScrollTop + minMenuY; + } + } + if (nextSticky === true && stickyCache === false) { + menu.classList.add('sticky'); + stickyCache = true; + } else if (nextSticky === false && stickyCache === true) { + menu.classList.remove('sticky'); + stickyCache = false; + } + if (nextTop !== null) { + menu.style.top = nextTop + 'px'; + topCache = nextTop; + } + prevScrollTop = scrollTop; + }, { passive: true }); + })(); + (function controllBorder() { + function updateBorder() { + if (menu.offsetTop === 0) { + menu.classList.remove('bordered'); + } else { + menu.classList.add('bordered'); + } + } + updateBorder(); + document.addEventListener('scroll', updateBorder, { passive: true }); + })(); +})(); diff --git a/clipboard.min.js b/clipboard.min.js new file mode 100644 index 0000000000..02c549e35c --- /dev/null +++ b/clipboard.min.js @@ -0,0 +1,7 @@ +/*! + * clipboard.js v2.0.4 + * https://zenorocha.github.io/clipboard.js + * + * Licensed MIT © Zeno Rocha + */ +!function(t,e){"object"==typeof exports&&"object"==typeof module?module.exports=e():"function"==typeof define&&define.amd?define([],e):"object"==typeof exports?exports.ClipboardJS=e():t.ClipboardJS=e()}(this,function(){return function(n){var o={};function r(t){if(o[t])return o[t].exports;var e=o[t]={i:t,l:!1,exports:{}};return n[t].call(e.exports,e,e.exports,r),e.l=!0,e.exports}return r.m=n,r.c=o,r.d=function(t,e,n){r.o(t,e)||Object.defineProperty(t,e,{enumerable:!0,get:n})},r.r=function(t){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(t,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(t,"__esModule",{value:!0})},r.t=function(e,t){if(1&t&&(e=r(e)),8&t)return e;if(4&t&&"object"==typeof e&&e&&e.__esModule)return e;var n=Object.create(null);if(r.r(n),Object.defineProperty(n,"default",{enumerable:!0,value:e}),2&t&&"string"!=typeof e)for(var o in e)r.d(n,o,function(t){return e[t]}.bind(null,o));return n},r.n=function(t){var e=t&&t.__esModule?function(){return t.default}:function(){return t};return r.d(e,"a",e),e},r.o=function(t,e){return Object.prototype.hasOwnProperty.call(t,e)},r.p="",r(r.s=0)}([function(t,e,n){"use strict";var r="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(t){return typeof t}:function(t){return t&&"function"==typeof Symbol&&t.constructor===Symbol&&t!==Symbol.prototype?"symbol":typeof t},i=function(){function o(t,e){for(var n=0;n
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/development/Development.html b/development/Development.html
new file mode 100644
index 0000000000..26e9152553
--- /dev/null
+++ b/development/Development.html
@@ -0,0 +1,238 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Build
+First and foremost, make sure you have the latest Rust installed in your system. Nothing will work without Rust.
+If you get errors like cargo: feature X is required, it most likely means you have an old version of Rust. Update it by running rustup update stable.
iOS
+1. You probably already have Xcode installed if you are reading this. If not, go get it.
+2. Compile the core Rust library first:
+cd scripts && ./build.sh ios
+3. Open the NativeSigner.xcodeproj project from the ios folder in your Xcode and click Run (Cmd+R).
4. The first time you start the app, you will need to put your device into Airplane Mode. In the iOS simulator, you can do this by turning off WiFi on your Mac (yes, this is an official apple-recommended way).
+However, we strongly recommend that you use a real device for development, as some important parts (e.g. camera) may not work in the simulator.
+Android
+1. Download Android Studio.
+2. Open the project from the android directory.
3. Install NDK. Go to File -> Project Structure -> SDK Location. Next to the "Android NDK location" section, click "Download Android NDK" button.
We highly recommend you to update all existing plugins and SDK's for Kotlin, Gradle, etc even if you just downloaded a fresh Android Studio. It's always a good idea to restart Android Studio after that. This can save you many hours on Stackoverflow trying to fix random errors like "NDK not found".
+4. Connect your device or create a virtual one. Open Tools -> Device Manager and create a new phone simulator with the latest Android.
5. (macOS) Specify path to python in local.properties.
rust.pythonCommand=python3
6. Run the project (Ctrl+R). It should build the Rust core library automatically.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/development/Ecosystem.html b/development/Ecosystem.html
new file mode 100644
index 0000000000..05eb69c8e7
--- /dev/null
+++ b/development/Ecosystem.html
@@ -0,0 +1,245 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Development
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/development/Rustdocs.html b/development/Rustdocs.html
new file mode 100644
index 0000000000..728cf4babb
--- /dev/null
+++ b/development/Rustdocs.html
@@ -0,0 +1,246 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Vault ecosystem
+Vault repository contains 3 tools that are part of Vault ecosystem
+-
+
- Polkadot Vault app +
generate_messagenetwork data management tool
+qr_reader_pcqr scanner app for PC
+
Greater Vault ecosystem:
+-
+
- metadata portal +
- Signer companion +
- polkadot-js libraries for QR code data transfer +
- UOS interface specification - since no tools support original upstream specification, here is standard interpretation that is used in Vault. +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/development/Troubleshooting.html b/development/Troubleshooting.html
new file mode 100644
index 0000000000..e9ceedd2aa
--- /dev/null
+++ b/development/Troubleshooting.html
@@ -0,0 +1,242 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Links to rust docs of the apps
+ + +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/development/UOS.html b/development/UOS.html
new file mode 100644
index 0000000000..e10e4492d6
--- /dev/null
+++ b/development/UOS.html
@@ -0,0 +1,1186 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Troubleshooting
+Rust side builds but app crashes on start (Android) or complains about symbols not found (iOS)
+One common reason for this is inconsistency in uniffi version - make sure that installed version matches one stated in Cargo.toml
Build for Android fails on macOS, build for iOS fails on linux
+This is a known issue, does not seem to be solvable at the moment. Please use 2 machines, as we do.
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/development/Vault-Structure.html b/development/Vault-Structure.html
new file mode 100644
index 0000000000..1b32a6f7a0
--- /dev/null
+++ b/development/Vault-Structure.html
@@ -0,0 +1,585 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Derivations import, payload code
+
+
+
+
+
+
+ Scope
+This document provides an interpretation of the UOS format used by Polkadot Vault. The upstream version of the published format has diverged significantly from the actual implementation, so this document represents the current state of the UOS format that is compatible with Polkadot Vault. It only applies to networks compatible with Polkadot Vault, i.e. Substrate-based networks. The document also describes special payloads used to maintain a Polkadot Vault instance.
+Therefore, this document effectively describes the input and output format for QR codes used by Polkadot Vault.
+Terminology
+The Vault receives information over an air-gap as QR codes. These codes are read as u8 vectors and must always be parsed by the Vault before use.
QR codes can contain information that a user wants to sign with one of the Vault keys, or they may contain update information to ensure smooth operation of the Vault without the need for a reset or connection to the network.
+QR code content types
+-
+
- Transaction/extrinsic - a single transaction that is to be signed +
- Bulk transactions - a set of transactions that are to be signed in a single +session +
- Message - a message that is to be signed with a key +
- Chain metadata: up-to-date metadata allows the Vault to read transactions content +
- Chain specs: adds new network to the Vault +
- Metadata types: is used to update older versions runtime metadata (
V13and below)
+ - Key derivations: is used to import and export Vault key paths +
QR code structure
+QR code envelope has the following structure:
+| QR code prefix | content | ending spacer | padding |
|---|---|---|---|
| 4 bits | byte-aligned content | 4 bits | remainder |
QR code prefix always starts with 0x4 symbol indicating "raw" encoding.
Subsequent 2 bytes encode content length. Using this number, QR code parser can +instantly extract content and disregard the rest of QR code.
+Actual content is shifted by half-byte, otherwise it is a normal byte sequence.
+Multiframe QR
+The information transferred through QR channel into Vault is always enveloped
+in multiframe packages (although minimal number of multiframe packages is 1).
+There are two standards for the multiframe: RaptorQ erasure coding and legacy
+non-erasure multiframe. The type of envelope is determined by the first bit of
+the QR code data: 0 indicates legacy multiframe, 1 indicates RaptorQ
RaptorQ multipart payload
+RaptorQ (RFC6330) is
+a variable rate (fountain) erasure code protocol with reference implementation
+in Rust
Wrapping content in RaptorQ protocol allows for arbitrary amounts of data to be
+transferred reliably within reasonable time. It is recommended to wrap all
+payloads into this type of envelope.
Each QR code in RaptorQ encoded multipart payload contains following parts:
bytes [0..4] | bytes [4..] |
|---|---|
0x80000000 || payload_size | RaptorQ serialized packet |
-
+
payload_sizeMUST contain payload size in bytes, represented as +big-endian 32-bit unsigned integer.
+payload_sizeMUST NOT exceed7FFFFFFF
+payload_sizeMUST be identical in all codes encoding the payload
+payload_sizeandRaptorQ serialized packetMUST be stored by the Cold +Vault, in no particular order, until their amount is sufficient to decode +the payload.
+- Hot Wallet MUST continuously loop through all the frames showing each +frame for at least 1/30 seconds (recommended frame rate: 4 FPS). +
- Cold Vault MUST be able to start scanning the Multipart Payload at any +frame. +
- Cold Vault MUST NOT expect the frames to come in any particular order. +
- Cold Vault SHOULD show a progress indicator of how many frames it has +successfully scanned out of the estimated minimum required amount. +
- Hot Wallet SHOULD generate sufficient number of recovery frames +(recommended overhead: 100%; minimal reasonable overhead: square root of +number of packets). +
- Payloads fitting in 1 frame SHOULD be shown without recovery frames as +static image. +
Once sufficient number of frames is collected, they could be processed into +single payload and treated as data vector ("QR code content").
+Legacy Multipart Payload
+In real implementation, the Polkadot Vault ecosystem generalized all payloads as +multipart messages.
+| bytes position | [0] | [1..3] | [3..5] | [5..] |
|---|---|---|---|---|
| content | 00 | frame_count | frame_index | data |
-
+
frameMUST the number of current frame, '0000' represented as +big-endian 16-bit unsigned integer.
+frame_countMUST the total number of frames, represented as big-endian +16-bit unsigned integer.
+part_dataMUST be stored by the Cold Vault, ordered byframenumber, +until all frames are scanned.
+- Hot Wallet MUST continuously loop through all the frames showing each +frame for about 2 seconds. +
- Cold Vault MUST be able to start scanning the Multipart Payload at any +frame. +
- Cold Vault MUST NOT expect the frames to come in any particular order. +
- Cold Vault SHOULD show a progress indicator of how many frames it has +successfully scanned out of the total count. +
Once all frames are combined, the part_data must be concatenated into a
+single binary blob and treated as data vector ("QR code content").
Informative content of QR code
+Every QR code content starts with a prelude [0x53, 0x<encryption code>, 0x<payload code>].
0x53 is always expected and indicates Substrate-related content.
<encryption code> for signables indicates encryption algorithm that will be
+used to generate the signature:
0x00 |
+ Ed25519 | +
0x01 |
+ Sr25519 | +
0x02 |
+ Ecdsa | +
<encryption code> for updates indicates encryption algorithm that was used to
+sign the update:
0x00 |
+ Ed25519 | +
0x01 |
+ Sr25519 | +
0x02 |
+ Ecdsa | +
0xff |
+ unsigned | +
Derivations import and testing are always unsigned, with <encryption code>
+always 0xff.
Vault supports following <payload code> variants:
0x00 |
+ legacy mortal transaction | +
0x02 |
+ transaction (both mortal and immortal) | +
0x03 |
+ message | +
0x04 |
+ bulk transactions | +
0x80 |
+ load metadata update | +
0x81 |
+ load types update | +
0xc1 |
+ add specs update | +
0xde |
+ derivations import | +
Note: old UOS specified 0x00 as mortal transaction and 0x02 as immortal one,
+but currently both mortal and immortal transactions from polkadot-js are 0x02.
Shared QR code processing sequence:
+-
+
- Read QR code, try interpreting it, and get the hexadecimal string from into +Rust (hexadecimal string is getting changed to raw bytes soon). +If QR code is not processable, nothing happens and the scanner keeps trying to +catch a processable one. +
- Analyze prelude: is it Substrate? is it a known payload type? If not, Vault +always produces an error and suggests to scan supported payload. +
Further processing is done based on the payload type.
+Transaction
+Transaction has the following structure:
+| prelude | public key | SCALE-encoded call data | SCALE-encoded extensions | network genesis hash | +
Public key is the key that can sign the transaction. Its length depends on the
+<encryption code> declared in transaction prelude:
| Encryption | Public key length, bytes |
|---|---|
| Ed25519 | 32 |
| Sr25519 | 32 |
| Ecdsa | 33 |
Call data is Vec<u8> representation of transaction content. Call data must be
+parsed by Vault prior to signature generation and becomes a part of signed
+blob. Within transaction, the call data is SCALE-encoded, i.e. effectively is
+prefixed with compact of its length in bytes.
Extensions contain data additional to the call data, and also are part of a +signed blob. Typical extensions are Era, Nonce, metadata version, etc. +Extensions content and order, in principle, can vary between the networks and +metadata versions.
+Network genesis hash determines the network in which the transaction is created. +At the moment genesis hash is fixed-length 32 bytes.
+Thus, the transaction structure could also be represented as:
+| prelude | public key | compact of call data length | call data | SCALE-encoded extensions | network genesis hash | +
Bold-marked transaction pieces are used in the blob for which the signature is
+produced. If the blob is short, 257 bytes or below, the signature is produced
+for it as is. For blobs longer than 257 bytes, 32 byte hash (blake2_256) is
+signed instead. This is inherited from earlier Vault versions, and is currently
+compatible with polkadot-js.
Transaction parsing sequence
+-
+
-
+
Cut the QR data and get:
+-
+
- encryption (single
u8from prelude)
+ - transaction author public key, its length matching the encryption (32 or
+33
u8immediately after the prelude)
+ - network genesis hash (32
u8at the end)
+ - SCALE-encoded call data and SCALE-encoded extensions as a combined blob +(everything that remains in between the transaction author public kay and +the network genesis hash) +
If the data length is insufficient, Vault produces an error and suggests to +load non-damaged transaction.
+
+ - encryption (single
-
+
Search the Vault database for the network specs (from the network genesis +hash and encryption).
+If the network specs are not found, Vault shows:
+-
+
- public key and encryption of the transaction author key +
- error message, that suggests to add network with found genesis hash +
+ -
+
Search the Vault database for the address key (from the transaction author +public key and encryption). Vault will try to interpret and display the +transaction in any case. Signing will be possible only if the parsing is +successful and the address key is known to Vault and is extended to the network +in question.
+-
+
-
+
Address key not found. Signing not possible. Output shows:
+-
+
- public key and encryption of the transaction author key +
- call and extensions parsing result +
- warning message, that suggests to add the address into Vault +
+ -
+
Address key is found, but it is not extended to the network used. Signing +not possible. Output shows:
+-
+
- detailed author key information (base58 representation, identicon, +address details such as address being passworded etc) +
- call and extensions parsing result +
- warning message, that suggests extending the address into the network +used +
+ -
+
Address key is found and is extended to the network used. Vault will +proceed to try and interpret the call and extensions. Detailed author +information will be shown regardless of the parsing outcome. +The signing will be allowed only if the parsing is successful.
+
+
+ -
+
-
+
Separate the call and extensions. Call is prefixed by its length compact, +the compact is cut off, the part with length that was indicated in the compact +goes into call data, the part that remains goes into extensions data.
+If no compact is found or the length is insufficient, Vault produces an +error that call and extensions could not be separated.
+
+ -
+
Get the metadata set from the Vault database, by the network name from the +network specs. Metadata is used to interpret extensions and then the call +itself.
+If there are no metadata entries for the network at all, Vault produces an +error and asks to load the metadata.
+
+RuntimeMetadataversions supported by Vault areV12,V13, andV14. +The crucial feature of theV14is that the metadata contains the description +of the types used in the call and extensions production.V12andV13are +legacy versions and provide only text identifiers for the types, and in order to +use them, the supplemental types information is needed.
+ -
+
Process the extensions.
+Vault already knows in which network the transaction was made, but does not +yet know the metadata version. Metadata version must be one of the signable +extensions. At the same time, the extensions and their order are recorded in the +network metadata. Thus, all metadata entries from the set are checked, from +newest to oldest, in an attempt to find metadata that both decodes the +extensions and has a version that matches the metadata version decoded from the +extensions.
+If processing extensions with a single metadata entry results in an error, +the next metadata entry is tried. The errors would be displayed to user only if +all attempts with existing metadata have failed.
+Typically, the extensions are quite stable in between the metadata versions +and in between the networks, however, they can be and sometimes are different.
+In legacy metadata (
+RuntimeMetadataversion beingV12andV13) +extensions have identifiers only, and in Vault the extensions forV12and +V13are hardcoded as:-
+
Eraera
+Compact(u64)nonce
+Compact(u128)tip
+u32metadata version
+u32tx version
+H256genesis hash
+H256block hash
+
If the extensions could not be decoded as the standard set or not all +extensions blob is used, the Vault rejects this metadata version and adds error +into the error set.
+Metadata
+V14has extensions with both identifiers and properly described +types, and Vault decodes extensions as they are recorded in the metadata. For +this, +ExtrinsicMetadata+part of the metadata +RuntimeMetadataV14+is used. Vectorsigned_extensionsinExtrinsicMetadatais scanned twice, +first for types intyof the +SignedExtensionMetadata+and then for types inadditional_signedof theSignedExtensionMetadata. The +types, when resolved through the types database from the metadata, allow to cut +correct length blobs from the whole SCALE-encoded extensions blob and decode +them properly.If any of these small decodings fails, the metadata version gets rejected by +the Vault and an error is added to the error set. Same happens if after all +extensions are scanned, some part of extensions blob remains unused.
+There are some special extensions that must be treated separately. The +
+identifierinSignedExtensionMetadataandidentsegment of the type +Path+are used to trigger types interpretation as specially treated extensions. Each +identifieris encountered twice, once fortyscan, and once for +additional_signedscan. In some cases only one of those types has non-empty +content, in some cases it is both. To distinguish the two, the type-associated +path is used, which points to where the type is defined in Substrate code. +Type-associated path has priority over the identifier.Path triggers:
+| Path | Type is interpreted as | +| :- | :- | +|
+Era|Era| +|CheckNonce|Nonce| +|ChargeTransactionPayment| tip, gets displayed as balance with decimals and unit corresponding to the network specs |Identifier triggers, are used if the path trigger was not activated:
+| Identifier | Type, if not empty and if there is no path trigger, is interpreted as | Note | +| :- | :- | :- | +|
+CheckSpecVersion| metadata version | gets checked with the metatada version from the metadata | +|CheckTxVersion| tx version | | +|CheckGenesis| network genesis hash | must match the genesis hash that was cut from the tail of the transaction | +|CheckMortality| block hash | must match the genesis hash if the transaction is immortal;Erahas same identifier, but is distinguished by the path | +|CheckNonce| nonce | | +|ChargeTransactionPayment| tip, gets displayed as balance with decimals and unit corresponding to the network specs |If the extension is not a special case, it is displayed as normal parser +output and does not participate in deciding if the transaction could be signed.
+After all extensions are processed, the decoding must yield following +extensions:
+-
+
- exactly one
Era
+ - exactly one
Nonce<- this is not so currently, fix it
+ - exactly one
BlockHash
+ - exactly one
GenesisHash<- this is not so currently, fix it
+ - exactly one metadata version +
If the extension set is different, this results in Vault error for this +particular metadata version, this error goes into error set.
+The extensions in the metadata are checked on the metadata loading step, +long before any transactions are even produced. Metadata with incomplete +extensions causes a warning on
+load_metadataupdate generation step, and +another one when an update with such metadata gets loaded into Vault. +Nevertheless, such metadata loading into Vault is allowed, as there could be +other uses for metadata except signable transaction signing. Probably.If the metadata version in extensions does not match the metadata version +of the metadata used, this results in Vault error for this particular metadata +version, this error goes into error set.
+If the extensions are completely decoded, with correct set of the special +extensions and the metadata version from the extensions match the metadata +version of the metadata used, the extensions are considered correctly parsed, +and Vault can proceed to the call decoding.
+If all metadata entries from the Vault database were tested and no suitable +solution is found, Vault produces an error stating that all attempts to decode +extensions have failed. This could be used by variety of reasons (see above), +but so far the most common one observed was users having the metadata in Vault +not up-to-date with the metadata on chain. Thus, the error must have a +recommendation to update the metadata first.
+
+ -
+
Process the call data.
+After the metadata with correct version is established, it is used to parse +the call data itself. Each call begins with
+u8pallet index, this is the +decoding entry point.For
+V14metadata the correct pallet is found in the set of available ones +inpalletsfield of +RuntimeMetadataV14, +byindexfield in corresponding +PalletMetadata. +Thecallsfield of thisPalletMetadata, if it isSome(_), contains +PalletCallMetadata+that provides the available calls enum described intypesregistry of the +RuntimeMetadataV14. For each type in the registry, including this calls enum, +encoded data size is determined, and the decoding is done according to the type.For
+V12andV13metadata the correct pallet is also found by scanning +the available pallets and searching for correct pallet index. Then the call is +found using the call index (secondu8of the call data). Each call has +associated set of argument names and argument types, however, the argument type +is just a text identifier. The type definitions are not in the metadata and +transactions decoding requires supplemental types information. By default, the +Vault contains types information that was constructed for Westend when Westend +was still usingV13metadata and it was so far reasonably sufficient for +simple transactions parsing. If the Vault does not find the type information in +the database and has to decode the transaction usingV12orV13+metadata, error is produced, indicating that there are no types. Elsewise, for +each encountered argument type the encoded data size is determined, and the +decoding is done according to the argument type.There are types requiring special display:
+-
+
- calls (for cases when a call contains other calls) +
- numbers that are processed as the balances +
Calls in
+V14parsing are distinguished byCallinidentsegment of the +typePath. +Calls inV12andV13metadata are distinguished by any element of the set +of calls type identifiers in string argument type.At the moment the numbers that should be displayed as balance in +transactions with
+V14metadata are determined by the type nametype_nameof +the corresponding +Field+being:-
+
Balance
+T::Balance
+BalanceOf<T>
+ExtendedBalance
+BalanceOf<T, I>
+DepositBalance
+PalletBalanceOf<T>
+
Similar identifiers are used in
+V12andV13, the checked value is the +string argument type itself.There could be other instances when the number should be displayed as +balance. However, sometimes the balance is not the balance in the units +in the network specs, for example in the
+assetspallet. See issue +#1050 and comments +there for details.If no errors were encountered while parsing and all call data was used in +the process, the transaction is considered parsed and is displayed to the user, +either ready for signing (if all other checks have passed) or as read-only.
+
+ -
+
If the user chooses to sign the transaction, the Vault produces QR code with +signature, that should be read back into the hot side. As soon as the signature +QR code is generated, the Vault considers the transaction signed.
+All signed transactions are entered in the history log, and could be seen +and decoded again from the history log. Transactions not signed by the user do +not go in the history log.
+If the key used for the transaction is passworded, user has three attempts +to enter the password correctly. Each incorrect password entry is reflected in +the history.
+In the time interval between Vault displaying the parsed transaction and +the user approving it, the transaction details needed to generate the signature +and history log details are temporarily stored in the database. The temporary +storage gets cleared each time before and after use. Vault extracts the stored +transaction data only if the database checksum stored in navigator state is +same as the current checksum of the database. If the password is entered +incorrectly, the database is updated with "wrong password" history entry, and +the checksum in the state gets updated accordingly. Eventually, all transaction +info can and will be moved into state itself and temporary storage will not be +used.
+
+
Example
+Alice makes transfer to Bob in Westend network.
+Transaction:
+530102d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27da40403008eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a480700e8764817b501b8003223000005000000e143f23803ac50e8f6f8e62695d1ce9e4e1d68aa36c1cd2cfd15340213f3423e538a7d7a0ac17eb6dd004578cb8e238c384a10f57c999a3fa1200409cd9b3f33e143f23803ac50e8f6f8e62695d1ce9e4e1d68aa36c1cd2cfd15340213f3423e
| Part | Meaning | Byte position |
|---|---|---|
53 | Substrate-related content | 0 |
01 | Sr25519 encryption algorithm | 1 |
02 | Transaction | 2 |
d435..a27d1 | Alice public key | 3..=34 |
a404..48172 | SCALE-encoded call data | 35..=76 |
a4 | Compact call data length, 41 | 35 |
0403..48173 | Call data | 36..=76 |
04 | Pallet index 4 in metadata, entry point for decoding | 36 |
b501..3f334 | Extensions | 77..=153 |
e143..423e5 | Westend genesis hash | 154..=185 |
1
+
+d43593c715fdd31c61141abd04a99fd6822c8558854ccde39a5684e7a56da27d
2
+
+a40403008eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a480700e8764817
3
+
+0403008eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a480700e8764817
4
+
+b501b8003223000005000000e143f23803ac50e8f6f8e62695d1ce9e4e1d68aa36c1cd2cfd15340213f3423e538a7d7a0ac17eb6dd004578cb8e238c384a10f57c999a3fa1200409cd9b3f33
5
+
+e143f23803ac50e8f6f8e62695d1ce9e4e1d68aa36c1cd2cfd15340213f3423e
Call content is parsed using Westend metadata, in this particular case westend9010
+| Call part | Meaning |
|---|---|
04 | Pallet index 4 (Balances) in metadata, entry point for decoding |
03 | Method index 3 in pallet 4 (transfer_keep_alive), search in metadata what the method contains. Here it is MultiAddress for transfer destination and Compact(u128) balance. |
00 | Enum variant in MultiAddress, AccountId |
8eaf..6a486 | Associated AccountId data, Bob public key |
0700e8764817 | Compact(u128) balance. Amount paid: 100000000000 or, with Westend decimals and unit, 100.000000000 mWND. |
6
+
+8eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a48
Extensions content
+| Extensions part | Meaning |
|---|---|
b501 | Era: phase 27, period 64 |
b8 | Nonce: 46 |
00 | Tip: 0 pWND |
32230000 | Metadata version: 9010 |
05000000 | Tx version: 5 |
e143..423e7 | Westend genesis hash |
538a..3f338 | Block hash |
7
+
+e143f23803ac50e8f6f8e62695d1ce9e4e1d68aa36c1cd2cfd15340213f3423e
8
+
+538a7d7a0ac17eb6dd004578cb8e238c384a10f57c999a3fa1200409cd9b3f33
Message
+Message has the following structure:
+| prelude | +public key | +[u8] slice |
+ network genesis hash | +
[u8] slice is represented as String if all bytes are valid UTF-8. If not all
+bytes are valid UTF-8, the Vault produces an error.
It is critical that the message payloads are always clearly distinguishable from +the transaction payloads, i.e. it is never possible to trick user to sign +transaction posing as a message.
+Current proposal is to enable message signing only with Sr25519 encryption +algorithm, with designated signing context, different from the signing context +used for transactions signing.
+Bulk transactions
+Bulk transactions is a SCALE-encoded TransactionBulk structure that consists of concatenated Vec<u8> transactions.
Bulking is a way to sign multiple translations at once and reduce the number of QR codes to scan.
+Bulk transactions are processed in exactly the same way as single transactions.
+Update
+Update has following general structure:
+| prelude | verifier public key (if signed) | update payload | signature (if signed) | reserved tail | +
Note that the verifier public key and signature parts appear only in signed
+uploads. Preludes [0x53, 0xff, 0x<payload code>] are followed by the update
+payload.
Every time user receives an unsigned update, the Vault displays a warning that +the update is not verified. Generally, the use of unsigned updates is +discouraged.
+For update signing it is recommended to use a dedicated key, not used for +transactions. This way, if the signed data was not really the update data, but +something else posing as the update data, the signature produced could not do +any damage.
+| Encryption | Public key length, bytes | Signature length, bytes |
|---|---|---|
| Ed25519 | 32 | 64 |
| Sr25519 | 32 | 64 |
| Ecdsa | 33 | 65 |
| no encryption | 0 | 0 |
reserved tail currently is not used and is expected to be empty. It could be
+used later if the multisignatures are introduced for the updates. Expecting
+reserved tail in update processing is done to keep code continuity in case
+multisignatures introduction ever happens.
Because of the reserved tail, the update payload length has to be always
+exactly declared, so that the update payload part could be cut correctly from
+the update.
Detailed description of the update payloads and form in which they are used in
+update itself and for generating update signature, could be found in Rust module
+definitions::qr_transfers.
add_specs update payload, payload code c1
+Introduces a new network to Vault, i.e. adds network specs to the Vault +database.
+Update payload is ContentAddSpecs in to_transfer() form, i.e. double
+SCALE-encoded NetworkSpecsToSend (second SCALE is to have the exact payload
+length).
Payload signature is generated for SCALE-encoded NetworkSpecsToSend.
Network specs are stored in dedicated SPECSTREE tree of the Vault database.
+Network specs identifier is NetworkSpecsKey, a key built from encryption used
+by the network and the network genesis hash. There could be networks with
+multiple encryption algorithms supported, thus the encryption is part of the
+key.
Some elements of the network specs could be slightly different for networks with +the same genesis hash and different encryptions. There are:
+-
+
-
+
Invariant specs, identical between all different encryptions:
+-
+
- name (network name as it appears in metadata) +
- base58 prefix +
The reason is that the network name is and the base58 prefix can be a part +of the network metadata, and the network metadata is not encryption-specific.
+
+ -
+
Specs static for given encryption, that should not change over time once set:
+-
+
- decimals +
- unit +
To replace these, the user would need to remove the network and add it +again, i.e. it won't be possible to do by accident.
+
+ -
+
Flexible display-related and convenience specs, that can change and could be +changed by simply loading new ones over the old ones:
+-
+
- color and secondary color (both currently not used, but historically are +there and may return at some point) +
- logo +
- path (default derivation path for network,
//<network_name>)
+ - title (network title as it gets displayed in the Vault) +
+
load_metadata update payload, payload code 80
+Loads metadata for a network already known to Vault, i.e. for a network with +network specs in the Vault database.
+Update payload is ContentLoadMeta in to_transfer() form, and consists of
+concatenated SCALE-encoded metadata Vec<u8> and network genesis hash (H256,
+always 32 bytes).
Same blob is used to generate the signature.
+Network metadata is stored in dedicated METATREE tree of the Vault database.
+Network metadata identifier in is MetaKey, a key built from the network name
+and network metadata version.
Metadata suitable for Vault
+Network metadata that can get into Vault and can be used by Vault only if it +complies with following requirements:
+-
+
- metadata vector starts with
b"meta"prelude
+ - part of the metadata vector after
b"meta"prelude is decodable asRuntimeMetadata
+ RuntimeMetadataversion of the metadata isV12,V13orV14
+- Metadata has
Systempallet
+ - There is
Versionconstant inSystempallet
+ Versionis decodable asRuntimeVersion
+- If the metadata contains base58 prefix, it must be decodable as
u16oru8
+
Additionally, if the metadata V14 is received, its associated extensions will
+be scanned and user will be warned if the extensions are incompatible with
+transactions signing.
Also in case of the metadata V14 the type of the encoded data stored in the
+Version constant is also stored in the metadata types registry and in
+principle could be different from RuntimeVersion above. At the moment, the
+type of the Version is hardcoded, and any other types would not be processed
+and would get rejected with an error.
load_types update payload, payload code 81
+Load types information.
+Type information is needed to decode transactions made in networks with metadata
+RuntimeMetadata version V12 or V13.
Most of the networks are already using RuntimeMetadata version V14, which has +types information incorporated in the metadata itself.
+The load_types update is expected to become obsolete soon.
Update payload is ContentLoadTypes in to_transfer(), i.e. double
+SCALE-encoded Vec<TypeEntry> (second SCALE is to have the exact payload
+length).
Payload signature is generated for SCALE-encoded Vec<TypeEntry>.
Types information is stored in SETTREE tree of the Vault database, under key
+TYPES.
Verifiers
+Vault can accept both verified and non-verified updates, however, information +once verified can not be replaced or updated by a weaker verifier without full +Vault reset.
+A verifier could be Some(_) with corresponding public key inside or None.
+All verifiers for the data follow trust on first use principle.
Vault uses:
+-
+
- a single general verifier +
- a network verifier for each of the networks introduced to the Vault +
General verifier information is stored in SETTREE tree of the Vault database,
+under key GENERALVERIFIER. General verifier is always set to a value, be it
+Some(_) or None. Removing the general verifier means setting it to None.
+If no general verifier entry is found in the database, the database is
+considered corrupted and the Vault must be reset.
Network verifier information is stored in dedicated VERIFIERS tree of the
+Vault database. Network verifier identifier is VerifierKey, a key built from
+the network genesis hash. Same network verifier is used for network specs with
+any encryption algorithm and for network metadata. Network verifier could be
+valid or invalid. Valid network verifier could be general or custom. Verifiers
+installed as a result of an update are always valid. Invalid network verifier
+blocks the use of the network unless the Vault is reset, it appears if user
+marks custom verifier as no longer trusted.
Updating verifier could cause some data verified by the old verifier to be +removed, to avoid confusion regarding which verifier has signed the data +currently stored in the database. The data removed is called "hold", and user +receives a warning if accepting new update would cause hold data to be removed.
+General verifier
+General verifier is the strongest and the most reliable verifier known to the +Vault. General verifier could sign all kinds of updates. By default the Vault +uses Parity-associated key as general verifier, but users can remove it and set +their own. There could be only one general verifier at any time.
+General verifier could be removed only by complete wipe of the Vault, through
+Remove general certificate button in the Settings. This will reset the Vault
+database to the default content and set the general verifier as None, that
+will be updated to the first verifier encountered by the Vault.
Expected usage for this is that the user removes old general verifier and +immediately afterwards loads an update from the preferred source, thus setting +the general verifier to the user-preferred value.
+General verifier can be updated from None to Some(_) by accepting a verified
+update. This would result in removing "general hold", i.e.:
-
+
- all network data (network specs and metadata) for the networks for which the +verifier is set to the general one +
- types information +
General verifier could not be changed from Some(_) to another, different
+Some(_) by simply accepting updates.
Note that if the general verifier is None, none of the custom verifiers could
+be Some(_). Similarly, if the verifier is recorded as custom in the database,
+its value can not be the same as the value of the general verifier. If found,
+those situations indicate the database corruption.
Custom verifiers
+Custom verifiers could be used for network information that was verified, but +not with the general verifier. There could be as many as needed custom verifiers +at any time. Custom verifier is considered weaker than the general verifier.
+Custom verifier set to None could be updated to:
-
+
- Another custom verifier set to
Some(_)
+ - General verifier +
Custom verifier set to Some(_) could be updated to general verifier.
These verifier updates can be done by accepting an update signed by a new +verifier.
+Any of the custom network verifier updates would result in removing "hold", i.e. +all network specs entries (for all encryption algorithms on file) and all +network metadata entries.
+Common update processing sequence:
+-
+
-
+
Cut the QR data and get:
+-
+
- encryption used by verifier (single
u8from prelude)
+ - (only if the update is signed, i.e. the encryption is not
0xff) +update verifier public key, its length matching the encryption (32 or +33u8immediately after the prelude)
+ - concatenated update payload, verifier signature (only if the update is +signed) and reserved tail. +
If the data length is insufficient, Vault produces an error and suggests to +load non-damaged update.
+
+ - encryption used by verifier (single
-
+
Using the payload type from the prelude, determine the update payload length +and cut payload from the concatenated verifier signature and reserved tail.
+If the data length is insufficient, Vault produces an error and suggests to +load non-damaged update.
+
+ -
+
(only if the update is signed, i.e. the encryption is not
+0xff) +Cut verifier signature, its length matching the encryption (64 or 65u8+immediately after the update payload). Remaining data is reserved tail, +currently it is not used.If the data length is insufficient, Vault produces an error and suggests to +load non-damaged update.
+
+ -
+
Verify the signature for the payload. If this fails, Vault produces an error +indicating that the update has invalid signature.
+
+
add_specs processing sequence
+-
+
-
+
Update payload is transformed into
+ContentAddSpecsand the incoming +NetworkSpecsToSendare retrieved, or the Vault produces an error indicating +that theadd_specspayload is damaged.
+ -
+
Vault checks that there is no change in invariant specs occurring.
+If there are entries in the
+SPECSTREEof the Vault database with same +genesis hash as in newly received specs (the encryption not necessarily +matches), the Vault checks that the name and base58 prefix in the received +specs are same as in the specs already in the Vault database.
+ -
+
Vault checks the verifier entry for the received genesis hash.
+If there are no entries, i.e. the network is altogether new to the Vault, +the specs could be added into the database. During the same database transaction +the network verifier is set up:
+|
+add_specsupdate verification | General verifier in Vault database | Action | +| :- | :- | :- | +| unverified,0xffupdate encryption code |NoneorSome(_)| (1) set network verifier to custom,None(regardless of the general verifier); (2) add specs | +| verified bya|None| (1) set network verifier to general; (2) set general verifier toSome(a), process the general hold; (3) add specs | +| verified bya|Some(b)| (1) set network verifier to custom,Some(a); (2) add specs | +| verified bya|Some(a)| (1) set network verifier to general; (2) add specs |If there are entries, i.e. the network was known to the Vault at some +point after the last Vault reset, the network verifier in the database and the +verifier of the update are compared. The specs could be added in the database if
+-
+
- there are no verifier mismatches encountered (i.e. verifier same or +stronger) +
- received data causes no change in specs static for encryption +
- the specs are not yet in the database in exactly same form +
Note that if the exactly same specs as already in the database are received +with updated verifier and the user accepts the update, the verifier will get +updated and the specs will stay in the database.
+|
+add_specsupdate verification | Network verifier in Vault database | General verifier in Vault database | Action | +| :- | :- | :- | :- | +| unverified,0xffupdate encryption code | custom,None|None| accept specs if good | +| unverified,0xffupdate encryption code | custom,None|Some(a)| accept specs if good | +| unverified,0xffupdate encryption code | general |None| accept specs if good | +| unverified,0xffupdate encryption code | general |Some(a)| error: update should have been signed bya| +| verified bya| custom,None|None| (1) change network verifier to general, process the network hold; (2) set general verifier toSome(a), process the general hold; (3) accept specs if good | +| verified bya| custom,None|Some(a)| (1) change network verifier to general, process the network hold; (2) accept specs if good | +| verified bya| custom,None|Some(b)| (1) change network verifier to custom,Some(a), process the network hold; (2) accept specs if good | +| verified bya| custom,Some(a)|Some(b)| accept specs if good | +| verified bya| custom,Some(b)|Some(a)| (1) change network verifier to general, process the network hold; (2) accept specs if good | +| verified bya| custom,Some(b)|Some(c)| error: update should have been signed byborc|Before the
+NetworkSpecsToSendare added in theSPECSTREE, they get +transformed intoNetworkSpecs, and have theorderfield (display order in +Vault network lists) added. Each new network specs entry gets added in the end +of the list.
+
load_meta processing sequence
+-
+
-
+
Update payload is transformed into
+ContentLoadMeta, from which the metadata +and the genesis hash are retrieved, or the Vault produces an error indicating +that theload_metadatapayload is damaged.
+ -
+
Vault checks that the received metadata fulfills all Vault metadata +requirements outlined above. Otherwise an +error is produced indicating that the received metadata is invalid.
+Incoming
+MetaValuesare produced, that contain network name, network +metadata version and optional base58 prefix (if it is recorded in the metadata).
+ -
+
Network genesis hash is used to generate
+VerifierKeyand check if the +network has an established network verifier in the Vault database. If there +is no network verifier associated with genesis hash, an error is produced, +indicating that the network metadata could be loaded only for networks +introduced to Vault.
+ -
+
+SPECSTREEtree of the Vault database is scanned in search of entries with +genesis hash matching the one received in payload.Vault accepts
+load_metadataupdates only for the networks that have at +least one network specs entry in the database.Note that if the verifier in step (3) above is found, it not necessarily +means that the specs are found (for example, if a network verified by general +verifier was removed by user).
+If the specs are found, the Vault checks that the network name and, if +present, base58 prefix from the received metadata match the ones in network +specs from the database. If the values do not match, the Vault produces an +error.
+
+ -
+
Vault compares the verifier of the received update and the verifier for the +network from the database. The update verifier must be exactly the same as the +verifier already in the database. If there is mismatch, Vault produces an +error, indication that the
+load_metadataupdate for the network must be signed +by the specified verifier (general or custom) or unsigned.
+ -
+
If the update has passed all checks above, the Vault searches for the +metadata entry in the
+METATREEof the Vault database, using network name and +version from update to produceMetaKey.If the key is not found in the database, the metadata could be added.
+If the key is found in the database and metadata is exactly the same, +the Vault produces an error indicating that the metadata is already in the +database. This is expected to be quite common outcome.
+If the key is found in the database and the metadata is different, the +Vault produces an error. Metadata must be not acceptable. This situation can +occur if there was a silent metadata update or if the metadata is corrupted.
+
+
load_types processing sequence
+-
+
-
+
Update payload is transformed into
+ContentLoadTypes, from which the types +description vectorVec<TypeEntry>is retrieved, or the Vault produces an +error indicating that theload_typespayload is damaged.
+ -
+
+load_typesupdates must be signed by the general verifier.|
+load_typesupdate verification | General verifier in Vault database | Action | +| :- | :- | :- | +| unverified,0xffupdate encryption code |None| load types if the types are not yet in the database | +| verified bya|None| (1) set general verifier toSome(a), process the general hold; (2) load types, warn if the types are the same as before | +| verified bya|Some(b)| reject types, error indicates thatload_typesrequires general verifier signature | +| verified bya|Some(a)| load types if the types are not yet in the database |If the
+load_typesverifier is same as the general verifier in the database +and the types are same as the types in the database, the Vault produces an +error indicating that the types are already known.Each time the types are loaded, the Vault produces a warning.
+load_types+is rare and quite unexpected operation.
+
Derivations import, payload code de
+Derivations import has the following structure:
+| prelude | derivations import payload | +
Derivations import payload is a SCALE-encoded ExportAddrs structure.
It does not contain any private keys or seed phrases.
+ExportAddrs structure holds the following information about each key:
-
+
- name and public key of the seed the derived key belongs to +
ss58address of the derived key (h160for ethereum based chains)
+- derivation path +
- encryption type +
- genesis hash of the network the key is used in +
When processing derivations import, all data after prelude is transformed into
+ExportAddrs. Network genesis hash, encryption and derivations set are
+derived from it, or the Vault produces a warning indicating that the derivation
+import payload is corrupted.
Vault checks that the network for which the derivations are imported has +network specs in the Vault database. If not, a warning is produced.
+Vault checks that the derivation set contains only valid derivations. If any +derivation is unsuitable, a warning is produced indicating this.
+If the user accepts the derivations import, Vault generates a key for each valid +derivation.
+If one of the derived keys already exists, it gets ignored, i.e. no error is +produced.
+If there are two derivations with identical path within the payload, only one +derived key is created.
+ +
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/editor.js b/editor.js
new file mode 100644
index 0000000000..464790c499
--- /dev/null
+++ b/editor.js
@@ -0,0 +1,29 @@
+"use strict";
+window.editors = [];
+(function(editors) {
+ if (typeof(ace) === 'undefined' || !ace) {
+ return;
+ }
+
+ Array.from(document.querySelectorAll('.editable')).forEach(function(editable) {
+ let display_line_numbers = window.playground_line_numbers || false;
+
+ let editor = ace.edit(editable);
+ editor.setOptions({
+ highlightActiveLine: false,
+ showPrintMargin: false,
+ showLineNumbers: display_line_numbers,
+ showGutter: display_line_numbers,
+ maxLines: Infinity,
+ fontSize: "0.875em" // please adjust the font size of the code in general.css
+ });
+
+ editor.$blockScrolling = Infinity;
+
+ editor.getSession().setMode("ace/mode/rust");
+
+ editor.originalCode = editor.getValue();
+
+ editors.push(editor);
+ });
+})(window.editors);
diff --git a/elasticlunr.min.js b/elasticlunr.min.js
new file mode 100644
index 0000000000..94b20dd2ef
--- /dev/null
+++ b/elasticlunr.min.js
@@ -0,0 +1,10 @@
+/**
+ * elasticlunr - http://weixsong.github.io
+ * Lightweight full-text search engine in Javascript for browser search and offline search. - 0.9.5
+ *
+ * Copyright (C) 2017 Oliver Nightingale
+ * Copyright (C) 2017 Wei Song
+ * MIT Licensed
+ * @license
+ */
+!function(){function e(e){if(null===e||"object"!=typeof e)return e;var t=e.constructor();for(var n in e)e.hasOwnProperty(n)&&(t[n]=e[n]);return t}var t=function(e){var n=new t.Index;return n.pipeline.add(t.trimmer,t.stopWordFilter,t.stemmer),e&&e.call(n,n),n};t.version="0.9.5",lunr=t,t.utils={},t.utils.warn=function(e){return function(t){e.console&&console.warn&&console.warn(t)}}(this),t.utils.toString=function(e){return void 0===e||null===e?"":e.toString()},t.EventEmitter=function(){this.events={}},t.EventEmitter.prototype.addListener=function(){var e=Array.prototype.slice.call(arguments),t=e.pop(),n=e;if("function"!=typeof t)throw new TypeError("last argument must be a function");n.forEach(function(e){this.hasHandler(e)||(this.events[e]=[]),this.events[e].push(t)},this)},t.EventEmitter.prototype.removeListener=function(e,t){if(this.hasHandler(e)){var n=this.events[e].indexOf(t);-1!==n&&(this.events[e].splice(n,1),0==this.events[e].length&&delete this.events[e])}},t.EventEmitter.prototype.emit=function(e){if(this.hasHandler(e)){var t=Array.prototype.slice.call(arguments,1);this.events[e].forEach(function(e){e.apply(void 0,t)},this)}},t.EventEmitter.prototype.hasHandler=function(e){return e in this.events},t.tokenizer=function(e){if(!arguments.length||null===e||void 0===e)return[];if(Array.isArray(e)){var n=e.filter(function(e){return null===e||void 0===e?!1:!0});n=n.map(function(e){return t.utils.toString(e).toLowerCase()});var i=[];return n.forEach(function(e){var n=e.split(t.tokenizer.seperator);i=i.concat(n)},this),i}return e.toString().trim().toLowerCase().split(t.tokenizer.seperator)},t.tokenizer.defaultSeperator=/[\s\-]+/,t.tokenizer.seperator=t.tokenizer.defaultSeperator,t.tokenizer.setSeperator=function(e){null!==e&&void 0!==e&&"object"==typeof e&&(t.tokenizer.seperator=e)},t.tokenizer.resetSeperator=function(){t.tokenizer.seperator=t.tokenizer.defaultSeperator},t.tokenizer.getSeperator=function(){return t.tokenizer.seperator},t.Pipeline=function(){this._queue=[]},t.Pipeline.registeredFunctions={},t.Pipeline.registerFunction=function(e,n){n in t.Pipeline.registeredFunctions&&t.utils.warn("Overwriting existing registered function: "+n),e.label=n,t.Pipeline.registeredFunctions[n]=e},t.Pipeline.getRegisteredFunction=function(e){return e in t.Pipeline.registeredFunctions!=!0?null:t.Pipeline.registeredFunctions[e]},t.Pipeline.warnIfFunctionNotRegistered=function(e){var n=e.label&&e.label in this.registeredFunctions;n||t.utils.warn("Function is not registered with pipeline. This may cause problems when serialising the index.\n",e)},t.Pipeline.load=function(e){var n=new t.Pipeline;return e.forEach(function(e){var i=t.Pipeline.getRegisteredFunction(e);if(!i)throw new Error("Cannot load un-registered function: "+e);n.add(i)}),n},t.Pipeline.prototype.add=function(){var e=Array.prototype.slice.call(arguments);e.forEach(function(e){t.Pipeline.warnIfFunctionNotRegistered(e),this._queue.push(e)},this)},t.Pipeline.prototype.after=function(e,n){t.Pipeline.warnIfFunctionNotRegistered(n);var i=this._queue.indexOf(e);if(-1===i)throw new Error("Cannot find existingFn");this._queue.splice(i+1,0,n)},t.Pipeline.prototype.before=function(e,n){t.Pipeline.warnIfFunctionNotRegistered(n);var i=this._queue.indexOf(e);if(-1===i)throw new Error("Cannot find existingFn");this._queue.splice(i,0,n)},t.Pipeline.prototype.remove=function(e){var t=this._queue.indexOf(e);-1!==t&&this._queue.splice(t,1)},t.Pipeline.prototype.run=function(e){for(var t=[],n=e.length,i=this._queue.length,o=0;n>o;o++){for(var r=e[o],s=0;i>s&&(r=this._queue[s](r,o,e),void 0!==r&&null!==r);s++);void 0!==r&&null!==r&&t.push(r)}return t},t.Pipeline.prototype.reset=function(){this._queue=[]},t.Pipeline.prototype.get=function(){return this._queue},t.Pipeline.prototype.toJSON=function(){return this._queue.map(function(e){return t.Pipeline.warnIfFunctionNotRegistered(e),e.label})},t.Index=function(){this._fields=[],this._ref="id",this.pipeline=new t.Pipeline,this.documentStore=new t.DocumentStore,this.index={},this.eventEmitter=new t.EventEmitter,this._idfCache={},this.on("add","remove","update",function(){this._idfCache={}}.bind(this))},t.Index.prototype.on=function(){var e=Array.prototype.slice.call(arguments);return this.eventEmitter.addListener.apply(this.eventEmitter,e)},t.Index.prototype.off=function(e,t){return this.eventEmitter.removeListener(e,t)},t.Index.load=function(e){e.version!==t.version&&t.utils.warn("version mismatch: current "+t.version+" importing "+e.version);var n=new this;n._fields=e.fields,n._ref=e.ref,n.documentStore=t.DocumentStore.load(e.documentStore),n.pipeline=t.Pipeline.load(e.pipeline),n.index={};for(var i in e.index)n.index[i]=t.InvertedIndex.load(e.index[i]);return n},t.Index.prototype.addField=function(e){return this._fields.push(e),this.index[e]=new t.InvertedIndex,this},t.Index.prototype.setRef=function(e){return this._ref=e,this},t.Index.prototype.saveDocument=function(e){return this.documentStore=new t.DocumentStore(e),this},t.Index.prototype.addDoc=function(e,n){if(e){var n=void 0===n?!0:n,i=e[this._ref];this.documentStore.addDoc(i,e),this._fields.forEach(function(n){var o=this.pipeline.run(t.tokenizer(e[n]));this.documentStore.addFieldLength(i,n,o.length);var r={};o.forEach(function(e){e in r?r[e]+=1:r[e]=1},this);for(var s in r){var u=r[s];u=Math.sqrt(u),this.index[n].addToken(s,{ref:i,tf:u})}},this),n&&this.eventEmitter.emit("add",e,this)}},t.Index.prototype.removeDocByRef=function(e){if(e&&this.documentStore.isDocStored()!==!1&&this.documentStore.hasDoc(e)){var t=this.documentStore.getDoc(e);this.removeDoc(t,!1)}},t.Index.prototype.removeDoc=function(e,n){if(e){var n=void 0===n?!0:n,i=e[this._ref];this.documentStore.hasDoc(i)&&(this.documentStore.removeDoc(i),this._fields.forEach(function(n){var o=this.pipeline.run(t.tokenizer(e[n]));o.forEach(function(e){this.index[n].removeToken(e,i)},this)},this),n&&this.eventEmitter.emit("remove",e,this))}},t.Index.prototype.updateDoc=function(e,t){var t=void 0===t?!0:t;this.removeDocByRef(e[this._ref],!1),this.addDoc(e,!1),t&&this.eventEmitter.emit("update",e,this)},t.Index.prototype.idf=function(e,t){var n="@"+t+"/"+e;if(Object.prototype.hasOwnProperty.call(this._idfCache,n))return this._idfCache[n];var i=this.index[t].getDocFreq(e),o=1+Math.log(this.documentStore.length/(i+1));return this._idfCache[n]=o,o},t.Index.prototype.getFields=function(){return this._fields.slice()},t.Index.prototype.search=function(e,n){if(!e)return[];e="string"==typeof e?{any:e}:JSON.parse(JSON.stringify(e));var i=null;null!=n&&(i=JSON.stringify(n));for(var o=new t.Configuration(i,this.getFields()).get(),r={},s=Object.keys(e),u=0;u
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Vault structure
+Architectural structure
+On top level, Vault consists of following parts:
+-
+
- Rust backend core +
- FFI interface +
- Native frontend +
- Database +
Rust backend
+There are 3 actual endpoints in rust folder: signer, which is source of
+library used for Vault itself; generate_message, which is used to update
+Vault repo with new built-in network information and to generate
+over-the-airgap updates; and qr_reader_pc which is a minimalistic app to parse
+qr codes that we had to write since there was no reasonably working alternative.
Sub-folders of the rust folder:
-
+
constants— constant values defined for the whole workspace.
+db_handling— all database-related operations for Vault and +generate_messagetool. Most of the business logic is contained here.
+defaults— built-in and test data for database
+definitions— objects used across the workspace are defined here
+files— contains test files and is used for build and update generation +processes. Most contents are gitignored.
+generate_message— tool to generate over-the-airgap updates and maintain +network info database on hot side
+navigator— navigation for Vault app; it is realized in rust to unify app +behavior across the platforms
+parser- parses signable transactions. This is internal logic for +transaction_parsingthat is used when signable transaction is identified, but +it could be used as a standalone lib for the same purpose.
+printing_balance— small lib to render tokens with proper units
+qr_reader_pc— small standalone PC app to parse QR codes in Vault +ecosystem. Also is capable of parsing multiframe payloads (theoretically, in +practice it is not feasible due to PC webcam low performance)
+qr_reader_phone— logic to parse QR payloads in Vault
+qrcode_rtx— multiframe erasure-encoded payload generator for signer update +QR animation.
+qrcode_static— generation of static qr codes used all over the workspace
+signer— FFI interface crate to generate bindings that bridge native code +and rust backend
+transaction_parsing— high-level parser for all QR payloads sent into Vault
+transaction_signing— all operations that could be performed when user +accepts payload parsed withtransaction_parsing
+
FFI interface
+For interfacing rust code and native interface we use
+uniffi framework. It is a framework
+intended to aid building cross-platform software in Rust especially for the
+cases of re-using components written in Rust in the smartphone application
+development contexts. Other than Vault itself one of the most notable users of
+the uniffi framework are the Mozilla Application Services
uniffi framework provides a way for the developer to define a clear and a
+typesafe FFI interface between components written in Rust and languages such
+as Kotlin and Swift. This approach leads to a much more robust architecture
+than implementing a homegrown FFI with, say, passing JSON-serialized data back
+and forth between Kotlin and Rust code. Here is why.
Suppose the application needs to pass a following structure through FFI from
+Kotlin to Rust or back:
#[derive(Serialize, Deserialize)]
+ struct Address { street:String, city: String, }This would mean that on the Kotlin side of the FFI there would have to be some
+way of turning this type from JSON into a Kotlin type. It may be some sort of
+scheme or even a manual JSON value-by-key data extraction.
Now suppose this struct is changed by adding and removing some fields:
+#[derive(Serialize, Deserialize)]
+ struct Address { country: String, city: String, index: usize, }After this change on a Rust-side the developer would have to remember to
+reflect these changes on the Kotlin and Swift sides and if that is not done
+there is a chance that it will not be caught in build-time by CI. It is quite
+hard to remember everything and having a guarantee that such things would be
+caught at compile time is much better than not having this sort of guarantee.
+One of the things uniffi solves is exactly this: it provides compile-time
+guarantees of typesafety.
The other concern with the JSON serialization approach is performance. As long
+as small objects are transferred back and forth it is no trouble encoding them
+into strings. But suppose the application requires transferring bigger blobs of
+binary data such as png images or even some metadata files. Using JSON would
+force the developer to encode such blobs as Strings before passing them into
+FFI and decoding them back into binary blobs on the other side of the FFI.
+uniffi helps to avoid this also.
Native frontend
+Native frontends are made separately for each supported platform. To keep things +uniform, interfaces are made as simple as possible and as much code is written +in unified Rust component, as possible. Yet, platform-specific functions, +including runtime management and threading, are also accessed through native +framework. The structure of native frontend follows modern (2022) reactive +design pattern of View-Action-Model triad. Thus, all backend is located in data +model section, along with few native business logic components.
+It is important to note, that native navigation is not used, as due to +subtle differences in its seemingly uniform design across platforms. Navigation +is instead implemented on Rust side and, as an additional advantage, is tested +there at lower computational cost for CI pipelines.
+Database
+For storage of all data except secrets, a sled database is used. Choice of db +was based on its lightweightness, reliability, portability.
+ +Functional structure
+Vault has the following systems:
+-
+
- Secure key management +
- Signing +
- Transaction parsing +
- Transaction visualization +
- Airgap data transfer +
- Airgap updating +
- Network detector +
- Logging +
- Self-signing updating capability +
- UI +
These systems are located in different parts the app and some of them rely on +hot-side infrastructure. The general design goal was to isolate as much as +possible in easily maintainable Rust code and keep only necessary functions in +native side. Currently, those include:
+-
+
- Hardware secret storage: we rely on hardware designer's KMS in accordance with +best practices +
- Network detector: network operations are limited by OS and we try to keep +network access permissions for the app to minimum while still maintaining +simple breach detection +
- Camera: currently image capture and recognition systems implementations in +native environments by far surpass 3rd party ones. This might change in the +future, but at least image capture will be managed by OS to maintain platform +compatibility. +
- UI: we use native frameworks and components for rendering and user interaction +for best look and feel of the app. +
Secure key management
+Keypairs used in Vault are generated from secret seed phrase, derivation path +and optional secret password, in accordance with specifications described in +subkey manual using code imported directly from substrate codebase for best +conformance.
+Secret seed phrase storage
+Secret seed phrase is stored as a string in devices original KMS. It is +symmetrically encrypted with a strong key that either is stored in a +hardware-protected keyring or uses biometric data (in case of legacy android +devices without strongbox system). Secrets access is managed by operating +system's built-in authorization interface. Authorization is required for +creation of seeds, access to seeds and removal of seeds. One particular special +case is addition of the first seed on iOS platform, that does not trigger +authorization mechanism as the storage is empty at this moment; this is in +agreement with iOS key management system design and potentially leads to a +threat of attacker replacing a single key by adding it to empty device; this +attack is countered by authorization on seed removal.
+Thus, secret seeds source of truth is KMS. To synchronize the rest of the app,
+list of seed identifiers is sent to backend on app startup and on all events
+related to changes in this list by calling update_seed_names(Vec<String>).
Random seed generator and seed recovery tools are implemented in Rust. These +are the only 2 cases where seed originates not in KMS.
+Derivation path management
+The most complex part of key management is storage of derivation strings and +public keys. Improper handling here may lead to user's loss of control over +their assets.
+Key records are stored as strings in database associated with secret seed +identifiers, crypto algorithm, and list of allowed networks. Public key and its +cryptographic algorithm are used to deterministically generate database record +key - thus by design distinct key entries directly correspond to addresses on +chain.
+Creation of new records requires generation of public keys through derivation +process, thus secret seed should be queried - so adding items to this database +requires authentication.
+Substrate keys could be natively used across all networks supporting their +crypto algorithm. This may lead to accidental re-use of keys; thus it is not +forbidden by the app, but networks are isolated unless user explicitly expresses +desire to enable key in given network. From user side, it is abstracted into +creation of independent addresses; however, real implementation stores addresses +with public keys as storage keys and thus does not distinguish between networks. +To isolate networks, each key stores a field with a list of allowed networks, +and when user "creates" address with the same pubkey as already existing one, it +is just another network added to the list of networks.
+Keys could be imported through QR code created by generate_message tool
+(instructions). A
+plaintext newline-separated list of derivations should be supplied to the tool
+along with network identifier; the import thus is bound to certain network,
+however, it is not bound to any particular seed - user can select any of
+created seeds and, after authorization, create keys with given paths. Bulk
+import of password-protected keys is forbidden at the moment.
Optional password
+Optional password (part of derivation path after ///) is never stored, only
+addresses that have password in their derivation path are marked. Thus, password
+is queried every time it is needed with a tool separate from OS authentication
+interface, but together with authentication screen, as password is always used
+with a secret seed phrase.
Memory safety in secure key management
+All memory handles by native framework relies on native framework's memory
+protection mechanisms (JVM virtualization and Swift isolation and garbage
+collection). However, when secrets are processed in Rust, no inherent designed
+memory safety features are available. To prevent secrets remaining in memory
+after their use, zeroize library is used. Also, describe string destruction
+protocol or fix it
Signing
+Every payload to be signed is first extracted from transfer payload in agreement +with UOS specification and polkadot-js implementation. Only payloads that could +be parsed and visualized somehow could be signed to avoid blind signing - thus +on parser error no signable payload is produced and signing procedure is not +initiated.
+When signable payload is ready, it is stored in TRANSACTION tree while +user makes decision on whether to sign it. While in storage, database checksum +is monitored for changes.
+Signing uses private key generated from KMS-protected secret seed phrase, +derivation string and optional password. Signing operation itself is imported +directly from substrate codebase as dependency.
+Signing event or its failure is logged and signature wrapped in UOS format is +presented as a qr static image on the phone.
+Transaction parsing
+Transaction parsing process is described in UOS format documentation
+Transaction visualization
+Signable transaction is decomposed into hierarchical cards for clarity. All
+possible scale-decodable types are assigned to generalized visualization
+patterns ("transaction cards") with some types having special visualizations
+(balance formatted with proper decimals and units, identicons added to
+identities, etc.). Each card is assigned order and indent that allow the
+cards to be shown in a lazy view environment. Thus, any networks that have
+minimal metadata requirements should be decodable and visualizable.
Some cards also include documentation entries fetched from metadata. Those could +be expanded in UI on touch.
+Thus, user has opportunity to read the whole transaction before signing.
+Airgap data transfer
+Transactions are encoded in accordance to UOS standard in QR codes. QR codes can
+be sent into Vault - through static frames or dynamic multiframe animations -
+and back - only as static frames. QR codes are decoded through native image
+recognition system and decoded through rust backend; output QR codes are
+generated in png format by backend. There are 2 formats of multiframe QR codes:
+legacy multiframe and raptorq multiframe. Legacy multiframe format requires
+all frames in animation to be collected and is thus unpractical for larger
+payloads. RaptorQ multiframe format allows any subset of frames to be collected
+and thus allows large payloads to be transferred effortlessly.
Fast multiframe transfer works efficiently at 30 fps. Typical large payloads +contain up to 200 frames at current state of networks. This can be theoretically +performed in under 10 seconds; practically this works in under 1 minute.
+Airgap updating
+Vault can download new networks and metadata updates from QR data. To prevent +malicious updates from compromising security, a system of certificates is +implemented.
+Updates could be generated by any user; they can also be distributed in signed form to delegate validity check job to trusted parties. These trusted parties should sign metadata with their asymmetric key - certificate - and they become verifiers once their update is uploaded to Vault. There are 2 tiers of certificates - "general" and "custom", with the first allowing more comfortable use of Vault at cost of only one general verifier allowed.
+Rules about verifier certificates are designed around simplicity of security protocol: one trusted party becomes main source of trust and updates generated by it are just accepted. If that party does not have all required updates available, other party can be added as custom verifier. That verifier is not allowed to change specs at will and suspicious activity by custom verifier would interfere with network usage thus stopping user from doing potentially harmful stuff. This allows less strenuous security policy on user side.
+It is important to note that certificates could not be effectively revoked considering airgapped nature of the app, thus it is recommended to keep their keys on airgapped Vault devices if updates signed by these certificates are distributed publicly.
+ +Network detector
+An additional security feature is network detector. When the app is on, it runs +in the background (on low-priority thread) and attempts to monitor the network +availability. This detector is implemented differently on different platforms +and has different features and limitations; however, it does not and could not +provide full connectivity monitoring and proper maintaining of airgap is +dependent on user. Vault device should always be kept in airplane mode and all +other connectivity should be disabled.
+The basic idea of network detection alertness is that when network connectivity +is detected, 3 things happen:
+-
+
- Event is logged in history +
- Visual indication of network status is presented to user (shield in corner of +screen and message in alert activated by the shield) +
- Certain Vault functions are disabled (user authentication, seed and key +creation, etc.) - features that bring secret material into active app memory +from storage +
When network connectivity is lost, only visual indication changes. To restore +clean state of Vault, user should acknowledge safety alert by pressing on +shield icon, reading and accepting the warning. Upon acknowledging, it is logged +in history, visual indication changes to green and all normal Vault functions +are restored.
+Network detector in iOS
+Airplane mode detection in iOS is forbidden and may lead to expulsion of the app +from the App Store. Thus, detector relies on probing network interfaces. If any +network interface is up, network alert is triggered.
+Network detector in Android
+Network detector is triggered directly by airplane mode change event.
+Bluetooth, NFC, etc,
+Other possible network connectivity methods are not monitored. Even though it is +possible to add detectors for them, accessing their status will require the app +to request corresponding permissions form OS, thus reducing app's isolation and +decreasing overall security - first, by increasing chance of leak in breach +event, and second, by making corrupt fake app that leaks information through +network appear more normal. Furthermore, there is information that network might +be connected through cable in some devices in airplane mode; there was no +research on what debugging through cable is capable of for devices in airplane +mode. Thus, network detector is a convenience too and should not be relied on as +sole source of security; user is responsible for device isolation.
+Logging
+All events that happen in Vault are logged by backend in history tree of +database. From user interface, all events are presented in chronological order +on log screen. On the same screen, history checksum could be seen and custom +text entries could be added to database. Checksum uses time added to history +records in computation and is therefore impractical to forge.
+Events presented on log screen are colored to distinguish "normal" and +"dangerous" events. Shown records give minimal important information about the +event. On click, detailed info screen is shown, where all events happened at the +same time are presented in detail (including transactions, that are decoded for +review if metadata is still available).
+Log could also be erased for privacy; erasure event is logged and becomes the +first event in recorded history.
+Self-signing updating capability
+Vault can sign network and metadata updates that could be used for other
+signers. User can select any update component present in Vault and any key
+available for any network and generate a qr code which, upon decoding, can be
+used by generate_message or similar tool to generate over-the-airgap update.
+See detailed documentation
This feature was designed for elegance, but it is quite useful to maintain +update signing key for large update distribution centers, for it allows to +securely store secret certificate key that could not be practically revoked if +compromised.
+UI
+User interface is organized through View-Action-DataModel abstraction.
+View
+Vault visual representation is abstracted in 3 visual layers placed on top of
+each other: screen, modal and alert. This structure is mostly an
+adaptation of iOS design guidelines, as android native UI is much flexible and
+it is easier to adopt it to iOS design patterns than vice versa. Up to one of
+each component could be presented simultaneously. Screen component is always
+present in the app, but sometimes it is fully or partially blocked by other
+components.
Modals and alerts are dismissed on goBack action, screens have complex
+navigation rules. Modals require user to take action and interrupt flow. Alerts
+are used for short information interruptions, like error messages or
+confirmations.
In addition to these, header bar is always present on screen and footer bar is +presented in some cases. Footer bar always has same structure and only allows +navigation to one of navigation roots. Top bar might contain back button, screen +name, and extra menu button; status indicator is always shown on top bar.
+Action
+Almost all actions available to user are in fact handled by single operation -
+action() backend function, that is called through pushButton native
+interface. In native side, this operation is debounced by time. On rust side,
+actions are performed on static mutex storing app state; on blocked mutex
+actions is ignored, as well as impossible actions that are not allowed in
+current state of navigation. Thus, state of the app is protected against
+undefined concurrency effects by hardware button-like behavior of action().
Most actions lead to change of shown combination of screen, modal and alert; but +some actions - for example, those involving keyboard input - alter contents of a +UI component. In most cases, all parameters of UI components are passed as +states (more or less similar concept on all platforms) and frontend framework +detects updates and seamlessly performs proper rendering.
+Action accepts 3 parameters: action type (enum), action data (&str), secret data
+(&str). Secret data is used to transfer secret information and care is taken to
+always properly zeroize its contents; on contrary, action data could contain
+large strings and is optimized normally.
Data model
+Data model as seen by native UI consists of 3 parts: secret seed content, +network detection state and screen contents. Secret seed content consists of +list of seed names that are used as handles to fetch secret material from secure +storage. Network detection state is a 4-state variable that describes current +network detection state (safe state, network is currently detected, network was +detected before, error state). The rest of data model is a black box in Rust.
+From Rust side, model is generated by navigation crate. The state of the app
+is stored in lazy static State object and sufficient information required for
+View rendering is generated into ActionResult object that is sent into native
+layer on each action update.
":e:f.tabReplace?e.replace(/\t/g,f.tabReplace):e):e}function E(e){let n=null;const t=function(e){var n=e.className+" ";n+=e.parentNode?e.parentNode.className:"";const t=f.languageDetectRe.exec(n);if(t){var r=T(t[1]);return r||(console.warn(g.replace("{}",t[1])),console.warn("Falling back to no-highlight mode for this block.",e)),r?t[1]:"no-highlight"}return n.split(/\s+/).find(e=>p(e)||T(e))}(e);if(p(t))return;S("before:highlightBlock",{block:e,language:t}),f.useBR?(n=document.createElement("div")).innerHTML=e.innerHTML.replace(/\n/g,"").replace(/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/mark.min.js b/mark.min.js
new file mode 100644
index 0000000000..1636231883
--- /dev/null
+++ b/mark.min.js
@@ -0,0 +1,7 @@
+/*!***************************************************
+* mark.js v8.11.1
+* https://markjs.io/
+* Copyright (c) 2014–2018, Julian Kühnel
+* Released under the MIT license https://git.io/vwTVl
+*****************************************************/
+!function(e,t){"object"==typeof exports&&"undefined"!=typeof module?module.exports=t():"function"==typeof define&&define.amd?define(t):e.Mark=t()}(this,function(){"use strict";var e="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(e){return typeof e}:function(e){return e&&"function"==typeof Symbol&&e.constructor===Symbol&&e!==Symbol.prototype?"symbol":typeof e},t=function(e,t){if(!(e instanceof t))throw new TypeError("Cannot call a class as a function")},n=function(){function e(e,t){for(var n=0;n
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 
+ 
+
+ +
Polkadot Vault - Turn your smartphone into a hardware wallet
+Polkadot Vault is a mobile application that allows any smartphone to act as an air-gapped crypto wallet. This is also known as "cold storage".
+You can create accounts in Substrate-based networks, sign messages/transactions, and transfer funds to and from these accounts without any sort of connectivity enabled on the device.
+You must turn off or even physically remove the smartphone's Wifi, Mobile Network, and Bluetooth to ensure that the mobile phone containing these accounts will not be exposed to any online threat. Switching to airplane mode suffices in many cases.
+Disabling the mobile phone's networking abilities is a requirement for the app to be used as intended, check our wiki for more details.
+Have a look at the tutorial on our wiki to learn how to use Polkadot Vault together with Polkadot-js app.
+Any data transfer from or to the app happens using QR code. By doing so, the most sensitive piece of information, the private keys, will never leave the phone. The Polkadot Vault mobile app can be used to store any Substrate account, this includes Polkadot (DOT) and Kusama (KSM) networks.
+Key features
+-
+
- This is not a complete crypto wallet in itself. The Vault does not sync with blockchain, so it does not know your account balance, whether transactions were successful or even if the account exists! This is a cold wallet app that only stores keys, reads and signs messages. It should always be used with hot wallet like polkadot.js. +
- The Vault alone does not make your accounts secure. You must maintain security yourself. Airgap should be only part of your security protocol, improper use of Vault could still lead to loss of funds and/or secrets. +
- When properly used, Vault provides best achievable security with Substrate networks to-date. +
System requirements
+Currently Vault is available only for iOS. Android version is coming soon.
+Getting Started
+These tutorials and docs are heavily outdated at the moment, please use them as references or help improving
+If you are upgrading from older version of Vault, please see changelog and upgrading Vault
+Please note that the Vault app is an advanced tool designed for maximum security and complex features. In many use cases, more user-friendly tools would be sufficient.
+ +User Guides
+ +About
+ +Legacy versions
+Older versions of this app could be useful for development, however, they are not safe for use in production. They are available at following branches:
+-
+
- Last public release with React Native +
- Non-ascii characters fix and some transaction parsing +
- Metadata types import and message parsing in RN +
- Rust backend with RN frontend +
License
+Polkadot-Vault is GPL 3.0 licensed.
+ +