etclabscore/jade

[WIP] Jade - The next generation of web applications

The Jade Specification

Supported by ETC Labs

Table of Contents

• Contributing
• Definitions
• Introduction
  • What are the goals of Jade
  • What influenced the design decisions
  • What are the tradeoffs
• Jade Specification
  • Jade Common
    • Jade
    • Jade-service-runner
    • Jade-ui-{platform}-wrapper
  • An Individual Jade Project Architecture
    • Jade-{project}
      • Jade-{project}-{language}
      • Jade-{project}-rpc
        • Jade-{project}-client-{language}
      • Jade-{project}-ui
  • Proposed 1.0.0

Contributing

Definitions

Introduction

What are the goals of the Jade

The goal of Jade is to enable the creation of decentralized, peer to peer applications built for ethereum classic.

Jade should solve the following problems:

1. dapp users should have control over their accounts. This means fine grain controls over:

• Where the private keys are stored. (local or remote?, via 3rd party service? Hardware?)
• When and how the private key may be used to sign transactions/messages.

1. dapp developers should have uniformly documented interfaces for the blockchain, accounts and all other software required to build dapps. They should use OpenRPC.
2. dapp developers should have an easy way of deploying their applications. This means reducing scope of concerns, and enabling dapp developers to ignore the problem of where to get blockchain info from, or where the users account lives.
3. dapps should be able to run nearly anywhere -- browsers, phones, desktops, etc.
4. dapp users should choose the security model that fits them, not the dapp developer.
5. dapp users should have tools at their disposal that makes all of the above easy enough for your grandpa

What influenced the design decisions

What are the tradeoffs

Jade Specification

All Projects:

1. follow pristine

Jade Common

Jade

1. No code, just readme and links to all the goods. This is the first thing you want a google of Jade Etc to see
2. contains github pages site that would be the root of the projects subdomaining (jade.etclabs.org)

Jade-service-runner

1. runs any jade-{project}-rpc service on any platform
2. provides a 'meta rpc' or rpc gateway for any services being. It would be an aggregate of all the jade-{project}s that it is currently running
3. provides a configuration layer for easily maintaining data directories / named environments. In practice, this would be used for things like dev env that has seperate accounts / chain data / etc

Jade-ui-{platform}-wrapper

note: platform here is one of: 'electron', 'mobile'

1. Anything that takes the web based ui exported by jade-{project}-ui and produces a platform specific wrapper for it
2. web application electron wrapper

An Individual Jade Project Architecture

Jade-{project}

1. Top level of a project.
2. place you want people to see first
3. contains github pages site that would be the root of the projects subdomaining ({projectname}.jade.etclabs.org)

Jade-{project}-{language}

1. Exports a package for the language specified by language.
2. May use a compiled and wrapped build to provide the requisite functions of the project. For example, a jade-{project}-js where the js package is really just the jade-{project}-rust crate compiled to wasm and documented / pushed to npm
3. Includes github pages / generated docs.

Jade-{project}-rpc

1. First place you want people to see about RPC server for this project.
2. Should define the OpenRPC schema file.
3. contains github pages site that would be the root of the projects subdomaining ((docs | playground).{projectname}.jade.etclabs.org)
4. MUST expose functionality provided by Jade-{project}-{language} via json rpc server
5. exposes json rpc with service discovery

Jade-{project}-client-{language}

1. Library that implements a client to use the json rpc service.
2. one per language generated
3. packages are published to package manager based on language of implementation

Jade-{project}-ui

1. UI tailored to dapp users or developers that is built ontop of the json rpc
2. packaged as web application
3. uses Jade-{project}-client-{language}s

proposed 1.0.0

The first Jade-{project}:

• Jade-signer
  • Jade-signer-rs
  • Jade-signer-rpc
  • Jade-signer-rpc-clients
  • Jade-signer-ui
• Jade-ui-electron-wrapper
• Jade-service-runner
  • Jade-service-runner-ui

Jade-signer

1. lightweight account management that doesn't require ethereum rpc.
2. Ideally is agnostic to the network onwhich the account would be used...
3. pretty much only has: account crud, signTransaction, signMessage

Jade-service-runner

1. runs any jade-{project} service on any platform
2. provides a 'meta rpc' or rpc gateway for any services.

jade's Issues

get first draft of README/Spec together

Jade-ui-{platform}-wrapper

we should have another ticket created out of this. dont really know where to put it though.

platform wrapper

any web UI should be able to use a platform wrapper package for wrapping up web ui's for iOS/Android, Web, Electron

Originally posted by @shanejonas in #14

Run Mitton through emerald

• fix the broken shit in emerald wallet (minimally, not to make a PR)
• knows how to make changes to tx uri and test them
• how emerald wallet works - booting shit, hooking up via electron, alllll them thangs.

just a note on semver tags

https://github.com/etclabscore/jade/blob/master/VERSIONING.md#summary

MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

I guess we should clarify if the PATCH increment should happen per release (that's what we've been doing) or "when you make [each] backwards-compatible bug fixes".

IMO incrementing PATCH per tagged release makes sense, since semver (and git) typically accomodate for v1.2.3-14-abbcdefa.

might it be worth setting up pre-commit git hooks to enforce some of these patterns?

might be overkill. would need to happen per lang/project or both.... idk. just an idea.

Jade Planning Meeting

sed [:upper:] -> [:lower:]

For me the MUSTs and SHOULDs are distracting. I don't understand why people insist on capitalizing them. Normal lowercased prose, anyone?

Github pages branch

While the repo itself is supa hot. How bout we have a gh-pages (github pages) branch of it?

discussion on build artifact naming

https://github.com/etclabscore/jade/blob/master/BUILDING.md#build-folder-structure

• Are these build rules for CI, for Makefiles/runners that'll be used locally?...

• Build dir naming...

• ethereumclassic/go-ethereum currently uses build/bin/geth

  • the /bin/ is nice because it differentiates executable artifacts vs. non executables, eg signatures, logs, whatever

• ethereum/go-ethereum uses build/geth

• i hacked on a project this weekend that used .build/

• Should we standardize platform naming, eg darwin vs. osx vs. mac?

• Should we standardize platform architecture, so have like amd64 or whatever somewhere?

• Should we prefer .zip or .tar.gz or both? (Currently geth uses .zip for Windows, then both for linux and mac)

• Common artifact name schemes

Service Runner OpenRPC spec

This is copied from the project board etclabscore-tooling

Service Runner

• utility to keep geth node/vault alive and running with configurable data directories.
• A GUI client for making it user friendly and cross platform runnable by non-developers.
  service runner

Problem:

In a decentralized world there are many services (eg. geth, jade-signer, ipfs) that need to be configured to either build, maintain or consume a Dapp.
Management of a full node, configuration, and its peer to peer service dependencies are a manual process.
Dapps require extra services, and many Dapps point to 3rd party centralized services like infura because of the friction caused by maintaining multiple services.
Users + Developers need be running nodes and services themselves to keep the network decentralized.

Solution:

a service runner MUST be able to:

• read services configuration
• start a given service \w configuration
• keep a list of services host/port + maybe capabilities?
• stop a service
• list services

Add TESTING.md to describe how to test projects

For doing CI/CD and various other automation, describing how to run tests for each is a MUST.