Git Product home page Git Product logo

nano-docs's Introduction

Nano Protocol Documentation

nano-docs is the source code for the Nano protocol documentation and is built using MkDocs with the MkDocs Material theme.

Purpose

This documentation focuses on various users within the technical community: advanced users, node operators, developers integrating Nano, and those interested in details around how the protocol works. All efforts to help update the documentation should keep in mind these goals as submissions that fall outside of this scope are likely to be rejected.

Contributing

For users wishing to contribute to this documentation, we recommend you join the Discord (https://chat.nano.org) #documentation channel to keep up to date on the latest activity. GitHub issues will be used to manage requests for changes. It is recommended any navigational changes or larger updates be discussed on the Discord #nano-docs channel or within a GitHub issue before completing work - this will help avoid wasted work that does not align with the documentation goals.

To submit changes, please fork the repository and create a branch to make changes. Submit a Pull Request back to the source repository when ready for review ahead of possible inclusion.

Development

The recommended local setup is to use Docker with a pre-built image for MkDocs and Material theme. With Docker installed, from the cloned nano-docs directory run:

docker pull ghcr.io/nanocurrency/nano-docs:latest
docker run --rm -it -p 8000:8000 ghcr.io/nanocurrency/nano-docs:latest

You can also install MkDocs with Python 3 to serve using the following:

pip3 install -r requirements.txt
mkdocs serve

If only reviewing pull requests is required, using a pre-packaged container with all custom theme modifications can be done with the following commands:

docker pull ghcr.io/nanocurrency/nano-docs:pr-<pull_request_number>
docker run --rm -it -p 8000:8000 ghcr.io/nanocurrency/nano-docs:pr-<pull_request_number>

Note that because a local volume isn't being mounted this pull request review approach is only good for validating changes and not for development purposes. These PR-specific containers will be deleted once the related pull request is either closed or merged. If an offline version of the docs are needed, the container tag latest is also available and updated on each change to the master branch.

Access the site at http://localhost:8000. This supports automatic rebuilding, so anytime changes are saved to the documentation or configuration, it will be rebuilt and refresh the page. Some search indexing may remain cache between builds.

Formatting and Organization Tips

Title and description

At the top of every page (not snippets) two fields should be added title: and description: which will be converted to values of <title> and <meta> tags in the header to better inform search engines, social scraping tools and more.

Headers

Pages automatically have a <h1> title setup for them based on the page name, so headers ## (<h2>) and higher should only be used to organize the content.

Table of Contents

Currently, the ToC on the right side is limited to a depth of 4, so ##, ###, and #### will be included there. Higher header levels can be used on the page to better organize content but will not be in the ToC.

Links

MkDocs has a link checker built in that can be run using the --strict flag on mkdocs serve, or mkdocs build command. This flag is included in the build pipeline. For it to work, links must be referencing the relative file path with the file extension included and no trailing slashes. Anchors are not included in this check. Although relative URLs will function if used, they will not be verified by the link checker.

For example, linking from a page in therunning-a-node folder to integration-guides would be:

  • Gets checked: ../integration-guides/the-basics.md.
  • Doesn't get checked: /integration-guides/the-basics

Snippets

The snippets directory contains reusable pieces of content which can be inserted as follows:

--8<-- "snippet-file-name.md"

This should be used for simple, duplicated content only and is not a complex templating setup.

Comments

The StripHTML extension is used so that HTML-style comments can be included in the markdown docs. However, for best compatibility, keep them at the top level, not within indented areas/rendered admonition blocks, etc. as much as possible.

<!-- this is a valid comment that will not get rendered to the browser -->

Admonition Extension Quick Reference

Admonition is an extension for MkDocs that provides easy block-styled side content (including collapsible blocks). More details on use can be found here: https://squidfunk.github.io/mkdocs-material/extensions/admonition/. Below is a quick reference for this functionality:

For an always expanded option: !!! note "This is the title" This is the text

For a collapsible option:

??? question "Is this collapsed by default?" Yes, it is

???+ question "Is this expanded by default?" Yes, it is

Types include:

  • note
  • abstract
  • info
  • tip
  • success
  • question
  • warning
  • failure
  • danger
  • bug
  • example
  • quote

Diagrams

Usage of Draw.io is encouraged for generating diagrams:

There is also support for Mermaid Sequence Diagrams, and documentation can be found here: https://mermaidjs.github.io/#/sequenceDiagram, however given the desire to have consistency in the diagrams and the limitations of Mermaid, generating Draw.io type diagrams is preferred.

Octicon icons

The scripts for using Github's Octicons are included in the header. Details for available icons can be found here: https://primer.style/octicons/. Usage should be limited. Example currently available in announcement block:

<span class="iconify" data-icon="octicon-tag-16" data-inline="false"></span>

nano-docs's People

Contributors

angristan avatar argakiig avatar bananodroid avatar bitdesert avatar clemahieu avatar codesoap avatar cryptocode avatar darrenalex avatar ethunxxx avatar gak avatar git-sgmoore avatar giteska avatar guilhermelawless avatar guywhoknowstheguy avatar jerzystanislawski avatar jserv avatar matm avatar meltingice avatar qwahzi avatar rickinano avatar roconda avatar schenkty avatar sergiysw avatar shryder avatar skynxt avatar srayman avatar tarmo888 avatar thsfs avatar wezrule avatar zhyatt avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

nano-docs's Issues

Recommend json_block true

@zhyatt
This is available since v19, can we start recommending it now by using it in the documentation examples? The formatted output is much easier to read.

What about the doc translation?

Hello,

I asked quite a while ago about the eventuality of translating the documentation. I was answered to wait for the release of the new version of the official website, which is now online.

Any plans on the way to let people translate the doc, now ? I'm quite eager to.

Add frontier confirmation modes

To cover changes in nanocurrency/nano-node#2175

Auto mode (default): If not Principal Representative, start frontier confirmation process every 15 minutes; if Principal Representative, start frontier confirmation process every 3 minutes

Always: Start frontier confirmation process every 3 minutes

Disabled: Do not start frontier confirmation process

RPC command formatting and cleanup

The current setup for RPC commands needs some cleanup including:

  • Adjusting command titles to be the action used
  • Better formatting of request/response details
  • More consistent formatting across the board, including version callouts

Suggestions for how best to do the formatting of request/response details are welcome. A possible approach was included for the account_balance, account_block_count and account_info calls using tables for keys, version, format, etc.

Once we get the suggested formatting down additional cleanup efforts on the remaining calls can be done more consistently and this ticket will be used to help track that work.

Expanding the info regarding Nano seed and key derivation

The documentation should be updated at some point regarding the key derivation. I think it's correct info, just missing a few points.
I think it should be written by someone who really knows this, I just found out by trial and error.

For example from here: https://docs.nano.org/integration-guides/the-basics/#seed
PrivK[i] = blake2b(outLen = 32, input = seed || i)

That's true but should be noted that seed is not the same as the BIP39 seed which is 128 in length.

From here: https://docs.nano.org/integration-guides/key-management/
Derived Private Key for 44'/165'/0'

Yes, that's also true but should be noted that type of derivation is not the same as the one mentioned above using blake2b. It results in different private keys!
Should also be mentioned that the 24-word mnemonic can be derived from a Nano 64 length seed using either

BIP39:
mnemonic = bip39.entropyToMnemonic('seed')

or using nanocurrency-web-js like so:
mnemonic = wallet.generate('seed').mnemonic

Furthermore, the 64 nano seed can also be derived from a 24-word mnemonic by:
seed = bip39.mnemonicToEntropy(mnemonic)

Maybe also mention how to get the private key using both derivation methods (from either nanocurrency-web-js or nanocurrency-js

Default Nano (nanocurrency-js, index 0):
privKey = nano.deriveSecretKey(seed, 0)
Should be the same as blake2b(outLen = 32, input = seed || 0) but haven't tested

Ledger key (nanocurrency-web-js, index 0, seed is 64 char (also called entropy), nanowallet.seed is the 128 char BIP39 seed):
nanowallet = wallet.generate(seed)
accounts = nanowallet.accounts(nanowallet.seed, 0, 0)
privKey = accounts[0].privateKey
This should be the same as BIP39 derivation from 44'/165'/0'

Mention v20 upgrades can take a few minutes

nanocurrency/nano-node#2283 is modifying all accounts to use the representative account instead of the representative block. This has been found to take a few minutes on some systems.

The account_info RPC should mark rep_block as deprecated and the representative shown by default when it eventually gets removed, RPC 2.0?

Add more information about using docker and an exposed RPC address

The node prints this message when "::ffff:0.0.0.0" is set as address an control is enabled: WARNING: control-level RPCs are enabled on non-local address ::ffff:0.0.0.0, potentially allowing wallet access outside local computer

We should add more information on this in the documentation and include the link in the printed message.

If not using docker:

  • A non-local address exposes the RPC
  • A firewall is necessary to properly manage exposure
  • Recommended to use a proxy, V22 will bring management using API-keys but should be used with SSL or a proxy

If using docker:

  • A non-local address is the default and required for other applications to use the RPC
  • The setting by itself does not expose the RPC to outside the local machine, this depends on how the run command is created
  • We have a warning against redirecting other addresses than localhost to the RPC port
  • Docker overrides ufw - even if rules are defined in ufw to only allow certain IPs through the RPC port, docker overrides this unless a special configuration is used.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.