Further clean up
This commit is contained in:
Andy Tudhope
parent
13fe696cc6
commit
2fdf63b20a
|
|
@ -1,15 +0,0 @@
|
|||
- name: pluto
|
||||
description: A grammar for data manipulation
|
||||
link: https://status-im.github.io/pluto/
|
||||
thumbnail: pluto.jpg
|
||||
tags:
|
||||
- grammar
|
||||
- data
|
||||
- name: collectibles-chat
|
||||
description: Extension for sending NFTs through Chat
|
||||
link: https://gist.github.com/janherich/92747e730b2e115bcbe145114d024e66
|
||||
thumbnail: cryptokitty.jpg
|
||||
tags:
|
||||
- chat
|
||||
- NFTs
|
||||
- collectibles
|
||||
|
|
@ -1,10 +1,4 @@
|
|||
docs:
|
||||
Nimbus:
|
||||
Incubate:
|
||||
introduction: index.html
|
||||
milestones: milestones.html
|
||||
design: design.html
|
||||
ideas_for_implementation: ideas_for_implementation.html
|
||||
resources: resources.html
|
||||
team: team.html
|
||||
contributor_guide: contributor_guide.html
|
||||
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
- name: How to extend your DApp via chat in Status
|
||||
description: Send collectibles directly in chat
|
||||
link: /tutorials/extensions_tutorial_chat_command.html
|
||||
- name: How to apply for Incubate
|
||||
description: Get some of that good decentralised luvin
|
||||
link: /tutorials/apply_for_incubate.html
|
||||
tags:
|
||||
- extensions
|
||||
- chat
|
||||
- Ethereum
|
||||
- applications
|
||||
- startups
|
||||
- web3
|
||||
- decentralized
|
||||
- open source
|
||||
|
|
|
|||
|
|
@ -1,43 +0,0 @@
|
|||
title: Nimbus
|
||||
---
|
||||
|
||||
# Status Partners with the team behind the programming language Nim
|
||||
|
||||
*To bolster research efforts for Nimbus – a sharding client for Ethereum – status.im have partnered with the core team developing the Nim programming language.*
|
||||
|
||||
On August 1st, we [posted](https://our.status.im/introducing-nimbus-an/) about our research initiative called Nimbus – a Nim implementation of a sharding client for Ethereum. Today we are pleased to announce our partnership with the team behind the [Nim programming language](https://nim-lang.org/); lead by [Andreas Rumpf](https://github.com/Araq). This partnership will not only support our ongoing sharding research, but promote the continued development of the underlying open source language serving as the basis of our work. The more developed, documented, and robust Nim is, the more in depth our R&D can be. Andreas and team have a strong vision for the future of the programming language and we want to support them in their efforts. This marks our ongoing support for open source projects as well as our commitment to our sharding research.
|
||||
|
||||
## Why Nim
|
||||
We chose to work in Nim because it is a lightweight and efficient programming language that suits itself well to resource restricted devices. It also allows us to better learn the Ethereum protocol, as well as attract highly specialized developers with a deep understanding and appreciation for the advanced language features, such as its powerful meta-programming capabilities that give us the flexibility to meet future needs of creating intuitive domain-specific languages tailored to specific facets of Ethereum 2.0 development.
|
||||
|
||||
Finally, the language is backed by a very strong team of talented developers. Andreas started Nim's development in 2006, only two years later the compiler reached the important milestone of being able to compile itself, a process that is known as "bootstrapping". For years now users are deploying Nim applications in production.
|
||||
|
||||
Nim can be summarised as combining the very best aspects of the well known programming languages C, Python and Lisp: Nim is as fast as C, as readable as Python and as extensible as Lisp. This aspect makes Nim unique in the large landscape of existing programming languages.
|
||||
|
||||
Nim was envisioned from the start as a simple language with a focus on metaprogramming and with Status' support Nim's metaprogramming will not only cover its syntactic elements but also its semantics and its type system.
|
||||
|
||||
## The Partnership
|
||||
Status will support Andreas and the Nim team with funding and resources needed to stay focused on the development of the programming language. The Nim team will add at least 2 paid full-time developers! They will fix bugs, respond to issues, and of course develop the compiler, the standard library as well as its tooling. So far, the language has been supported by the open source community and generous volunteers and donors who believe in the work. This has created a unique commitment to the project by all those involved but has meant a lack of dedicated and focused computer scientists solely focused on its development.
|
||||
|
||||
The Status Nimbus team is very familiar with Nim as core Status contributors [Dustin Brody](https://github.com/tersec), [Eugene Kabanov](https://github.com/cheatfate), [Jacek Sieka](https://github.com/arnetheduck), [Mamy Ratsimbazafy](https://github.com/mratsim), [Ryan Lipscombe](https://github.com/coffeepots), [Yuriy Glukhov](https://github.com/yglukhov) and [Zahary Karadjov](https://github.com/zah) are active contributors to the Nim ecosystem. There is already deep integration and collaboration between the Nimbus and Nim teams and this partnership will see even further collaboration and support of each other's work.
|
||||
|
||||
## A Look Ahead at the Roadmap
|
||||
With Status' sponsorship, the Nim team has come up with an ambitious roadmap which makes Nim one of the most exciting languages to watch in the following years. Nim version 1.0 is the long overdue commitment to a stable language core that will preserve backwards compatibility for years to come. There are no hard deadlines to a release date, but a detailed milestone tracking all the issues that need to be resolved for v1.0 is available [here](https://github.com/nim-lang/Nim/milestone/2).
|
||||
|
||||
## Beyond the Partnership
|
||||
In addition to the sponsorship of Nim's ongoing core development there will be a "grants program for Nim". Inspired by Google's Summer of Code, developers will be hired to work on specific Nim-related projects.
|
||||
|
||||
Examples for grants:
|
||||
|
||||
* Add [Language Server Protocol](https://langserver.org/) support to nimsuggest, for better editor and IDE integration.
|
||||
* Improve Nim's package manager, "Nimble", to support reproducible builds.
|
||||
* Improve Nim's tooling so that the result of macro expansions becomes easier to look at.
|
||||
|
||||
We look forward to working with Andreas and the team to push the development of Nim.
|
||||
|
||||
For more information about Nimbus, join us on [Riot](https://chat.status.im/) or [Github](https://github.com/status-im/nimbus).
|
||||
|
||||
You can learn more and get involved with Nim on [Github](https://github.com/nim-lang).
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
title: Status Incubate
|
||||
---
|
||||
|
||||
# Status Incubate Begins!
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
id: contributor_guide
|
||||
title: Contributor Guide
|
||||
---
|
||||
|
||||
|
||||
# How To Get Involved In Research At Status
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
---
|
||||
id: design
|
||||
title: Extensible, Configurable, and Modular Design
|
||||
---
|
||||
|
||||
The application architecture should have modular abstractions for the following:
|
||||
|
||||
1. Networking layer
|
||||
1. Sub-protocols
|
||||
1. Consensus
|
||||
1. Privacy
|
||||
1. Database
|
||||
1. Virtual Machine
|
||||
|
||||
In addition, the implementation must pass the [common tests for all Ethereum implementations](https://github.com/ethereum/tests).
|
||||
|
||||
## Commitment to Ethereum Improvement Proposals (EIP)
|
||||
|
||||
Nimbus is committed to open standards and to maintaining consensus with other Ethereum-compliant implementations. The development of Nimbus and the changes in its protocols will follow [the EIP process](https://github.com/ethereum/EIPs/).
|
||||
|
||||
## User Experience
|
||||
|
||||
Access to shards and mainchain state should be fast and responsive, the application binary should be lightweight in terms of the resources used, and the client should be dependable and robust against crashes.
|
||||
|
||||
## Licensing: MIT, Apache v2.0
|
||||
|
||||
We propose that Nimbus be licensed under Apache 2.0 and MIT. A permissive licensing structure with patent protection would
|
||||
|
||||
1. Ensure the compatibility with GPL 2.0 and LGPL 2.0
|
||||
1. Extend the reach of the Ethereum platform
|
||||
1. Foster the highest degree of adoption by governments and enterprise
|
||||
|
||||
One unsolved hurdle faced by Status is the [LGPLv3](https://opensource.org/licenses/LGPL-3.0) license, whose requirement for runtime linking is incompatible with major mobile app distribution channels, such as the App Store of Apple Inc.
|
||||
|
||||
Numerous requests for a static-linking exception have gone unanswered. This has blocked the deployment of any legally sound, full Ethereum client on popular channels for distribution of mobile devices. LGPL also prevents the adoption of Ethereum on closed hardware platforms, such as XBox. Still, we remain optimistic this issue will be rectified.
|
||||
|
||||
## Biweekly Development Reports, Technical Writing, and Promotion
|
||||
|
||||
In addition to the implementation, Nimbus will have a biweekly process for reporting development-related updates. A technical writer will document implementation efforts and translate ongoing research discussions into articles easily understood by the community.
|
||||
|
||||
Within the community at large, we will promote Ethereum as the leader of scalable public blockchains.
|
||||
|
||||
## Bounty-Based Development
|
||||
|
||||
To entice the community to accelerate the development, we will attach bounties to and **[publish](https://openbounty.status.im/app#/) **the tasks that can be self-contained and defined clearly.
|
||||
|
|
@ -1,14 +0,0 @@
|
|||
---
|
||||
id: ideas_for_implementation
|
||||
title: Ideas for Implementation
|
||||
---
|
||||
|
||||
1. Create [devp2p](https://github.com/ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol) and an abstraction to allow for [libp2p](https://github.com/Agorise/c-libp2p), [Node Discovery](https://github.com/ethereum/wiki/wiki/Node-discovery-protocol), [RLP encoding](https://github.com/ethereum/wiki/wiki/RLP), [Modified Patricia Merkle Tree](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/), [bigint's](https://github.com/def-/nim-bigints), [keccak256](https://github.com/ethereum/eth-hash), and [secp256k1](https://en.bitcoin.it/wiki/Secp256k1).
|
||||
1. Create an abstraction that would allow sub-protocols: ETH, [SHH](https://gist.github.com/gluk256/9812e59ed0481050350a11308ada4096), [PSS](https://gist.github.com/zelig/d52dab6a4509125f842bbd0dce1e9440), [Swarm](https://github.com/ethersphere/swarm), [LES](https://github.com/ethereum/wiki/wiki/Light-client-protocol), [Stateless Clients](https://nordicapis.com/defining-stateful-vs-stateless-web-services/), Sharding, [Plasma](https://plasma.io/), [State Channels](https://blog.stephantual.com/what-are-state-channels-32a81f7accab). For now, we can ignore all but LES and Sharding.
|
||||
1. DB: Most implementations of Ethereum use [LevelDB](https://github.com/google/leveldb). Parity has a DB abstraction and uses [HashDB](https://github.com/NPS-DEEP/hashdb/wiki) and [RocksDB](https://rocksdb.org/docs/getting-started.html).
|
||||
1. RocksDB is an interesting choice, because it solves the issues that have troubled leveldb. Rocksdb also has a [light version](https://github.com/facebook/rocksdb/blob/master/ROCKSDB_LITE.md) for mobile usage; it's in C++, which would be an issue only if we go for pure C.
|
||||
1. [EVM](https://github.com/pirapira/awesome-ethereum-virtual-machine): basic VM, [eWASM](https://github.com/ewasm/design) ([Hera](https://github.com/ewasm/hera) is also in C++)
|
||||
1. IPC/RPC abstraction, [external API methods](https://github.com/ethereum/wiki/wiki/JSON-RPC) that can be consumed by application bindings: react-native module, IPC, RPC HTTP server, or web sockets
|
||||
1. Encryption library is a little unclear. [Libgcrypt](https://www.gnupg.org/software/libgcrypt/index.html) has everything we need but might be problematic from the standpoint of LGPL licensing. If we have an abstraction for Libgcrypt, we could use it now and swap it out later for something more permissive.
|
||||
1. Alternatively, we could roll out our own library. However, implementing our own encryption would not be a great idea, and our version would have to be audited and tested. Suggestions are welcome.
|
||||
1. Monitor [ethereum/py-evm](https://github.com/ethereum/py-evm/tree/sharding). Connect with Chang-Wu Chen, Hsiao-Wei Wang, and anyone else working on sharding.
|
||||
|
|
@ -1,56 +1,4 @@
|
|||
title: An Ethereum 2.0 Sharding Client
|
||||
title: Welcome to Incubate
|
||||
---
|
||||
|
||||
## OVERVIEW
|
||||
|
||||
Draft 2018-05-22
|
||||
|
||||
Nimbus aims to be a [sharding](https://github.com/ethereum/wiki/wiki/Sharding-FAQ) client implementation for the Ethereum Blockchain Application Platform. Because the largest deployment of Ethereum will potentially be on embedded systems, Nimbus will be designed to perform well on IoT and personal mobile devices, including older smartphones with resource-restricted hardware. The extensible, configurable, and modular design of Nimbus will make it production ready for Web 3.0 and will ensure that it can be supported and maintained across all goals of Ethereum 2.0.
|
||||
|
||||
|
||||
## GOALS
|
||||
|
||||
|
||||
1. Create an Ethereum implementation suitable for resource-restricted devices.
|
||||
1. Create an implementation team for the [Applied Research Objectives](https://hackmd.io/s/HkLkj55yb#objectives-in-applied-research) of [Ethereum Research](http://ethereumresearch.org/) (aka Ethereum Asia Pacific Limited), with focus on the following:
|
||||
1. Proof of Stake (PoS)
|
||||
1. Sharding
|
||||
1. Stateless Clients
|
||||
1. LES2
|
||||
1. eWASM
|
||||
1. Close the gap between research modeling and production.
|
||||
1. Pledge to participate in, help implement, and conform to the [Ethereum Improvement Proposal](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md).
|
||||
1. Implement permissive licensing.
|
||||
1. Focus on production-ready [Web 3.0](https://medium.com/@matteozago/why-the-web-3-0-matters-and-you-should-know-about-it-a5851d63c949) Stack ([Whisper](https://github.com/ethereum/wiki/wiki/Whisper), [PSS](https://github.com/nolash/psstalk/blob/master/README.md), and [Swarm](https://swarm-guide.readthedocs.io/en/latest/introduction.html)) and its ongoing research and development.
|
||||
1. Focus on marketing and promotion to address community concerns on scalability and to bolster Ethereum's dominant mindshare.
|
||||
|
||||
|
||||
## REQUIREMENTS
|
||||
|
||||
[Nim](https://nim-lang.org/) is an efficient, general-purpose systems programming language with a Python-like syntax that compiles to C. Nim will allow us to implement Ethereum rapidly and to take advantage of the mature C-language tooling: in compilation of machine code, and in the analysis of static code.
|
||||
|
||||
With Ethereum research currently modeled in Python, the end result of implementing in Nim should be code that:
|
||||
|
||||
1. Enables us to easily bring research into production
|
||||
1. Has a high degree of reasonability for researchers
|
||||
1. Is performant in production
|
||||
|
||||
The core contributors and Nim community have been very supportive and enthusiastic for the project.
|
||||
|
||||
|
||||
## Development on Embedded Systems
|
||||
|
||||
We believe that the largest successful deployment of Ethereum will reside on embedded systems: IoT devices and mobile personal devices, such as smartphones. Although Nimbus will support archival nodes, its first implementation will be as a light client, with focus on Proof of Stake and sharding.
|
||||
|
||||
Existing implementations of Ethereum have focused on desktop computers and servers. These implementations have played a major role in the initial success of Ethereum, and they are suitable for full and archival nodes. However, their deployment onto embedded systems has been an afterthought.
|
||||
|
||||
In addition, throughout the development of Status, we have found that the dominant Ethereum implementations, Geth and Parity, are unsuitable for our target platform unless they are profiled and optimised (in progress).
|
||||
|
||||
During the deployment of Status among 40,000 alpha testers, we found that a significant portion (23.6%) of users were still running old mobile devices. In addition, recently discovered [Spectre vulnerabilities](https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)) have led to an increase in the demand for open processors. For these reasons, we propose a self-imposed constraint and a requirement that Status perform well on the following:
|
||||
|
||||
|
||||
1. 2014 [SoC](https://en.wikipedia.org/wiki/System_on_a_chip) architectures, such as the [Cortex-A53](https://developer.arm.com/products/processors/cortex-a/cortex-a53) (Samsung Note 4 & [Raspberry Pi 3](https://www.raspberrypi.org/products/raspberry-pi-3-model-b/)) and the Apple A8 (iPhone 6)
|
||||
1. [MIPS](https://en.wikipedia.org/wiki/MIPS_architecture)-based architectures, such as the [Onion Omega2](https://onion.io/omega2/)
|
||||
1. Open-source processors, such as [RISC-V](https://en.wikipedia.org/wiki/RISC-V)
|
||||
|
||||
When the 2020 scalability goal is fully realised, this constraint will help ensure that Ethereum runs performantly on resource-restricted hardware that is at least 6 years old.
|
||||
Docs to go here.
|
||||
|
|
@ -1,168 +0,0 @@
|
|||
---
|
||||
id: milestones
|
||||
title: Milestones
|
||||
---
|
||||
|
||||
Timelines are approximate and affected by research, implementation considerations, and revisions made while the team produces a detailed implementation timeline.
|
||||
|
||||
|
||||
## Formation of the Team, and Detailed Project Implementation Timeline
|
||||
|
||||
|
||||
### January - February 2018
|
||||
|
||||
|
||||
### Completed:
|
||||
|
||||
1. Form the initial team
|
||||
1. Define the project's scope, architecture, and implementation timelines
|
||||
|
||||
### Goals:
|
||||
|
||||
|
||||
1. Hire core contributors:
|
||||
1. Five (5) full-time core contributors
|
||||
1. Up to five (5) part-time core contributors
|
||||
1. One (1) Technical Program Manager
|
||||
1. One (1) Technical Writer
|
||||
1. Up to ten (10) full-time core contributors by 2019
|
||||
1. Create a detailed timeline for implementing the project as a deliverable
|
||||
|
||||
|
||||
## Compatibility with Ethereum 1.0
|
||||
|
||||
|
||||
### January - November 2018
|
||||
|
||||
As an initial goal, we will focus on implementing all components required for interoperability with the Ethereum ecosystem. We will publish these components as independently reusable modules and libraries.
|
||||
|
||||
However, before starting the implementation in Nim, we will develop an understanding of the existing implementations of Ethereum: [Go Ethereum](https://github.com/ethereum/go-ethereum/), [Pyethereum](https://github.com/ethereum/pyethereum), [Py-EVM](https://github.com/ethereum/py-evm), and [Parity](https://github.com/paritytech/parity).
|
||||
|
||||
The code will consist of independently reusable libraries that have the same permissive license as that of Nimbus itself:
|
||||
|
||||
|
||||
|
||||
1. [RLP encoding and decoding](https://github.com/status-im/nim-rlp)
|
||||
1. [Handling of the state database and users' keyfiles](https://github.com/status-im/nim-eth-keyfile/blob/master/README.md)
|
||||
1. Connecting to the Ethereum network
|
||||
1. Ethereum Patricia Trees
|
||||
1. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md#introduction) sub-protocols
|
||||
1. Ethereum [Ethash](https://github.com/ethereum/wiki/wiki/Ethash) function
|
||||
1. Implementation of EVM
|
||||
|
||||
|
||||
### Goals:
|
||||
|
||||
1. Nimbus is able to
|
||||
1. Sync with the latest blockchain, from scratch
|
||||
1. Accurately execute the entire transaction history
|
||||
1. The team is familiar with all codebases used to implement Ethereum.
|
||||
1. The team understands the main themes from [ethresear.ch](https://ethresear.ch/) and actively participates in EIPs.
|
||||
|
||||
|
||||
## Sharding Phase 1
|
||||
|
||||
|
||||
### July - November 2018
|
||||
|
||||
While implementing compatibility with Ethereum 1.0, we will gain early experience with the complete setup of sharding. As a result:
|
||||
|
||||
|
||||
1. The client will implement the core features necessary for sharding Phase 1.
|
||||
1. The team will actively participate in sharding-related EIPs.
|
||||
|
||||
|
||||
### Goal:
|
||||
|
||||
The architecture of Nimbus supports sharding nodes.
|
||||
|
||||
|
||||
## Auditing of Beta and Security
|
||||
|
||||
|
||||
### November 2018 - March 2019
|
||||
|
||||
An independent security partner will continuously perform a security audit on the Nimbus codebase. We will also adopt frequent reviews of code, testing with automated fuzzing frameworks, and other practices that enhance security. In addition, we will develop a Nim-optimized fuzzing framework and will release it for use by the community at large.
|
||||
|
||||
### Goal:
|
||||
|
||||
Deliver a security-audited, production-ready client.
|
||||
|
||||
## Implementation of Whisper and PSS
|
||||
|
||||
### July - November 2018
|
||||
|
||||
We will set and advertise the bounties as soon as the P2P layer gets implemented. The core team will start working on this in July, unless already completed.
|
||||
|
||||
### Goals:
|
||||
|
||||
1. Make Nimbus the leading platform for conducting research into the scalability aspects of Whisper and PSS. We consider this a key requirement for implementing a fully decentralised Status messaging platform within the Ethereum network.
|
||||
1. Deliver easy-to-use APIs for conducting large-scale and small-scale experiments within the network.
|
||||
|
||||
## Support for LES
|
||||
|
||||
### July - November 2018
|
||||
|
||||
We will optimize the architecture of Nimbus for implementing the [LES protocol](https://github.com/ethereum/wiki/wiki/Light-client-protocol). We will also optimize all internal state-handling operations such that they work efficiently and asynchronously. This will enable on-demand fetching of data from the network. This will also ensure that Nimbus runs with a high degree of concurrency and that the client UI is responsive.
|
||||
|
||||
### Goals:
|
||||
|
||||
1. Enable a Light Mode switch in Nimbus.
|
||||
1. Successfully operate Nimbus in a mobile environment, without relying on a proxy service.
|
||||
|
||||
## Sharding Phase 2
|
||||
|
||||
### November 2018 - July 2019
|
||||
|
||||
We will focus on achieving compatibility with all other clients. In addition, we will implement an [eWASM](https://github.com/ewasm/design/blob/master/README.md) runtime and will add Nim as one of the languages that can target the new VM.
|
||||
|
||||
### Goals:
|
||||
|
||||
Implement the following in Nim:
|
||||
|
||||
1. CLI tools and APIs for running Phase 2 nodes and for interacting with the Validator Manager Contract (VMC)
|
||||
1. The development tools that will target the eWASM runtime environment
|
||||
|
||||
## Casper Implementation
|
||||
|
||||
### December 2018 - February 2019
|
||||
|
||||
The team will closely follow the development of [Casper](https://blockgeeks.com/guides/ethereum-casper/) and will try to achieve and maintain compatibility with the existing Casper deployments.
|
||||
|
||||
## Implementation of Swarm
|
||||
|
||||
### January - July 2019
|
||||
|
||||
We will set and advertise the bounties as soon as the P2P layer gets implemented. The core team will start working on this in January, unless already completed.
|
||||
|
||||
### Goals:
|
||||
|
||||
Implement the following:
|
||||
|
||||
1. Ability to embed Nimbus into applications that deliver the complete Web 3.0 experience
|
||||
1. Support for the [Ethereum Name Service](https://ens.domains/)
|
||||
1. Support for a virtual file-system interface for accessing web content published on Swarm
|
||||
1. Reusable APIs for publishing and obtaining content from Swarm
|
||||
|
||||
## Sharding Phase 3
|
||||
|
||||
### March - August 2019
|
||||
|
||||
We will leverage our LES-optimized architecture to deliver a fully stateless client optimized for mobile devices.
|
||||
|
||||
### Goals:
|
||||
|
||||
Implement support for the following:
|
||||
|
||||
1. Always-on operations on mobile devices, without disrupting the battery life or inducing significant bandwidth charges
|
||||
1. Running stateless executor nodes in deployments of headless servers
|
||||
|
||||
## Ongoing Improvements in Sharding
|
||||
|
||||
### August - December 2019
|
||||
|
||||
### Goals:
|
||||
|
||||
1. Become one of the leading production-ready sharding implementations in the Ethereum ecosystem.
|
||||
1. Take active part in the effort to specify the new programming models required for cross-shard interactions.
|
||||
1. Provide an ongoing research into the applicability and performance characteristics of all super-quadratic sharding designs in a mobile environment.
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
---
|
||||
id: resources
|
||||
title: Resources
|
||||
---
|
||||
|
||||
1. [Awesome Ethereum Virtual Machine](https://github.com/pirapira/awesome-ethereum-virtual-machine)
|
||||
1. [Detailed introduction to the sharding proposal](https://github.com/ethereum/sharding/blob/develop/docs/doc.md)
|
||||
1. [Sharding FAQ](https://github.com/ethereum/wiki/wiki/Sharding-FAQ)
|
||||
1. [Ethereum 2.0: A presentation by Vitalik Buterin at BeyondBlock Taipei 2017](https://www.youtube.com/watch?v=9RtSod8EXn4&feature=youtu.be&t=11493)
|
||||
1. [The Stateless Client Concept](https://ethresear.ch/t/the-stateless-client-concept/172)
|
||||
1. [A Modest Proposal for Ethereum 2.0: A presentation by Vitalik Buterin at devcon three](https://youtu.be/hAhUfCjjkXc)
|
||||
1. [Python Implementation of the EVM](https://github.com/ethereum/py-evm/blob/master/README.md)
|
||||
1. [Discussion about sharding](https://ethresear.ch/c/sharding)
|
||||
1. [Discussion on Casper, scalability, abstraction and other low-level protocol research topics](https://gitter.im/ethereum/research)
|
||||
1. [ethereum/py-evm](https://gitter.im/ethereum/py-evm)
|
||||
1. [Ethereum Sharding: Overview and Finality](https://medium.com/@icebearhww/ethereum-sharding-and-finality-65248951f649)
|
||||
1. [Sharding - Mind Map](https://www.mindomo.com/mindmap/sharding-d7cf8b6dee714d01a77388cb5d9d2a01)
|
||||
1. [On Settlement Finality](https://blog.ethereum.org/2016/05/09/on-settlement-finality/)
|
||||
1. [Casper contract and full POS](https://ethresear.ch/t/casper-contract-and-full-pos/136/2)
|
||||
1. [Ethereum Casper 101](http://notes.eth.sg/MYEwhswJwMzAtADgCwEYBM9kAYBGJ4wBTETKdGZdXAVmRvUQDYg=?view#)
|
||||
1. [ethersphere/swarm, Light mode of operation](https://github.com/ethersphere/swarm/wiki/Light-mode-of-operation)
|
||||
|
|
@ -1,43 +0,0 @@
|
|||
---
|
||||
id: team
|
||||
title: Team and Etymology
|
||||
---
|
||||
|
||||
In addition to a dedicated Nimbus team, Status as an organization will support development through our expertise in smart contracts, Ethereum and mobile development, and marketing and user experience research.
|
||||
|
||||
### Eugene Kabanov
|
||||
|
||||
Eugene has deep background and interest in systems programming, reverse engineering, development of high-load and high-performance networking services, and information security. He joined Nim community 3 years ago and has contributed to Nim networking, threading, and multiprocessing.
|
||||
|
||||
### [Jacek Sieka](https://www.linkedin.com/in/sieka/)
|
||||
|
||||
With a keen interest and background in peer-to-peer applications and compilers, Jacek joined Status as Head of Research, coming most recently from the high-frequency trading world. Fun hobby projects from the past include DC++ (a file sharing app), nlvm (an llvm-based Nim compiler) and more!
|
||||
|
||||
### [Mamy Ratsimbazafy](https://www.linkedin.com/in/mamyratsimbazafy)
|
||||
|
||||
Mamy joined Status as a Nim developer in the research team. After a career in leading American and French banks and non-profits, he decided that tech, blockchain and AI will eat the world. On the side, instead of mining he is teaching deep learning tricks to his GPU.
|
||||
|
||||
### Ryan Lipscombe
|
||||
|
||||
Fascinated by the transformative potential of blockchain and distributed systems, Ryan joined Status research as a Nim developer. His career spans from data science to embedded systems and has been part of the Nim community since 2015, working on database components and virtual machines for evolutionary systems.
|
||||
|
||||
|
||||
### Yuriy Glukhov
|
||||
|
||||
Yuriy has deep passion for new technologies and keen interest in many areas of IT. He was one of the first CTOs to successfully use Nim in a commercial project.
|
||||
|
||||
|
||||
### [Zahary Karadjov](https://www.linkedin.com/in/zahary/)
|
||||
|
||||
Zahary is member of the core compiler team of the Nim programming language. He joined the project 5 years ago, hoping that one day Nim will surpass C++ in usage and popularity. His career started as a game engine developer, where he learned how to push the modern hardware to its limits, but eventually he went on to become the CTO of a company shipping an IoT device, a SaaS platform for web publishers and even a defunct Chromium fork.
|
||||
|
||||
### [Dustin Brody](https://github.com/tersec)
|
||||
|
||||
# ETYMOLOGY
|
||||
|
||||
Nimbus is a reference to:
|
||||
|
||||
* A different kind of "dark cloud" computing
|
||||
* Spiritual symbolism of sanctity and holiness
|
||||
* Nim, the language it will be written in
|
||||
* A Bus in computing architecture
|
||||
|
|
@ -1,181 +0,0 @@
|
|||
---
|
||||
id: extensions_tutorial_chat_command
|
||||
title: Extension chat command tutorial
|
||||
---
|
||||
|
||||
# Write a chat command
|
||||
|
||||
One of the main use case for extensions is to add new chat commands. This tutorial will go step by step through the creation and deployment of a chat command allowing to send NFTs.
|
||||
|
||||
## Add meta data
|
||||
|
||||
First step is to create the skeleton extension with some relevant metadata:
|
||||
|
||||
```clojure
|
||||
{meta {:name "My command name"
|
||||
:description "My command description"
|
||||
:documentation "Some more details can go there"}}
|
||||
```
|
||||
|
||||
Metadata will be displayed to the end user before installing an extension.
|
||||
|
||||
## Define hook entry point (chat command)
|
||||
|
||||
Hooks identify what part of status will be extended. Each hook has a unique identifier and a set of key/value elements specific to this hook.
|
||||
An extension can implement several hooks.
|
||||
|
||||
In this tutorial a chat command is created: it's specific id is `collectible` and the generic hook type for a chat command is `commands`.
|
||||
|
||||
A `command` hook requires the following properties to be set:
|
||||
|
||||
* scope
|
||||
* preview and short-preview
|
||||
* parameters
|
||||
|
||||
### Scope
|
||||
|
||||
Scope can be any combination of:
|
||||
|
||||
* personal-chats
|
||||
* group-chats
|
||||
* public-chats
|
||||
|
||||
Here we will demonstrate `personal-chats`.
|
||||
|
||||
```clojure
|
||||
{hooks/commands.collectible
|
||||
{...
|
||||
:scope #{:personal-chats}} ;; Could be #{:personal-chats :group-chats}
|
||||
```
|
||||
|
||||
### Previews
|
||||
|
||||
`Previews` are used to display the result of a command execution in a chat.
|
||||
|
||||
`Short previews` will be displayed as last message in the chat item of the Home tab of Status.
|
||||
|
||||
Both previews must point to definition of UI in [Hiccup syntax](https://github.com/weavejester/hiccup/wiki/Syntax) using a combination of views, queries and events supported by status host.
|
||||
|
||||
More details can be found [here](https://status-im.github.io/pluto/docs/concepts/Anatomy.html).
|
||||
|
||||
Previews receive data from status encapsulating the parameters provided by the end user and some relevant contextual information. Those can be accessed in a view using the `properties` reference.
|
||||
|
||||
Our short preview definition:
|
||||
|
||||
```clojure
|
||||
{views/short-preview
|
||||
(let [{{{symbol :symbol} :params} :content outgoing :outgoing} properties]
|
||||
[view {:flex-direction :row
|
||||
:align-items :flex-start}
|
||||
[text (if outgoing "Sent " "Received ")]
|
||||
[text symbol]])}
|
||||
```
|
||||
|
||||
`properties` data is accessed using [destructuring](https://status-im.github.io/pluto/docs/concepts/View.html#destructuring).
|
||||
`text` and `view` are view elements available for all hosts.
|
||||
`if` is a block providing conditional logic.
|
||||
|
||||
Our preview definition:
|
||||
|
||||
```clojure
|
||||
{views/preview
|
||||
(let [{{{symbol :symbol token :token tx-hash :tx-hash} :params} :content outgoing :outgoing timestamp-str :timestamp-str} properties
|
||||
collectible-token [get-collectible-token {:symbol symbol :token token}]
|
||||
[view {:flex-direction :column
|
||||
:align-items :flex-start}
|
||||
[status/nft-token collectible-token]
|
||||
[view {:color (if outgoing "#707caf" "#939ba1")
|
||||
:margin-top 6
|
||||
:font-size 12
|
||||
:flex-direction :row}
|
||||
[text "Sent at "]
|
||||
[text timestamp-str]]
|
||||
[status/send-status {:tx-hash tx-hash :outgoing outgoing}]])}
|
||||
```
|
||||
|
||||
`status/nft-token` and `status/send-status` are view element specific to status.
|
||||
`[status/get-collectible-token {:symbol symbol :token token}]` is a query giving access to details for a specific collectible.
|
||||
|
||||
### Parameters
|
||||
|
||||
The NFT chat command has 2 required parameters: the NFT type and the specific NFT you want to exchange.
|
||||
Both will use Status UI components to provide a nice visual selection experience.
|
||||
|
||||
A parameter is identified by its `id` and must define a `type` and a `placeholder` (any string).
|
||||
In this tutorial `:text` and `:number` will be used.
|
||||
`suggestions` can be optionally provided and must point to a `view`.
|
||||
|
||||
```clojure
|
||||
{hooks/commands.collectible
|
||||
{...
|
||||
:parameters [{:id :symbol
|
||||
:type :text
|
||||
:placeholder "Collectible symbol"
|
||||
:suggestions status/asset-selector}
|
||||
{:id :token
|
||||
:type :number
|
||||
:placeholder "Collectible token"
|
||||
:suggestions status/token-selector}]}}
|
||||
```
|
||||
|
||||
## Deploy
|
||||
|
||||
Extensions are identified by a URI and can be loaded in status via a universal link.
|
||||
|
||||
Currently only GitHub gist is supported as provider.
|
||||
|
||||
A universal link pointing to an extension would then look like: `https://get.status.im/extension/gist@janherich/92747e730b2e115bcbe145114d024e66`
|
||||
|
||||
## Use
|
||||
|
||||
The simplest option is to scan a QR code pointing to your extension. You can also navigate to status user profile and open the `Extensions` item in the `Advanced` section. This option is only available in developer mode.
|
||||
|
||||
Once loaded, details about an extension are available. An extension can then be installed. Once installed all hooks are `active`. Any extension can then be `deactivated` or re-`activated`. Associated hooks will then be removed/added from Status.
|
||||
|
||||
You can now use your new extension from within a 1-1 chat!
|
||||
|
||||
|
||||
|
||||
|
||||
## Full extension code
|
||||
|
||||
|
||||
```clojure
|
||||
{meta {:name "Collectibles"
|
||||
:description "Demonstration of collectible command"
|
||||
:documentation "Some nice documentation"}
|
||||
|
||||
views/preview
|
||||
(let [{{{symbol :symbol token :token tx-hash :tx-hash} :params} :content outgoing :outgoing timestamp-str :timestamp-str} properties
|
||||
collectible-token [get-collectible-token {:symbol symbol :token token}]
|
||||
[view {:flex-direction :column
|
||||
:align-items :flex-start}
|
||||
[status/nft-token collectible-token]
|
||||
[view {:color (if outgoing "#707caf" "#939ba1")
|
||||
:margin-top 6
|
||||
:font-size 12
|
||||
:flex-direction :row}
|
||||
[text "Sent at "]
|
||||
[text timestamp-str]]
|
||||
[status/send-status {:tx-hash tx-hash :outgoing outgoing}]])
|
||||
|
||||
views/short-preview
|
||||
(let [{{{symbol :symbol} :params} :content outgoing :outgoing} properties]
|
||||
[view {:flex-direction :row
|
||||
:align-items :flex-start}
|
||||
[text (if outgoing "Sent " "Received ")]
|
||||
[text symbol]])
|
||||
|
||||
hooks/commands.collectible
|
||||
{:scope #{:personal-chats}
|
||||
:preview preview
|
||||
:short-preview short-preview
|
||||
:parameters [{:id :symbol
|
||||
:type :text
|
||||
:placeholder "Collectible symbol"
|
||||
:suggestions status/asset-selector}
|
||||
{:id :token
|
||||
:type :number
|
||||
:placeholder "Collectible token"
|
||||
:suggestions status/token-selector}]}}
|
||||
```
|
||||
|
|
@ -19,11 +19,5 @@ page:
|
|||
|
||||
sidebar:
|
||||
docs:
|
||||
Nimbus: Nimbus
|
||||
introduction: What Is Nimbus?
|
||||
milestones: Milestones
|
||||
design: Design
|
||||
ideas_for_implementation: Ideas For Implementation
|
||||
resources: Resources
|
||||
team: Team
|
||||
contributor_guide: Contributor Guide
|
||||
Incubate: Incubate
|
||||
introduction: What Is Status Incubate?
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@
|
|||
<i class="mobile-submenu-trigger"></i>
|
||||
<div class="sub-menu">
|
||||
<ul>
|
||||
<li><a href="https://incubate.status.im">About</a></li>
|
||||
<li><a href="#">About</a></li>
|
||||
<li><a href="https://our.status.im/tag/incubate">Blog</a></li>
|
||||
<li><a href="https://get.status.im/chat/public/status-incubate">Talk To Us</a></li>
|
||||
</ul>
|
||||
|
|
@ -56,7 +56,21 @@
|
|||
</div>
|
||||
</li>
|
||||
<li><a href="https://our.status.im/tag/hardwallet">Hardwallet</a></li>
|
||||
<li><a href="https://our.status.im">Community</a></li>
|
||||
<li class="has-submenu">
|
||||
<a href="https://people-ops.status.im">Peopleops</a>
|
||||
<i class="mobile-submenu-trigger"></i>
|
||||
<div class="sub-menu">
|
||||
<ul>
|
||||
<li><a href="https://our.status.im/our-principles/">Our Principles</a></li>
|
||||
<li><a href="https://status-im.github.io/docs/working_here.html">Working Here</a></li>
|
||||
<li><a href="https://status-im.github.io/docs/">Docs</a></li>
|
||||
<li><a href="https://status-im.github.io/docs/life_status.html">Life at Status</a></li>
|
||||
<li><a href="https://status-im.github.io/docs/">Contribute</a></li>
|
||||
<li><a href="https://status-im.github.io/docs/">Jobs</a></li>
|
||||
<li><a href="https://status-im.github.io/tag/people-ops">Blog</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
</li>
|
||||
</ul>
|
||||
</nav>
|
||||
</header>
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
<div class="mobile-menu-header">
|
||||
<div class="logo-wrap">
|
||||
<span class="logo-span"><a class="logo" href="/"></a></span>
|
||||
<span class="logo-span"><a class="logo-text" href="/">nimbus</a></span>
|
||||
<span class="logo-span"><a class="logo-text" href="/">incubate</a></span>
|
||||
</div>
|
||||
<a href="#" class="close">
|
||||
<svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg">
|
||||
|
|
|
|||
|
|
@ -1,10 +0,0 @@
|
|||
<li class="plugin on">
|
||||
<img src="/extensions/thumbnails/{{ plugin.thumbnail }}" style="display: block; width: 200px; height: 160px; margin-bottom: 20px;" />
|
||||
<a href="{{ plugin.link }}" class="plugin-name" target="_blank">{{ plugin.name }}</a>
|
||||
<p class="plugin-desc">{{ plugin.description }}</p>
|
||||
<div class="plugin-tag-list">
|
||||
{% for tag in plugin.tags %}
|
||||
<a href="#{{ tag }}" class="plugin-tag">{{ tag }}</a>
|
||||
{% endfor %}
|
||||
</div>
|
||||
</li>
|
||||
|
|
@ -287,8 +287,9 @@ select[multiple] {
|
|||
padding: 16px 24px;
|
||||
border-bottom: 1px solid rgba(0, 0, 0, 0.1);
|
||||
.logo
|
||||
background-image: url(../img/nimbus.svg);
|
||||
background-size: 44px;
|
||||
background-image: url(../img/logo_white.svg);
|
||||
background-size: 20px;
|
||||
background-color: #66CBD2;
|
||||
width: 44px;
|
||||
height: 44px;
|
||||
.logo-text
|
||||
|
|
|
|||
Loading…
Reference in New Issue