witnet / sheikah Goto Github PK
View Code? Open in Web Editor NEWA Witnet compatible desktop wallet and smart contracts development environment
Home Page: https://witnet.io
License: GNU General Public License v3.0
A Witnet compatible desktop wallet and smart contracts development environment
Home Page: https://witnet.io
License: GNU General Public License v3.0
This epic replaces issue #1
This epic replaces and closes #2.
The private and public key serialization format is succintly described in wip-adansdpc-hdwallets, reproduced here:
Extended public and private keys are serialized as follows:
Size | Description |
---|---|
1 byte | Depth: 0x00 for master nodes, 0x01 for level-1 derived keys, etc. |
4*depth bytes | Serialized path; each entry is encoded as 32-bit unsigned integer, big endian |
32 bytes | The chain code |
33 bytes | The public key or private key data |
The key data field will be serP(K) for public keys and 0x00
|| ser256(k) for private keys.
This structure can be encoded using Bech32 format described in WIP-adansdpc-addresses. We will use 'xpub' human-readable part for extended public keys and 'xprv' for extended private keys.
When importing a serialized extended public key, implementations must verify whether the X
coordinate in the public key data corresponds to a point on the curve. If not, the extended public key is invalid.
Upon start up, Sheikah should read from LevelDB or initialize it if still empty.
We must define the client architecture in more detail and write it down in order for everyone to be in the same page and give/receive feedback on.
As an example: we should define how communication between Sheika's front-end and back-end works (e.g.: websockets, etc.) and what's the policy for maintaining the state synced between both.
Discussion and decission on different parts of the client architecture should be done in separate GitHub issues / stories.
Here are some examples.
The IPC API library is an IPC server that wraps and exposes backend methods to the frontend.
dev
/test
/prod
).dev
for the time being.dev
environment.This is a continuation of #13.
In this case, we need to assess their compatibility and ease of use with React.
Here are some curated list of UI component collections:
https://github.com/brillout/awesome-react-components#ui-frameworks
https://hackernoon.com/the-coolest-react-ui-frameworks-for-your-new-react-app-ad699fffd651
We like Semantic UI so far, but we are open to exploring other options.
Describe the bug
Line 3
on CONTRIBUTING.md has a typo.
Change:
:tada: Thank you for being interested in contributing to an Sheikah! :tada:
for:
:tada: Thank you for being interested in contributing to Sheikah! :tada:
We will be making the most of Electron and React to ensure the app feels as native and responsive as possible. To do so, we need first to define a clear architecture that sets forth what will be happening in every part of our app. Clearly stating the responsabilities of both the Electron renderer and the main process is paramount to achieve a consistent and reliable architecture.
Electron conveniently uses two separate processes to isolate the code that will be run in a node-like context (the main process) from the code that will be run inside a web-like context (the renderer process).
The main process has superpowers. Your code is run in a node-like context, so you have access to everything in the userspace of the host machine. This means you can have native access to the filesystem, hardware devices, etc. without having to deal with restrictive web APIs.
A node-like context also gives you the possibility to run Javascript bindings of natively implemented functions (through N-API), which is specially convenient for implementing performance-intensive code (cryptosystems and the like).
The renderer process is nothing more than web content running in a browser (WebKit). The APIs available in this context are exactly the same that you could expect when running Javascript code in a modern browser (including all ES6 and some ES Next).
Our current high level architecture design relies on the main process to act as a sort of back-end that will be responsible for taking care of persisting data in a local database (see #33), performing all the expensive operations related to crypto and brokering communication with rust-witnet
, our full node implementation.
On the other hand, the renderer process acts as front-end or user interface. It is powered by React and relies on Redux to handle app state mutations in a consistent and robust manner.
The front-end back-end can communicate by passing messages to each other thanks to Electron's native IPC modules (ipcMain
and ipcRenderer
). The IPC connection itself is conveniently wrapped by a dedicated API with a series of modular handlers (see #27).
From this point, we can take to different roads:
rust-witnet
.@mariocao suggested using commitizen.
Add a .node-version
with the version used in the project: 9.11.1
, so we are all in the same page. I was using version 10 and bignum is no compiling in it at the moment.
Inside LevelDB, we should have both plain stores and encrypted stores.
Encrypted stores shall use symmetric encryption (AES/CBC/PKCS5Padding
) in a transparent way.
Encrypted stores are unlocked using a user-defined passphrase.
We should create a contribution guide to make it easier for people to know where to start from and what to take into account.
We can build upon the Aragon.js contributing guidelines.
Is your feature request related to a problem? Please describe.
The project root folder is polluted by a number of configuration files that won't see many changes once our the development stabilizes.
Describe the solution you'd like
Move all the configuration files into a new /config
folder.
This includes, at least:
jest.config.js
tsconfig.json
tsfmt.json
tslint.json
webpack.config.base.js
webpack.config.development.js
webpack.config.electron.js
webpack.config.eslint.js
webpack.config.production.js
webpack.config.test.js
Describe alternatives you've considered
None. Feel free to counter-propose.
It's time to define the wallet data structure.
We need to sketch/design the UI/UX for the FTU (first-time-usage).
Remove typings/secp256k1
and use instead @types/secp256k1 npm package
Should cover:
Here's a curated list of UI component collections:
https://github.com/vuejs/awesome-vue#component-collections
We had challenges with vuex
, so @kronolynx is exploring alternatives.
Progress on his findings shall be tracked here.
Add the jest config file to the npm jest script in package.json file.
Our linting rules have been enforcing usage of arrow (binded) functions instead of traditional functions. However, some of us are finding that arrow function overloads are counter-intuitive:
// Traditional function overload
function foo(bar: string): void {}
function foo(bar: number): void {}
// Arrow function overload
const foo: {
(bar: string): void
(bar: number): void
} = (bar: any) => {}
Type definitions also look kind of weird:
// Traditional function typing definition
function foo(bar: string): void
// Arrow function typing definition
const foo: (bar: string) => void
The purpose of this issue is to open a discussion on whether we should relax our arrow functions policy and allow usage of traditional functions in those cases where we believe them to be more convenient.
In that case, we should make a commitment to applying a not-enforced-by-the-linter clear policy on when it is acceptable to use arrow vs. traditional functions.
Vuex helps managing the front-end state in a very efficient, hygienic and seamless way. It ensures that the state can only be mutated in a predictable fashion.
More info:
https://vuex.vuejs.org/en/intro.html
Before implementing any UI we need to create a set of reusable components, our own UI toolkit.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.