Start9/documentation
2
0
Fork 0
mirror of https://github.com/Start9Labs/documentation.git synced 2026-03-26 10:21:53 +00:00
Code Issues Packages Projects Releases Wiki Activity

More scaffolding

Browse Source
This commit is contained in:
kn0wmad
2021-12-05 23:29:52 -07:00
committed by Lucy Cifferello
parent 4dc72ad620
commit 03d33ca4ec
130 changed files with 4892 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
source/03-index.md → source/03-todo.md
View File

@@ -10,7 +10,7 @@
- Android
- iOS
- Walkthrough
- Tabs Overview
- EmbassyOS Overview
- Updating EOS
- Services
- Service Marketplace <link to marketplace>
@@ -27,7 +27,7 @@
- Basic Config
- Name Your Embassy
- WiFi Setup
- Running Tor
- Tor Setup
- Desktop
- Linux
- Mac
@@ -46,7 +46,7 @@
- Mobile
- Android
- iOS
- Known Limitations
- Platform Limitations
- Desktop
- Linux
- Mac
@@ -90,9 +90,10 @@
- Start9
- EmbassyOS
- Bitcoin/Lightning
- LAN
- SSL
- Tor
- Networks
- LAN
- SSL
- Tor
- FAQ
- General
- Embassy
@@ -101,7 +102,8 @@
- DIY
- Basic Usage
- Services
- Bitcoin and Lightning Network
- Bitcoin
- aLightning Network
# Developer Documentation
- Service Packaging Guide

14
source/0ld-docs/contributing/embassyos.rst Normal file
View File

@@ -0,0 +1,14 @@
.. _embassyos_contribute:
*********
EmbassyOS
*********
We ❤️ contributions!
Please follow the guide `here <https://github.com/Start9Labs/embassy-os/blob/master/CONTRIBUTING.md>`_ and reach out to the `community dev <https://matrix.to/#/#community-dev:matrix.start9labs.com>`_ channel on Matrix with any questions.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

29
source/0ld-docs/contributing/services/backups.rst Normal file
View File

@@ -0,0 +1,29 @@
.. _service_backups:
***************
Service Backups
***************
Everything within the root of the mounted volume directory will be stored in an EmbassyOS backup. This includes the config (config.yaml) and properties (stats.yaml) files, as well as any other persisted data within the volume directory.
For restoration purposes, it might be beneficial to ignore certain files or folders. For instance, ignore the shared/public folder that is mounted for dependencies that expose this feature as it causes data inconsistencies on restore.
In this case, create a `.backupignore` file. This file contains a list of relative paths to the ignored files.
Example
=======
The `btcpayserver wrapper <https://github.com/Start9Labs/btcpayserver-wrapper/blob/master/configurator/src/templates/.backupignore.templates>`_ demonstrates a good use of a backupignore template.
Ultimately, ``/datadir/.backupignore`` gets populated with:
.. code::
/root/volumes/btcpayserver/start9/public
/root/volumes/btcpayserver/start9/shared
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

617
source/0ld-docs/contributing/services/config.rst Normal file
View File

@@ -0,0 +1,617 @@
.. _service_config:
****************************
Service Config Specification
****************************
Overview
========
Most self-hosted applications require the user to tell the app how to behave using a config file in a specific format, environment variables, command-line arguments, or some combination of these inputs. One of the coolest features of EmbassyOS is that, when packaged correctly, the app's configuration will be available to the user as a slick GUI that always produces a valid configuration no matter how little experience or skill the user has.
With EmbassyOS, this means a service wrappers' configuration requires a particular format and rule structure to ensure it integrates smoothly with the user interface. This format enables clean handling of improper values and dependency management.
The outcome of this step is two files:
:ref:`config_spec.yaml <config_spec>`
:ref:`config_rules.yaml <config_rules>`
These files contain a detailed mapping of configuration options with acceptable values, defaults, and relational rule-sets.
For example, if the user chooses config option A, then config option B must be between 5 and 10. This enables a simple GUI configuration experience, complete with validations and protections, for users. They do not have to worry about the consequences of a wrong value in a ``.conf`` file.
.. _config_spec:
Config Spec
===========
Overview
--------
.. figure:: /_static/images/service/bitcoin_config.png
:width: 80%
:alt: Bitcoin Config
This file defines the structure of configuration options your service depends on to run. It additionally can include configuration options that users might want to enable for more advanced or customized usage. Ultimately, these values influence the UI elements for a user to interact with. Specifically, they evaluate to the options available when managing a service, such as:
- Prior to service installation when the user needs to be made aware of any necessary dependency configurations
- When the user installs a service and the service is in the "Needs Config" state
- Whenever a user edits a service config
- When config pointers get updated
The neat part about this file is that each ValueSpec type gets translated into a specific front end component. For instance, boolean values display as a toggle button.
.. figure:: /_static/images/service/boolean_toggle.png
:width: 80%
:alt: Example boolean toggle
Another advantage is the ability to define default values. These values automatically get populated if the user selects the ``Default`` option when setting up a service in ``Needs Config`` state. This is super convenient for users who want to get up and running quickly.
Types
-----
ConfigSpec Type:
.. code::
key: ValueSpec
ValueSpec Type: Boolean | Enum | List | Number | Object | String | Union | Pointer (see below for details)
Implementation Guide
--------------------
The following section contains implementation specifications for the ``config_spec.yaml`` file.
- All keys are ``kebab-case`` strings, which correspond to the service (app) id
- All values are one the following specs (ie. ``ValueSpec`` type):
:ref:`boolean <boolean>`
:ref:`enum <enum>`
:ref:`list <list>`
:ref:`number <number>`
:ref:`object <object>`
:ref:`string <string>`
:ref:`union <union>`
:ref:`pointer <pointer>`
- In the examples for each value spec type below, ``Option`` means the key is optional. Otherwise, the key is required.
- Descriptions are optional, but recommended
- Name corresponds to the name of the config field
- Find a complete example :ref:`here <example_config_spec>`
- Change warning text displays when the value is altered
.. _boolean:
Boolean
^^^^^^^
Config value specification denoted as a boolean value. A default value is required.
``ValueSpec`` Type:
.. code::
type: boolean
name: String
description: Option<String>
changeWarning: Option<String>
default: Boolean
Example:
.. code:: yaml
fetch-blocks:
type: boolean
name: Fetch Blocks
description: Fetch blocks from the network if pruned from disk
default: true
.. _enum:
Enum
^^^^
Config value specification denoted as an enum value. Enums values must be a unique set. If no default is provided, ``null`` will be the assumed value.
ValueSpec Type:
.. code::
type: enum
name: String
description: Option<String>
changeWarning: Option<String>
default: Option<Enum>
values: Set<String>
.. code:: yaml
theme-mode:
type: enum
name: Theme Mode
values:
- NIGHT
- DAY
valueNames:
NIGHT: Night
DAY: Day
default: NIGHT
.. _list:
List
^^^^
The list type describes an array of values. The values must consist of the same subtype, which can be any of the ValueSpec types available in the EmbassyOS config specification.
Lists of any type do not contain the default for each item in list. The list *itself* can have a default. If no default is provided, ``null`` will be the assumed value.
Range is loosely based off mathematical range syntax, with infinity replaced with ``*``:
``[ || ]`` = inclusive
``( || )`` = noninclusive
``*`` = infinity on either end
eg:
.. code::
[0,*) - all numbers to infinity including 0
ValueSpec Type:
.. code::
type: list
name: String
description: Option<String>
subtype: enum || number || object || string || union
range: NumRange<unsigned integer>
spec: ValueSpec
default: ValueSpec
Example:
.. code:: yaml
allowed-calls:
type: list
name: Allowed Calls
description: The list of all RPC methods this user is allowed to make
subtype: enum
range: "[0, *)"
spec:
type: enum
values:
- item
- item
.. _number:
Number
^^^^^^
A number value within an optionally defined range. Nullable field is required. If ``nullable`` is true, the default is assumed to be ``null`` if it is not provided.
ValueSpec Type:
.. code::
type: number
name: String
description: Option<String>
changeWarning: Option<String>
default: Boolean
nullable: Boolean
range: Option<NumRange<64 bit floating point>>
integral: Boolean
units: Option<String>
Example:
.. code:: yaml
type: number
name: Peer Message Timeout
description: How long to wait for a response from a peer before failing
nullable: false
integral: true
units: Seconds
range: "[0, *)"
default: 30
.. _object:
Object Type
^^^^^^^^^^^
A nested representation of a ConfigSpec. The object type takes the same structure under the ``spec`` key as a ConfigSpec: a key indicates the field name, and the value denotes the ValueSpec type for that field.
There is no default option for the object type. Rather, the option ``null-by-default`` should be used to indicate the default as ``null``. If null by default is true, nullable must be true. If null by default is false, nullable could be either.
``unique-by`` indicates whether duplicates can be permitted in the list.
ValueSpec Type:
.. code::
type: object
name: String
description: Option<String>
changeWarning: Option<String>
nullable: Boolean
null-by-default: Boolean
display-as: Option<String>
unique-by: UniqueBy
spec: ConfigSpec
type UniqueBy = null | string | { any: UniqueBy[] } | { all: UniqueBy[] }
Example:
.. code:: yaml
type: object
name: Advanced
description: Advanced settings for Bitcoin Proxy
nullable: false
spec:
tor-only:
type: boolean
name: Only Tor Peers
description: Use Tor for all peer connections
default: false
peer-timeout:
type: number
name: Peer Message Timeout
description: How long to wait for a response from a peer before failing
nullable: false
integral: true
units: Seconds
range: "[0, *)"
default: 30
max-peer-age:
type: number
name: Maximum Peer Age
description: How long to wait before refreshing the peer list
nullable: false
integral: true
units: Seconds
range: "[0, *)"
default: 300
max-peer-concurrency:
type: number
name: Maximum Peer Concurrency
description: How many peers to reach out to concurrently for block data
nullable: true
integral: true
range: "[1, *)"
default: 1
.. _string:
String
^^^^^^
There are various options for string values. They can optionally be marked as copyable or masked, such as for passwords, which will reflect the UI element display. A pattern, expressed in regex, can be denoted. If it exists, this field requires both the pattern type (ie. Regex) and pattern description (ie. an explanation of the pattern requirements).
If the default type is ``Entropy``, the charset can optionally specify an inclusive ranged character set (ie. "a-f,0-9").
ValueSpec Type:
.. code::
type: string
name: String
description: Option<String>
changeWarning: Option<String>
copyable: Option<boolean>
masked: Option<boolean>
nullable: Boolean
default: String | Entropy
pattern: Option<Regex>
pattern-description: Option<String>
Entropy Type:
.. code::
charset: Option<String>
len: integer
Examples:
.. code::
color:
type: string
name: Color
description: Color value for the Lightning Network
nullable: false
pattern: "[0-9a-fA-F]{6}"
patternDescription: |
Must be a valid 6 digit hexadecimal RGB value. The first two digits are red, middle two are green and final two are
blue
default:
charset: "a-f,0-9"
len: 6
password:
type: string
name: Password
description: The password for the RPC User
nullable: false
copyable: true
masked: true
default:
charset: "a-z,A-Z,0-9"
len: 22
.. _pointer:
Pointer
^^^^^^^
The pointer type *points* to a config value on another service installed on EmbassyOS (ie. app subtype) or to the EmbassyOS system (ie. system subtype). When pointing to another service, the ``index`` field indicates the path to the desired config variable.
ValueSpec Type:
.. code::
type: pointer
name: String
description: Option<String>
changeWarning: Option<String>
subtype: app | system
app-id: String (*always* kebab case)
target: AppPointerSpecVariants | SystemPointerSpecVariants
index: Option<String> (dependent on target being AppPointerSpecVariants)
AppPointerSpecVariants = LanAddress | TorAddress | TorKey | Config
SystemPointerSpecVariants = HostIp
Example:
.. code::
user:
type: pointer
name: RPC Username
description: The username for the RPC user for Bitcoin Core
subtype: app
app-id: bitcoind
target: config
index: "rpc.username"
.. _union:
Union
^^^^^
This type describes a necessary dependency. Multiple variants can be expressed to enable the user the option to connect to another service (internal dependency) or outside source (external dependency).
For example, the Bitcoin Proxy service is united with an instance of Bitcoin. Three variants are defined: internal, external, and a quick connect. In this case, internal refers to the Bitcoin Core instance running on EmbassyOS, and defines the RPC credentials necessary for connecting; external refers to a Bitcoin Core node running on a different device, and defines the RPC credentials necessary for connecting; quick connect refers to yet another method of connecting to a Bitcoin Core node, optimized for convenience.
Default is required and corresponds to one of the variants.
``Tag`` is the key that will be rendered on the UI element.
ValueSpec Type;
.. code::
type: union
name: String
description: Option<String>
changeWarning: Option<String>
default: Boolean
tag: Tag
variants: Map<String, ConfigSpec>
display-as: Option<String>
unique-by: any | all | exactly | notUnique
Tag Type:
.. code::
id: String
name: String
description: Option<String>
variant-names: Map<String, String>
.. _example_config_spec:
Example:
.. code:: yaml
bitcoind:
type: union
name: Bitcoin Core
description: The Bitcoin Core node to connect to
tag:
id: type
name: Type
description: |
- Internal: The Bitcoin Core service installed to your Embassy
- External: A Bitcoin Core node running on a different device
- Quick Connect: A Quick Connect URL for an unpruned Bitcoin Core node
variant-names:
internal: Internal
external: External
quick-connect: Quick Connect
default: internal
variants:
internal:
address:
type: pointer
name: Local Address
description: The LAN IP address of your Bitcoin Core service
subtype: app
app-id: bitcoind
target: lan-address
user:
type: pointer
name: RPC Username
description: The username for the RPC user for Bitcoin Core
subtype: app
app-id: bitcoind
target: config
index: "rpc.username"
password:
type: pointer
name: RPC Password
description: The password for the RPC user for Bitcoin Core
subtype: app
app-id: bitcoind
target: config
index: "rpc.password"
external:
addressext:
type: string
name: Public Address
description: The public address of your Bitcoin Core RPC server
nullable: false
userext:
type: string
name: RPC Username
description: The username for the RPC user on your Bitcoin Core RPC server
nullable: false
passwordext:
type: string
name: RPC Password
description: The password for the RPC user on your Bitcoin Core RPC server
nullable: false
quick-connect:
quick-connect-url:
type: string
name: Quick Connect URL
description: The Quick Connect URL for your Bitcoin Core RPC server
nullable: false
pattern: 'btcstandup://[^:]*:[^@]*@[a-zA-Z0-9.-]+:[0-9]+(/(\?(label=.+)?)?)?'
patternDescription: Must be a valid Quick Connect URL. For help, check out https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Quick-Connect-API.md
.. _config_rules:
Config Rules
============
This file defines the configuration rules, or the rule-set that defines dependencies between config variables. In practice, config rules are for auto-configuring self dependencies. Self dependencies are internal dependencies of a service, such as if the setting of one config variable informs the option of another setting. These "dependencies" are configured as rules.
A rule is a boolean expression that we demand to be true. It is not true if the expression fails the rule parser.
They follow the `Backus–Naur <https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form>`_ meta-syntax for writing rules.
Rules are composed of two main concepts:
* Variables - accessor into a configuration
* Terms - either a variable or type literal (ie. a boolean term is a boolean variable, a boolean expression, or a comparison operation between numbers or strings)
Variables can be booleans, numbers, or strings, and have a different syntax depending on the type. These type annotations check your config rules against your config spec and throw an error if invalid.
- ``?`` - Casts to boolean value. If the value is not a boolean, this notes whether or not the value is null.
- ``#`` - Treat the value as a number. If it is not a number, the value will be parsed as NaN. String numbers are not currently supported.
- ``'`` - Cast the value into a string. Applies to any value except for an object or a list.
- ``!`` - Equals not.
.. note::
Config rules are processed in order.
If application does not satisfy a rule, a set of suggestions should be provided. These suggestions are in the form of the operation to preform:
- ``Set`` - set the value
- ``Push`` - add to the value (such as to a list)
- ``Delete`` - delete the value
.. code:: typescript
enum SuggestionVariant = Set | Delete | Push
interface Set {
var: String, // fully qualified path without typecast
// one of the following three variants are required
to: Option<String> // a string expression, use when tying another config value
to-value: Option<String>
to-entropy: Option<{
charset: String (eg. 'a-z,A-Z,0-9')
len: Number
}>
}
interface Delete {
src: String, // path to key - removes if in a list
}
interface Push {
to: String,
value: String, // string literal of value to be set
}
Set Examples:
.. code:: yaml
- SET:
# the key in config you want to set
var: 'users.[first(item => ''item.name = "c-lightning")].password'
# the value in config that you will set
to-entropy:
charset: "a-z,A-Z,0-9"
len: 22
- SET:
var: 'users.[first(item => ''item.name = "c-lightning")].fetch-blocks'
to-value: true
Push Examples:
.. code:: yaml
- PUSH:
to: "users"
value:
name: c-lightning
allowed-calls: []
- PUSH:
to: 'users.[first(item => ''item.name = "c-lightning")].allowed-calls'
value: "getnetworkinfo"
Full example from `c-lightning manifest <https://github.com/Start9Labs/c-lightning-wrapper/blob/master/manifest.yaml>`_:
.. code:: yaml
config:
- rule: '''users.*.name = "c-lightning"'
description: 'Must have an RPC user named "c-lightning"'
suggestions:
- PUSH:
to: "users"
value:
name: c-lightning
allowed-calls: []
- SET:
var: 'users.[first(item => ''item.name = "c-lightning")].password'
to-entropy:
charset: "a-z,A-Z,0-9"
len: 22
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

40
source/0ld-docs/contributing/services/docker.rst Normal file
View File

@@ -0,0 +1,40 @@
.. _service_docker:
******************
Service Dockerfile
******************
Dockerfile
==========
This purpose of the Dockerfile is to define how to build the image for the service. It declares the environment and building stages.
The Dockerfile is responsible for mounting the service application to whatever volume the manifest specifies, typically ``/root/.<service-id>``.
Since the build requires specific arm runtime environments, these base images can be imported into the Dockerfile as a starting point so the base system does not need to be completely redefined. This enables importing a specific build environment version that encapsulates any necessary libraries for running the service build, eg. golang, rust.
For instance:
``FROM alpine:3.12``
``FROM arm32v7/alpine``
``FROM arm32v7/golang:alpine``
We recommended using ``alpine`` since it produces the smallest image. We try to keep the image under 100MB when possible.
Entry-point
===========
The ``docker_entrypoint.sh`` defines what to do when the service application starts.
It consists of a bash script that completes any environment setup (eg. creating folder substructure), sets any environment variables, and executes the run command. The only required feature of this file is to execute the run commands for EmbassyOS.
Example
=======
The `LND wrapper <https://github.com/Start9Labs/lnd-wrapper/blob/master/Dockerfile>`_ features a well defined Dockerfile, for example.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

44
source/0ld-docs/contributing/services/index.rst Normal file
View File

@@ -0,0 +1,44 @@
.. _service_pacakge:
***********************
Service Packaging Guide
***********************
Welcome! If you are here, you are interested in becoming part of the mission to change the future of personal computing. This guide will take you through the process of packaging a service for EmbassyOS, a novel, self-hosted, sovereign computing platform.
A service in this context is any open source project that has been bundled into the appropriate format to run on EmbassyOS. By configuring and packaging a project according to this guide, it can be installed on EmbassyOS with no command line or technical expertise required. This opens up an entire platform for self-hosted software to run independent of third parties in a completely private and sovereign way for all individuals.
This guide is technical, but breaks down the steps for deployment. If you have any feedback or questions concerning this guide, please don't hesitate to `reach out <https://matrix.to/#/#community-dev:matrix.start9labs.com>`_ or submit a pull request with alterations.
To start, you will need to acquire EmbassyOS for testing the packaged service. This can be done by:
- building from `source <https://github.com/Start9Labs/embassy-os/blob/master/CONTRIBUTING.md#setting-up-your-development-environment>`_
- following the :ref:`DIY <diy>` guide
- :ref:`purchasing <purchasing>` the ready to run personal server
While you are waiting to receive or assemble a device, you can begin the process of packaging a project. The sections below outline these steps in detail.
Happy building!
.. toctree::
:maxdepth: 1
Overview <overview>
Wrapper <wrapper>
Manifest <manifest>
Docker <docker>
Makefile <makefile>
Config <config>
Properties <properties>
Instructions <instructions>
Backups <backups>
Submission process
------------------
When you have built and tested your project for EmbassyOS, please send Start9 a submission with the project repository to ``dev@start9labs.com``. After being reviewed for security and compatibility, the service will be deployed to the marketplace and available for all EmbassyOS users to download.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

23
source/0ld-docs/contributing/services/instructions.rst Normal file
View File

@@ -0,0 +1,23 @@
.. _service_instructions:
************************************
Service Instructions & Documentation
************************************
Within each wrapper repository should exist a ``docs`` directory. This folder should include any pertinent documentation, instructions, external integrations, or other details about the service that users or developers might find relevant.
If an ``instructions.md`` file is included, this markdown formatted file will be rendered in the "Instructions" tab within the service detail menu on EmbassyOS:
.. figure:: /_static/images/service/bitcoin_instructions.png
:width: 80%
:alt: Bitcoin Instructions
Example
=======
The `bitcoind wrapper <https://github.com/Start9Labs/bitcoind-wrapper/tree/master/docs>`_ demonstrates a good use of instructions and external integrations.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

30
source/0ld-docs/contributing/services/makefile.rst Normal file
View File

@@ -0,0 +1,30 @@
.. _service_makefile:
****************
Service Makefile
****************
.. note::
*This file is optional*
A Makefile serves as a convenience for outlining the build. This helps streamline additional developer contributions to the project. Please reference the GNU `documentation <https://www.gnu.org/software/make/manual/html_node/Introduction.html>`_ for implementation details.
An alternative to using ``make`` is to use the `nix <https://nixos.wiki/wiki/Nix>`_ specification.
This purpose of this file is to:
- Read the docker container and build the project
- Build all prerequisites for running the docker file
- Build all dependencies
- Package ``config_rules.yaml``, ``config_spec.yaml``, ``manifest.yaml``, and ``image.tar`` into an ``.s9pk`` extension by invoking ``appmgr``.
Example
=======
The `LND wrapper <https://github.com/Start9Labs/lnd-wrapper/blob/master/Makefile>`_ features a well defined Makefile, for example.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

352
source/0ld-docs/contributing/services/manifest.rst Normal file
View File

@@ -0,0 +1,352 @@
.. _service_manifest:
****************
Service Manifest
****************
Overview
========
This file describes the service and it's requirements. It is used to:
- create a listing in the marketplace
- denote any installation considerations
- define dependency requirements
Each time a service is updated, the manifest should be updated to include the new version, release notes, and any pertinent updates to the install, uninstall, or restoration flows. All this information is displayed in the marketplace listing, and the optionally denoted alerts will be displayed when appropriate to provide the user with more information.
For instance, `LND displays alerts <https://github.com/Start9Labs/lnd-wrapper/blob/master/manifest.yaml#L28>`_ around restoration since data will be overwritten.
There is nothing you need to do as a developer to set up Tor for running a service. This is *completely* handled by EmbassyOS - a Tor address will be automatically generated when the service is installed. Just define the port and which version of Tor the service needs in this manifest file! You do, however, need to ensure the service is in fact capable of running over Tor.
The manifest is also responsible for outlining service :ref:`dependencies <dependencies>`. By defining rules using the :ref:`EmbassyOS DSL specification <config_rules>`, users can easily and selectively install, uninstall, and update any service without getting stuck in dependency hell. EmbassyOS presents this information in a polished install/uninstall/update wizard, so there's no need for editing configuration files or jumping into the command line. For you as a developer, this simply means populating this key in the manifest!
Formatting
==========
- Serialization language:``.yaml``
- Case style: ``kebab-case``
Type definitions
================
Below are the types and sub-type definitions, with necessary elaborations. Any item that contains ``Option<>`` is an optional field.
.. code:: yaml
# manifest version compatibility ie. v0 (this is currently the only option)
compat: v0
# service id, used for uniqueness and BE identification ie. bitcoind
id: String
# version number of the release conforming to the semantic versioning scheme
version: String
# display name of service
title: String
# an object containing a short and long description of the service. TODO character lengths
description:
short: String
long: String
# a link to the release tag notes in GitHub, or a short description TODO character length
release-notes: String
# a notification message that should caution the user with any service particularities, eg. beta tech
install-alert: Option<String>
# a notification message warning users of potential problems with uninstalling, such as dependency failures or data loss
uninstall-alert: Option<String>
# a notification message containing warning or details about backup restoration
restore-alert: Option<String>
# denoting the existence of instructions.md
has-instructions: Boolean
# required semver version range of EmbassyOS to run service eg. ">=1.0.0"
os-version-required: VersionReq
# recommended semver version range of EmbassyOS to run service eg."^1.0.0"
os-version-recommended: VersionReq
# a list of objects of ports to run the service on localhost and tor
ports:
- internal: String
tor: String
# currently only tar is supported
image:
type: String
# shared memory container size
shm-size-mb: Option<usize>
# path to mount the image on the volume, ie: /root/bitcoind
mount: String
# read only data exposed to dependencies (path is relevant to mount)
public: Option<String>
# shared filesystem segment with each of your dependencies (path is relevant to mount)
shared: Option<String>
# deprecated - will default to an empty vector
assets: []
# version of tor support, eg. v2, v3
hidden-service-version: String
# A map of dependent services, see below for more details
dependencies: Dependencies
.. _dependencies:
Dependencies
============
Many services depend on other libraries and services on EmbassyOS (such as Bitcoin), sometimes even a particular version of those services, which need to be specified by the developers so that EmbassyOS can handle installing these dependencies under the hood.
The key of each field in the dependencies object is the lowercase, kebab-case app ID of the service that is depended on. Each dependency contains a set of rules that need to be fulfilled as true if the dependency is to be properly installed. The "config rules" here are for auto-configuring dependencies - the action defined by the rule will be executed if the service is auto configured with defaults during initial setup. This simplifies and streamlines the user experience. The interface should provide suggestions for the behavior if the denoted rule cannot be met with previous configurations.
Let's take this snippet for example:
.. code:: yaml
...
dependencies:
btc-rpc-proxy:
version: "^0.1.0"
optional: Can configure an external bitcoin node.
description: Required for fetching validated blocks.
config:
- rule: '''users.*.name = "c-lightning"'
description: 'Must have an RPC user named "c-lightning"'
suggestions:
- PUSH:
to: 'users'
value:
name: c-lightning
...
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`
The service ``btc-rpc-proxy`` is a dependency of the service ``c-lightning``. ``c-lightning`` requires it to be installed at a version >=0.1.0 <0.2.0. There exists a rule that states the config option ``user.name`` must be equal to "c-lightning". If this value does not exist for ``user.name`` when accessed, ``PUSH`` the value "c-lighting" to the field. This all takes place during the initial service configuration, before the service is started for the first time.
.. note::
Dependency config rules are processed in order.
Type definitions
----------------
Types for ``manifest.yaml`` fields:
.. code:: typescript
interface Dependencies [{
serviceId: DepInfo
}]
interface DepInfo {
version: String // ie. 0.11.1.1
optional?: String,
description?: String,
config: [ConfigRule],
],
}
interface ConfigRule {
rule: String, // ie. 'users.*.name = "lnd"
description: String,
suggestions: [SuggestionVariant]
}
interface SuggestionVariant {
SET: {
var: String,
to: SetVariant,
},
DELETE: {
src: String,
},
PUSH: {
to: String,
value: Value,
},
}
interface SetVariant {
to: Option<String>,
to-value: Option<Value>, // ie. true/false
to-entropy: Option<{
charset: String // ie. 'a-z,A-Z,0-9'
len: number
}>
}
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`
Examples
--------
Actual ``manifest.yaml`` files for existing services:
LND
^^^
.. code:: yaml
compat: v0
id: lnd
version: 0.11.1.1
title: Lightning Network Daemon
description:
short: "A complete implementation of a Lightning Network node by Lightning Labs"
long: "LND fully conforms to the Lightning Network specification (BOLTs). BOLT stands for: Basis of Lightning Technology. In the current state lnd is capable of: creating channels, closing channels, managing all channel states (including the exceptional ones!), maintaining a fully authenticated+validated channel graph, performing path finding within the network, passively forwarding incoming payments, sending outgoing onion-encrypted payments through the network, updating advertised fee schedules, and automatic channel management (autopilot)."
release-notes: https://github.com/lightningnetwork/lnd/releases/tag/v0.11.1-beta
ports:
- internal: 8080
tor: 8080
- internal: 9735
tor: 9735
- internal: 9911
tor: 9911
- internal: 10009
tor: 10009
image:
type: tar
mount: /root/.lnd
public: public
has-instructions: true
os-version-required: ">=0.2.8"
os-version-recommended: ">=0.2.8"
install-alert: |
READ CAREFULLY! LND and the Lightning Network are considered beta software. Please use with caution and do not risk more money than you are willing to lose. We encourage frequent backups. If for any reason, you need to restore LND from a backup, your on-chain wallet will be restored, but all your channels will be closed and their funds returned to your on-chain wallet, minus fees. It may also take some time for this process to occur.
uninstall-alert: "READ CAREFULLY! Uninstalling LND will result in permanent loss of data, including its private keys for its on-chain wallet and all channel states. Please make a backup if you have any funds in your on-chain wallet or in any channels. Recovering from backup will restore your on-chain wallet, but due to the architecture of the Lightning Network, your channels cannot be recovered. All your channels will be closed and their funds returned to your on-chain wallet, minus fees. \n"
restore-alert: |
Restoring LND will overwrite its current data, including its on-chain wallet and channels. Any channels opened since the last backup will be forgotten and may linger indefinitely, and channels contained in the backup will be closed and their funds returned to your on-chain wallet, minus fees.
assets: []
hidden-service-version: v3
dependencies:
btc-rpc-proxy:
version: "^0.2.4"
optional: Can alternatively configure an external bitcoin node.
description: Used to fetch validated blocks.
config:
- rule: '''users.*.name = "lnd"'
description: 'Must have an RPC user named "lnd"'
suggestions:
- PUSH:
to: "users"
value:
name: lnd
allowed-calls: []
- SET:
var: 'users.[first(item => ''item.name = "lnd")].password'
to-entropy:
charset: "a-z,A-Z,0-9"
len: 22
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getinfo"'
description: 'RPC user "lnd" must have "getinfo" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getinfo"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getbestblockhash"'
description: 'RPC user "lnd" must have "getbestblockhash" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getbestblockhash"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "gettxout"'
description: 'RPC user "lnd" must have "gettxout" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "gettxout"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getblockchaininfo"'
description: 'RPC user "lnd" must have "getblockchaininfo" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getblockchaininfo"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "sendrawtransaction"'
description: 'RPC user "lnd" must have "sendrawtransaction" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "sendrawtransaction"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getblockhash"'
description: 'RPC user "lnd" must have "getblockhash" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getblockhash"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getblock"'
description: 'RPC user "lnd" must have "getblock" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getblock"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getblockheader"'
description: 'RPC user "lnd" must have "getblockheader" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getblockheader"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "estimatesmartfee"'
description: 'RPC user "lnd" must have "estimatesmartfee" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "estimatesmartfee"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getnetworkinfo"'
description: 'RPC user "lnd" must have "getnetworkinfo" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getnetworkinfo"
- rule: 'users.[first(item => ''item.name = "lnd")].fetch-blocks?'
description: 'RPC user "lnd" must have "Fetch Blocks" enabled'
suggestions:
- SET:
var: 'users.[first(item => ''item.name = "lnd")].fetch-blocks'
to-value: true
bitcoind:
version: "^0.21.0"
optional: Can alternatively configure an external bitcoin node.
description: Used to subscribe to new block events.
config:
- rule: "zmq-enabled?"
description: "Must have an ZeroMQ enabled"
suggestions:
- SET:
var: "zmq-enabled"
to-value: true
Cups
^^^^
.. code:: yaml
compat: v0
id: cups
version: "0.3.6"
title: "Cups Messenger"
description:
short: "Real private messaging"
long: "Cups is a private, self-hosted, peer-to-peer, Tor-based, instant messenger. Unlike other end-to-end encrypted messengers, with Cups on the Embassy there are no trusted third parties."
release-notes: |
Features
- Adds instructions defined by EmbassyOS 0.2.4 instructions feature
ports:
- internal: 59001
tor: 59001
- internal: 80
tor: 80
image:
type: tar
mount: /root
has-instructions: true
os-version-required: ">=0.2.4"
os-version-recommended: ">=0.2.4"
assets:
- src: httpd.conf
dst: "."
overwrite: true
- src: www
dst: "."
overwrite: true
hidden-service-version: v3
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

103
source/0ld-docs/contributing/services/overview.rst Normal file
View File

@@ -0,0 +1,103 @@
.. _service_package_overview:
************************
Service Package Overview
************************
There are several main components that comprise a service package for EmbassyOS. This overview will introduce them and following sections will dive into technical specifics.
First, let's get your system setup with the necessary software dependencies.
Environment Setup
=================
At minimum, ``docker``, ``docker-buildx``, and ``appmgr`` are required. The rest of the recommendations serve to optimize the build process.
Recommended Dependencies
------------------------
`docker <https://docs.docker.com/get-docker>`_
`docker-buildx <https://docs.docker.com/buildx/working-with-buildx/>`_
`appmgr <https://github.com/Start9Labs/embassy-os/tree/master/appmgr>`_
`cargo <https://doc.rust-lang.org/cargo/>`_
`yq (version 4) <https://mikefarah.gitbook.io/yq>`_
`make <https://www.gnu.org/software/make/>`_
`musl <https://github.com/Start9Labs/rust-musl-cross>`_
Package Components
==================
Image
-----
Each service boils down to a Docker image. We're not going to dive into Docker specifics in this guide, since there exists tons of `resources <https://docs.docker.com/>`_ for developing with this containerization tool.
Because the service ultimately runs on a Raspberry Pi, the created Docker image should be a snapshot of an arm based linux environment. The service image is then mounted to the EmbassyOS image during installation. This path is defined in the :ref:`manifest <service_manifest>` configuration file.
The image is immutable, meaning that when the service is updated, the image is replaced with a completely new image containing the updated features.
Volume
------
Each service application gets a volume allocated to it by EmbassyOS. All service application data is stored in this directory and is persisted across updates.
The volume directory (for seeding data into the volume) is typically: ``/root/volumes/<service-id>``.
.. warning::
Any files that are in the image at the volume path will be overwritten when a backup restore occurs.
Dependencies
------------
When it comes to running your own server, managing dependencies is perhaps the most difficult part. The term "dependency hell" emerged from this sentiment. Even the best developers have lost significant amounts of time trying to find, correct, or clarify documentation for dependencies or dependency configuration. Individuals who manage their own servers have specific technical skills and are willing to devote the time and effort necessary to maintain them. Companies have entire departments dedicated to this feat.
Some other personal server products aimed at non-technical individuals tackle this problem by simply hard coding dependencies. Since EmbassyOS is a platform for running all open-source, self-hosted software, it is not possible to hard code every possible service, service dependency, and service dependency configuration forever. Instead, Start9 built a new, unprecedented operating system that touts a generalized, intuitive approach to dependency management and service configuration. EmbassyOS enables users to easily and selectively install, uninstall, and update any service they want without getting stuck in dependency hell.
This may sound cool or neat, but it is more than that: *it’s novel*. This has never been done before.
The key to making the system work is a new, domain-specific-language (DSL) and set of standards that are used by developers to define the rules and requirements of their services. Run in the context of EmbassyOS, these rules and requirements appear as simple UI elements, such as inputs, toggles, and drop downs, and they are enforced by validations and clear user instructions. Using this system, what previously required involved time and expertise, can now be done by anyone in a matter of seconds.
This DSL is utilized in the :ref:`config rules <config_rules>` and :ref:`dependencies <dependencies>` key in the service manifest.
Manifest
--------
This file describes the service and its requirements. It is used to:
- create a listing in the marketplace
- denote any installation considerations
- define dependency requirements
Each time a service is updated, the manifest should be updated to include the new version, release notes, and any pertinent updates to the install, uninstall, or restoration flows. All this information is displayed in the marketplace listing, and the optionally denoted alerts will be displayed when appropriate to provide the user with more information about the particularities of the service.
For instance, `LND displays alerts <https://github.com/Start9Labs/lnd-wrapper/blob/master/manifest.yaml#L28>`_ around restoration since data will be overwritten.
There is nothing you need to do as a developer to enable the service to run over Tor. This is *completely* handled by EmbassyOS - a Tor address will be automatically generated and an Nginx server configured (if a client application) when the service is installed. Just define which version of Tor your service needs in this manifest file!
Config
------
Most self-hosted applications require the user to tell the app how to behave using a config file in a specific format, environment variables, command-line arguments, or some combination of these inputs. One of the coolest features of EmbassyOS is that, when packaged correctly, the app's :ref:`configuration <service_config>` will be available to the user as a slick GUI that always produces a valid configuration no matter how little experience or skill the user has.
With EmbassyOS, this means a service wrappers' configuration requires a particular format and rule structure to ensure it integrates smoothly with the user interface. This format enables clean handling of improper values and configuration dependencies.
.s9pk Bundle
------------
The configuration and manifest files get bundled into the ``.s9pk`` package, which is `built using appmgr <https://github.com/Start9Labs/embassy-os/tree/master/appmgr>`_. Each new version release should include the updated version of these files re-bundled into a new binary. This is the file that will be downloaded from the marketplace. Upon user initiation, EmbassyOS then un-packages and installs the service.
Hello World Example
-------------------
For reference, the `Hello world <https://github.com/Start9Labs/hello-world-wrapper>`_ repository should be used as an example. A project template can be cloned using the "Use this template" button in GitHub.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

25
source/0ld-docs/contributing/services/properties.rst Normal file
View File

@@ -0,0 +1,25 @@
.. _service_properties:
******************
Service Properties
******************
The output of this step is a file titled ``stats.yaml``. This file contains a mapping of the values that will be displayed in the ``Properties`` section in a service's menu.
.. figure:: /_static/images/service/service_properties.png
:width: 80%
:alt: Service Properties
Service Properties Tab
Due to the fact that config variables are only available when the service is running, this file can only be populated at runtime. In services Start9 has wrapped or created, we typically handle this in ``configurator/src/main.rs``. This file is essentially a script that acquires the necessary values at runtime from config (eg. ``/root/.lnd/start9/config.yaml``), and dynamically populating them to the ``stats.yaml`` file, marking each value with the appropriate keys for UI display (ie. masked or copyable). Running the configurator is typically included in the ``docker_entrypoint.sh`` file.
Example
=======
A good example of the configurator producing the ``stats.yaml`` file can be found `here <https://github.com/Start9Labs/lnd-wrapper/blob/master/configurator/src/main.rs>`_.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

42
source/0ld-docs/contributing/services/wrapper.rst Normal file
View File

@@ -0,0 +1,42 @@
.. _service_wrapper:
***************
Service Wrapper
***************
Each service is bound with a wrapper repository, which contains everything you need to build a service.
The purpose of this repo is:
- Denote any dependencies required to run and build the project
- To define the necessary, ``config_rules.yaml``, ``config_spec.yaml`` and ``manifest.yaml`` options
- To build the project into the ``.s9pk`` format digestible to EmbassyOS
- Link to the source project as a git submodule
- Define the docker file for running the project on EmbassyOS
- Provide documentation for the project, especially user runbook instructions
- symlink of ``instructions.md`` from ``docs`` directory to wrapper repo root, if included
File Structure
==============
The project structure should be used as a model:
.. code-block:: bash
├── Dockerfile
├── Makefile (optional)
├── README.md
├── config_rules.yaml
├── config_spec.yaml
├── <submodule_project_dir>
├── docker_entrypoint.sh
├── docs
│ └── instructions.md
└── manifest.yaml
Submodule
==========
`Git submodules <https://www.git-scm.com/book/en/v2/Git-Tools-Submodules>`_ allow use of another project while in the working project directory. Setting up this feature enables linking of the source service repository so that its context is available.
Run ``git submodule add <link_to_source_project>``

29
source/0ld-docs/misc-guides/available-services.rst Normal file
View File

@@ -0,0 +1,29 @@
.. _available-services:
******************
Available Services
******************
A list of currently-available services for the Embassy.
Bitcoin-related services
========================
* `Bitcoin <https://github.com/Start9Labs/bitcoind-wrapper/tree/master/docs>`_
* `Bitcoin Proxy <https://github.com/Start9Labs/btc-rpc-proxy-wrapper/tree/master/docs>`_
* `Lightning Network Daemon (LND) <https://github.com/Start9Labs/lnd-wrapper/tree/master/docs>`_
* `c-lightning <https://github.com/Start9Labs/c-lightning-wrapper/tree/master/docs>`_
* `Ride the Lightning (RTL) <https://github.com/Start9Labs/ride-the-lightning-wrapper/tree/master/docs>`_
* `Spark Wallet <https://github.com/Start9Labs/spark-wallet-wrapper/tree/master/docs>`_
* `BTCPayServer <https://github.com/Start9Labs/btcpayserver-wrapper>`_
* `Sphinx Chat <https://sphinx.chat/>`_
Other services
==============
* `Bitwarden <https://github.com/Start9Labs/bitwarden-wrapper/tree/master/docs>`_
* `Burn After Reading <https://github.com/Start9Labs/burn-after-reading>`_
* `Cups <https://github.com/Start9Labs/cups-wrapper/tree/master/docs>`_
* `File Browser <https://github.com/Start9Labs/filebrowser-wrapper/tree/master/docs>`_
* `Mastodon <https://github.com/Start9Labs/mastodon-wrapper>`_
* `Embassy Pages <https://github.com/Start9Labs/embassy-pages-wrapper>`_

26
source/0ld-docs/misc-guides/bitcoin-cli.rst Normal file
View File

@@ -0,0 +1,26 @@
.. _bitcoin-cli:
*****************
Using Bitcoin-Cli
*****************
Instructions for accessing the bitcoind service in order to issue commands directly.
.. warning:: This is an advanced feature and should be used with caution. Start9 is not responsible for any damage you might cause through SSH access.
1. First, you will need SSH access. Please see the :ref:`setup instructions <ssh-setup>` for details.
2. Access your Embassy and then you can interact with the bitcoind docker container using the following syntax::
sudo docker exec bitcoind bitcoin-cli COMMAND
.. admonition:: Example
sudo docker exec bitcoind bitcoin-cli getnetworkinfo
A list of possible commands can be found `here <https://chainquery.com/bitcoin-cli>`_.
You can also drop into a shell using::
sudo docker exec -it bitcoind bash
and then enter ``bitcoin-cli`` commands. When you are finished, simply type ``exit``.

61
source/0ld-docs/support/FAQ/030-faq.rst Normal file
View File

@@ -0,0 +1,61 @@
.. _030_faq:
***********************
EmbassyOS Version 0.3.0
***********************
WHEN will the new version be released?
--------------------------------------
We are as eager to share this major OS overhaul with you as you are to use it. At this time we are in the testing phase. We will update with an ETA as soon as we can.
I have an Embassy already, what do I need to do?
------------------------------------------------
You have 2 options:
1 - Do nothing. Your Embassy will continue to work as it has, however there will likely be no further updates to the 0.2.x series.
2 - Upgrade by adding the `required hardware <https://start9.com/eos-0.3.0>`_ and then install the new version. v0.3.0 will be a free software upgrade to all existing users.
I want to buy an Embassy, what do I need to do?
-----------------------------------------------
Currently we are selling the v0.2.x Embassy. These are shipped immediately and can be upgraded when v0.3.0 is available. We are also selling upgrade kits, which contain all the `required hardware <https://start9.com/eos-0.3.0>`_ for v0.3.0. These will be shipped when the update is complete and will contain a pre-flashed SD card with EmbassyOS v0.3.0. The software update is free.
I want to build an Embassy myself, what do I need to do?
--------------------------------------------------------
You'll simply need to gather the `required hardware <https://start9.com/eos-0.3.0>`_, then wait until the release of v0.3.0, at which time you can purchase the OS, or build from source yourself. New build documentation is forthcoming.
I would like to purchase my own hardware. What factors do I need to consider?
------------------------------------------------------------------------------
1 - Please check the :ref:`DIY guide<diy>` for the necessary Raspberry Pi hardware. ``*`` (Skip this step if you already have an Embassy) ``*``
2 - The most important piece of additional hardware is the external drive. It MUST have a USB 3.x connection (3.0, 3.1, etc are fine). You may use a HDD, an SSD, or an M.2 SSD / NVME. HDDs are cheaper, and the storage capacities can be much higher, however this is at a big performance sacrifice. SSDs are significantly faster (all services and user data will be stored on your external drive), and more generally more reliable than an HDD. This is what we strongly recommend and sell with our official upgrade kits. An M.2 SSD is simply an SSD with a smaller form factor. An NVME SSD is even more performant than an SSD, however that performance will not be accessible due to the USB bottleneck that the data must traverse to the Pi. Drives will range in price radically depending on what you choose.
If you are unsure what drive type is best for you, get an external SSD with a USB 3.0 connection, such as a Samsung T5. These are around $130USD for 1TB and around $240 for 2TB.
3 - For the SD card, any type will work, and 16GB is recommended. A larger card will not offer any benefit. These are $5-10USD. EmbassyOS will be stored on this card.
What size drive do I need?
--------------------------
This will depend on how you want to use your Embassy. We recommend a minimum of 1TB if you intend to run a pruned Bitcoin node, or no Bitcoin node at all, and a 2TB minimum if you intend to run a full archival node, which will add a lot more functionality.
If you intend to run your own "cloud", then consider the amount of data you are storing. If you have lots of video files, for example, you may start filling up the disk fairly quickly. Any service you are currently using should have a simple way for you to view your data usage. Make sure to leave plenty of room for expansion.
Finally, remember that you can always expand to a larger drive in the future. EOS will also be adding additional advanced storage features in the near future.
I want to add an HDD later, in addition to my SSD, what are the performance consequences of doing this?
-------------------------------------------------------------------------------------------------------
At this time, we recommend against this as the Raspberry Pi cannot deliver enough power. We will be revisiting in future, but a powered usb hub would be a minimum requirement for this setup.
Can I use an internal SSD with a USB 3 enclosure? I've heard these may have issues?
------------------------------------------------------------------------------------
Yes, you may, and our original upgrade kits come with this style of drive. We have addressed the known issues in software, and in the rare event of hardware failure, we are here to help.
Does my external drive need its own power supply?
-------------------------------------------------
You may use powered disk drives if you prefer, but if only connecting one SSD, it is not necessary.
Can I re-use the SD Card from my Embassy for the new version?
-------------------------------------------------------------
ONLY if you have no data that you want to transfer. If you have existing files, Lightning channels, etc, then you will need to migrate to the new drive first. Keep in mind that this SD card is major overkill for newer versions of EmbassyOS, which will only require a 16GB SD card. This is because all service and user data will be stored on external drives going forward. You can use the original 128GB card for other purposes, sell it, etc.
``*`` PLEASE FEEL FREE TO REACH OUT TO US WITH ANY QUESTIONS - THIS PROCESS WILL BE STRAIGHTFORWARD AND WE ARE HERE TO HELP :) ``*``

176
source/0ld-docs/support/FAQ/bitcoin-faq.rst Normal file
View File

@@ -0,0 +1,176 @@
.. _bitcoin_faq:
*****************************
Bitcoin and Lightning Network
*****************************
Why does the Bitcoin service take so long to be ready?
------------------------------------------------------
On first install, the Bitcoin service must verify the entire history of transactions in order to verify transactions going forward. This can take approximately a week depending on your internet connection. You can continue to use the Embassy normally in the meantime.
You can learn more about the Initial Block Download in `this video <https://www.youtube.com/watch?v=OrYDehC-8TU>`_.
Can the IBD (Initial Block Download) be made faster? Or can wait times be improved?
------------------------------------------------------------------------------------
We have improvements on the way in mid-2021 to vastly improve the painful sync times, without sacrificing trust minimization.
I'm getting this error: unable to connect to bitcoind: -28: Loading block index... What do I do?
------------------------------------------------------------------------------------------------
The block index error is normal and goes away after the Bitcoin blockchain has synced. If you have completed the Initial Blockchain Download (IBD), this will be a few minutes at most.
Does the Embassy run a full archival Bitcoin node?
--------------------------------------------------
The Embassy runs a full node, but does not run a full *archival* node, it's pruned. This means it does not store the entire Blockchain. As it syncs, it discards blocks and transactions it does not need.
It is fully validating and verifying consensus all the way from Genesis. Really, the only reason to store the entire Blockchain is if you want to run a block explorer. Learn more here: :ref:`node`. All this being said, it will be possible to run a full archival node on the Embassy in mid-2021, bringing this additional functionality to those that would like it.
What actions, specifically, are only possible with an archival, or ‘unpruned’ node?
-----------------------------------------------------------------------------------
The more sophisticated the blockchain analysis being done is, the more index data is required, which will increase the system resources required. For example, if you wanted to run a block explorer, you would require not only a full archival node, but also a full transaction index. So, specifically, at this time, a full archival node is required for running an Electrum server, a block explorer, and for doing advanced chain analysis in general.
Is it insecure to run a pruned node?
------------------------------------
As a user, pruned nodes and archival nodes provide you the same security. In a larger sense, if 100% of people ran pruned nodes, the security of the network could be in dire circumstances and be put at risk if no nodes kept history, as then no one could bootstrap new nodes. The reality however, is that most Embassy owners are new node operators, so there is no net systemic risk introduced.
The Bitcoin Service is different from the GUI version I am used to using (bitcoin-qt). How do I use this like I used to?
-------------------------------------------------------------------------------------------------------------------------
At present, the Embassy does not offer its own node visualization tool. You can view certain properties about your node inside the "Properties" section, but not in an animated GUI. If you want to use bitcoin-cli, you may do so by adding an SSH key onto your Embassy and exec-ing into the bitcoind docker container. Otherwise, the main way to actually *use* your node is through a wallet. The QT GUI is not usable because it cannot be served through the browser (which is necessary here), and last we checked, the QT desktop client was incapable of connecting to a remote node over Tor. As far as we are aware, the only wallets that support this are Specter, Fully Noded, and Sparrow.
Is a wallet vulnerable to hacking if it’s always online??
---------------------------------------------------------
Funds are not stored on the node typically. The node simply serves as a source of truth for the state of the blockchain. Attacks depend on where the keys are and where the signing happens. You can use something like a hardware wallet for better security. Though, to be fair, a lot of attacks depend on you or your machine being targeted specifically, and a whole bunch of attack vectors are highly theoretical and obscure.
Most successful attacks seem to be either fake/doctored software or a social attack (tricking you into installing some malware or giving your seed outright or something like that).
Keep in mind, however, the more value there is out there to steal, the more sophisticated attacks will get automated (bots, crawlers etc). So its not just the risk profile of today, but also tomorrow you have to consider. That’s why something like a hardware wallet or dedicated mobile device for key signing is a good idea.
Even if your wallet is plugged into your Embassy, whether your wallet is hot or cold depends on the hardware that stores the keys.
How does Bitcoin Proxy request (and verify) data when that data is needed by some app using it?
-----------------------------------------------------------------------------------------------
Proxy fetches blocks from your pruned node if it still has them, and fetches them from peers when it does not. Proxy can ensures the fetched block is valid by comparing it to its header, which is retained by the pruned node. The header is a product of the hash of the block itself, amongst other things, so it can't be tampered with.
What is the difference between the Bitcoin Wallet Tracker and the Electrum Personal Server?
-------------------------------------------------------------------------------------------
Bitcoin Wallet Tracker and Electrum Personal Server are 2 services that do the same thing, similar to bitcoind vs btcd, or lnd vs c-lightning.
Both work with your Bitcoin node to provide a richer set of information to wallets than could be done with bitcoind alone. They are basically identical in purpose, their differences are notably in the software memory requirements and how snappily they can answer the same questions.
Electrum (and some other wallets) require more than just a Bitcoin node to run in a sovereign way, they require an “Electrum Server”. Both Electrum Personal Server and Bitcoin Wallet Tracker are “Electrum servers”.
How do I use Bitcoin Core as a wallet?
--------------------------------------
Bitcoin Core is a full node that also contains wallet functionality. Some will be familiar with Bitcoin-QT, which is a Bitcoin Core GUI that for a long time was the only available wallet. This is currently not compatible with the Embassy.
You can use the wallet in Bitcoin Core, however it is for advanced users and is only available in the command line via SSH.
It is helpful to think of the Bitcoin Core service on the Embassy as your own personal Bitcoin Server. This is your own verified source of truth of the Bitcoin ledger, that requires no permission for you to set up and own. The job of your Bitcoin server is to verify that the transactions you want to make and receive are valid.
There are modern wallets that have the ability to use your personal Bitcoin node as a source of truth, and with the advantages of additional security and advanced features. This also follows the Linux mantra of "do one thing and do it well." The recommended way to use Bitcoin with your Embassy’s Bitcoin node is with an external wallet.
The available wallets are listed in the following FAQ.
Which wallets can I use that sync with my Embassy Bitcoin node?
---------------------------------------------------------------
The only currently available external options are FullyNoded and Specter. Within the Embassy, BTCPayServer is available, which offers a wallet that is automatically connected to your Embassy's Bitcoin Core node. Keep in mind that this first and foremost a payment gateway, rather than a personal wallet. Unforutnately, this is still not a popular functionality in Bitcoin wallets. We are in communication with several wallet developers about adding Tor full node support.
What Lightning wallets can I use that sync with my Embassy?
-----------------------------------------------------------
Spark, Zap, and Zeus.
Is BlueWallet an option?
------------------------
BlueWallet requires a separate backend service called LNDHub, which is not available on the Embassy at this time.
Is there a guide for connecting Specter Wallet to my Embassy?
-------------------------------------------------------------
There is. Please follow the integration guide `here <https://github.com/Start9Labs/bitcoind-wrapper/tree/master/docs/integrations/specter>`_ and select the tutorial based on your operating system.
More guides, particularly in video form, are forthcoming.
I want to use my hardware signer, such as Coldcard or Trezor, with my Embassy. How does this work?
---------------------------------------------------------------------------------------------------
You do not use hardware signers directly with your node. Hardware signers interface with wallets, and wallets interface with nodes.
Node (Embassy) <— Wallet (Specter, Sparrow, Electrum) <— Hardware signer (Coldcard, Trezor)
You would use your hardware signer with your wallet, then instruct that wallet to use Embassy as its node.
- Nodes are for interacting with the Bitcoin network: enforcing consensus rules, validating and relaying blocks/transactions, and broadcasting transactions.
- Wallets are for constructing and viewing transactions, as well as generating addresses.
- Signers are for generating and storing keys, as well as signing transactions.
The reason there is so much confusion about these 3 concepts is that the Bitcoin Core Node comes with its own Wallet (which you should not use), and that wallet is also a signer. In fact, most wallets double as signers, and most wallets do NOT support connecting to your own node. So, most wallets are actually serving as a wallet, a node, and a signer, which might be convenient, but it is neither trustless nor maximally secure. Ideally, you are using a wallet that supports both integrating with a hardware signer (like Coldcard or Trezor) AND a backend node (like on the Embassy).
Please note: of the wallets listed (Specter/Sparrow/Electrum), only Specter is currently able to use Embassy as it's node, but the other two should be available soon.
Why would I want to run a lightning node?
-----------------------------------------
The Lightning Network (LN) is a second 'layer,' built on top of the Bitcoin Protocol. As a result all transactions on LN are backed up by the full security of the Bitcoin network. Lightning is designed for instant payments between nodes, but similar to running a Bitcoin node, running your own is the only way to be sovereign. When you have your own node, you will have the convenience of linking a Lightning wallet, for use on the go. It is also possible to earn an income (granted a very small one at this time), if you are willing to learn how to become a 'routing node.'
How can I get started with Lightning and open my first channel?
---------------------------------------------------------------
You can check out our `"Using Lightning" video <https://www.youtube.com/watch?v=rAvoUNsobws>`_ and learn the basics, including opening a channel with Start9.
.. youtube:: KhU_sTiaN8w
Please remember to always open a "Private" channel with us, or your channel is likely to be closed. Please don't hesitate to reach out to us with any questions.
I opened a Lightning channel, but my local balance is lower than I expected. Where is the remainder?
-----------------------------------------------------------------------------------------------------
A fee to close the channel (onchain) is set aside at opening.
How is that fee estimation calculated?
--------------------------------------
The commitment fees are automatically negotiated every few blocks with your peer. They are on chain txs like all channel closes but they are not broadcast until you attempt to close the channel.
What would happen if I shut down an Embassy that is running a Lightning node with open channels?
------------------------------------------------------------------------------------------------
It is REALLY IMPORTANT to understand that if Lightning services are shut off for long periods of time (days on end) it is possible for your peers to cheat you out of money. If you are not prepared to LOSE ALL THE MONEY IN YOUR CHANNELS, KEEP YOUR NODE RUNNING.
That said, malicious actors on the network right now are probably sparse. However, you are still open to that risk if you do not keep your node online.
Is there a solution to this?
----------------------------
Yes, the concept of a Watchtower was originally conceptualized in the LN whitepaper. A Watchtower is simply a lightning node to which you can give the authority to monitor transactions associated with your open payment channels.
Is it possible to run c-lightning and lnd parallel on the Embassy?
------------------------------------------------------------------
Yes, you may run both. They will operate in their own environments and allow you to run services that depend on either.
How do I connect my Spark mobile app to the Embassy Spark server?
-----------------------------------------------------------------
To use a Spark client, you still need to have Spark installed on the Embassy (which ‘serves’ Spark). Then, under Properties, there is a "Pairing URL". The first part of this is the server URL, and the end portion of it is the access key.
Unfortunately, Spark cannot currently be used in Consulate. This issue is being tracked `here <https://github.com/Start9Labs/consulate-ios/issues/30>`__.
Are my addresses, channels, and balances all stored in LND or in RTL?
---------------------------------------------------------------------
This is all on LND, and RTL is just a GUI for accessing LND. On-chain balance is also part of the LND backup.
How do I find my LND seed so I can write it down to backup?
-----------------------------------------------------------
All LND backups are best done via the Embassy backup flow. It is not supported to use a seed as backup; LND does not expose this. Everything crucial is backed up by our backup system so you do not need your seed. The seed is ONLY for the onchain wallet and does not backup your channel state.
To clarify some of the reasons for this choice:
First off, Lightning is fundamentally different than on-chain/Layer1(L1) bitcoin. There is no way to compress all of that information down into a single 24 word seed in such a way that it will continue to work throughout your usage of the Lightning Network.
So, what is the LND seed *for*? In short, the seed is only used for the Layer1 portion of the funds you have locked up in LND. Due to the live nature of LND and lightning nodes in general, we tend to discourage keeping any significant amounts of money in the onchain portion of your wallet. Given that we cannot actually recover the Layer2(L2) funds with that seed, we needed to have a more holistic way to backup LND funds such that the backup would encompass the ability to get L2 funds back. The Embassy backup system does this, and this approach also happens to be a perfectly valid backup of your L1 funds as well. While Bitcoin users have been trained that the 24 word seed can be used to recover all of their funds, it is important to state that lightning does not and cannot work this way. Exposing the seed gives you two separate things to keep track of in order to recover your funds instead of just one.
Is there a way to use the channel backups made within RTL?
----------------------------------------------------------
The only backup flow we officially support is through the Embassy backup system. This does include the channel backups created automatically by LND, but it must be understood that backups in Lightning are very different than they are on Layer 1 Bitcoin. If you restore from backup all your channels will close, and there is a potential, albeit small, probability for you to lose funds.
When attempting to add new peer, RTL says "server is still in the process of starting," but chain state seems to be fully up to date. What can I do?
-----------------------------------------------------------------------------------------------------------------------------------------------------
Check the LND logs, it can take a while to bootstrap, and starting RTL before this completes could cause errors.
"Server is still in the process of starting," but LND and RTL are running. How can I address this?
---------------------------------------------------------------------------------------------------
You may need to restart the LND Service.
I get the following error from LND: "Error ECONNREFUSED Fetching Info Failed! Unknown Error." What's wrong?
-----------------------------------------------------------------------------------------------------------
LND is waiting for Bitcoin to completely sync, and then needs to catch up on block scanning itself. This may take several minutes, and in some cases might require a restart of the LND service. Do this if the process takes more than 5-10 minutes.
What's the best way to move a small lightning balance?
------------------------------------------------------
It is possible to have lightning balances that are so low that they will not (or barely will) cover the on-chain fees to recoup into an on-chain wallet.
Why are Lightning Network backups and moves so complicated?
-----------------------------------------------------------
There are safe ways to do an “atomic move” of a LN node, but it requires a very specific sequence of actions and certain mistakes can result in your counterparties taking all your funds. Currently, LN works on a punishment scheme. This means if you publish revoked state, the counterparty is entitled to a claim on all the funds in the channel. This incentive system is what makes the whole system work. Without it LN would be subject to various kinds of thievery.
The downside is that backups of old state are not safe. This is because your node might believe it is the real state of the channel, but it may be unaware of states created since then. The problem here is that your node naively believes something different from the truth, which can result in all of the funds being lost. In response to this reality, the safe backup systems, including those generated by RTL, actually do not include channel state. They only list the peers that you had channels with. Restoring these backups essentially politely asks your peers to force close the channels they have with you. In those moments it is possible for your peer to try and cheat you, but they cannot be 100% sure that you can’t punish them, so it’s extremely unlikely that they will attempt to do so.

31
source/0ld-docs/support/FAQ/dev-faq.rst Normal file
View File

@@ -0,0 +1,31 @@
.. _dev_faq:
**************************
Contributing & Development
**************************
What versions does this FAQ concern?
------------------------------------
This FAQ concerns only EmbassyOS version 0.3.0 and above. For v0.2.x documentation, please see our :ref:`Service Packaging Guide <service_package_overview>`.
What language does the application I want to package need to be written in?
---------------------------------------------------------------------------
The application can be written in any language, so you may prefer to select an application in a language you are comfortable with (or write your own application). It is only important that the packaging specifications be followed.
What considerations go into selecting an application to package?
----------------------------------------------------------------
With sufficient effort, most any software with the ability to be self-hosted could make its way onto EmbassyOS. That being said, the following features will make service packaging much easier:
- Already built with self-hosting in mind
- Active development / community
- Native proxy/tor support
- Already 'dockerized'
Which possible formats can I use to write the :code:`manifest`, :code:`config_spec`, and :code:`config_rules` files?
--------------------------------------------------------------------------------------------------------------------
JSON, TOML, or YAML are valid options.
I'm getting errors on the `embassy-sdk pack` step. What's going on?
--------------------------------------------------------------------
There is something either missing or incorrect in regard to one of the :code:`manifest`, :code:`configs`, :code:`instructions`, or :code:`icon` files.

70
source/0ld-docs/support/FAQ/embassy-faq.rst Normal file
View File

@@ -0,0 +1,70 @@
.. _embassy_faq:
*****************************
Embassy (Device, OS, and DIY)
*****************************
Can I run EmbassyOS on a VPS or VM?
-----------------------------------
Maybe, but we advise against this. It is designed to be used on a RaspberryPi.
Is it possible to use the EmbassyOS on my own hardware?
-------------------------------------------------------
Yes! The :ref:`diy guide <diy>` will take you through the setup steps. This option is great for people who already own the necessary hardware or who live outside the US and want to save on shipping and customs fees.
Additionally, EmbassyOS is available to build from source under the Start9 Personal Use License. If you have the time and energy, it is possible to download and compile EmbassyOS yourself, for free, with the caveat that your “Embassy” will not have a product key generated by us. This means you will miss out on the perks that come along with purchasing from us, which will grow over time.
Do I plug the Embassy into my computer?
---------------------------------------
No. The Embassy only needs to be plugged into power and internet, just like your router. You can set it up right by your router and forget about it.
How much storage does the Embassy have?
---------------------------------------
Currently, the Embassy ships with a 128gb of storage.
Are my Internet requests anonymous and secure?
----------------------------------------------
EmbassyOS and every service on the Embassy serve their own Tor Hidden Services with unique Tor addresses. The private keys used to create these addresses are generated on your phone or computer when you first set up the Embassy. No one, not even Start9, has any idea what your Tor addresses are, let alone the password(s) you choose to authenticate with them.
Does Start9 have access to my Embassy's encryption keys?
--------------------------------------------------------
No. Your keys are generated on your device using the password you create.
Can multiple Embassies be setup to run redundantly in physically separate locations?
------------------------------------------------------------------------------------
Soon (tm). Currently no, be we have plans for a feature that will enable Embassies to provide encrypted, automated backup services for one another.
How does the Embassy compare to other Bitcoin nodes or personal servers?
------------------------------------------------------------------------
The cheapest way to run a Bitcoin/Lightning node is to buy a Raspberry Pi (or equivalent), compile the software from source yourself, and host everything on Tor. This takes even technical people significant time to accomplish. On the other end of the spectrum is something like the Embassy, which "just works". In between is stuff like MyNode, Nodl, Dojo, Umbrel, and Raspiblitz, which all require some degree of command line effort and network configuration. The biggest benefit of the Embassy is that it is infinitely extensible to all of open-source, self-hosted software. The service listing will expand enormously over time in ways the other platforms cannot.
Would you consider (Umbrel, Nodl, Dojo, etc) a competitor to you guys, or are they different enough to be compatible?
---------------------------------------------------------------------------------------------------------------------
Other node devices are competitors, and there are distinct trade-offs to each platform, but we are definitely moving toward the same future, which is a win for everyone!
We are taking more a general approach to all of open-source, self-hosted software, including Bitcoin/Lightning. They are more Bitcoin/Lightning oriented.
Is a more powerful device in the works??
----------------------------------------
In the near future, the Embassy will move to more powerful hardware.
I heard on an old podcast that there will be an Embassy Two, to be launched in 2021. Is there an ETA on this?
--------------------------------------------------------------------------------------------------------------
Do not expect a new device in 2021, but we are always doing R&D.
Can I mine Bitcoin with this?
-----------------------------
No, you can not.
Does the Embassy only work over Tor? No http or VPN...??
--------------------------------------------------------
The Embassy’s current primary communication is Tor, yes. In many cases we use HTTP over Tor (they are not mutually exclusive), you can see this by navigating to the Tor address in a browser and see the “http” in front of it. A VPN is a feature we’re exploring as an alternative to Tor to make things faster without meaningfully impacting privacy. You can also connect directly via LAN if you are on the same network as your device.
What if someone gets physical access to my device, can they read the contents? Is it encrypted?
-----------------------------------------------------------------------------------------------
The device is currently not currently protected in that way. Someone with physical access to the device can get full access to everything on it.
Apps like Bitwarden, however, do not store plaintext information, so your passwords will not be compromised unless they know your master password.
Why http and not https for .onion websites?
-------------------------------------------
When visiting a Tor V3 URL (.onion website), your communications are end-to-end encrypted and onion-routed by default. There is no added benefit to using https. See this `article <https://community.torproject.org/onion-services/advanced/https/>`_ from the Tor Project for more details.

115
source/0ld-docs/support/FAQ/general-faq.rst Normal file
View File

@@ -0,0 +1,115 @@
.. _general_faq:
*******
General
*******
What is Start9Labs?
-------------------
Start9Labs is a company based in Denver, CO that builds the Embassy and EmbassyOS.
What is the Embassy?
--------------------
The Embassy is a "shelf-top" computer built using a `Raspberry Pi <https://www.raspberrypi.org/products/raspberry-pi-4-model-b/>`_ for hardware and running EmbassyOS software.
The internet as we know it is organized into questioners, or clients, and answerers, or servers. When you open a mobile email app, say Gmail, the app (client) begins asking questions: "have I received new mail?", "what are my last 50 messages?", "what drafts am I in the midst of writing?", and so on. Your app's questions are sent to and heard by a Google-run server which then provides answers back to the client and are subsequently displayed to the screen.
The Embassy is exactly that: your very own "answerer", just like Google's, except managed simply and with ease by and for you alone.
In other words, it is a generalized private personal server capable of running all sorts of self hosted open source software.
When you see your credit card information on your banking app, your messages in your texting app, your passwords in your password management app, all of that information comes from somewhere in the cloud: some server run by some company somewhere on the planet. Who can see the data stored in that server? Who can edit it? It's not always clear, but the increasingly common practice of selling your data to advertisers and the high-profile cyber-security breaches of the last decade suggest a pessimistic outlook.
One thing is for certain though: if you control your server, then you control your data. Your finances, your communications, all of it is actually yours -- and only yours -- with an Embassy.
Why do I care?
--------------
As an example, let's talk about the password manager, Bitwarden. It may help convey the concept of a personal server. Currently, when you use Bitwarden, your passwords are stored on a physical device (aka server) owned and operated by the Bitwarden team. Your phone or laptop sends requests to their server when you want to do anything: create an account, create a new password, retrieve existing passwords, etc. Your passwords are stored on their device, encrypted with your Bitwarden password. They are the custodian of your passwords, similar to getting a safe deposit box at the bank. The bank keeps your valuables in their vault, presumably they don't know what's in the box, and any time you want access to your box, you ask the bank for permission. This is exactly how a hosted Bitwarden experience works, as well as just about everything on the internet. When you install Bitwarden on your Embassy, by contrast, it's like building your own safe deposit box in a private bunker whose location is only known to you and whose keys only you posses. You create an account with yourself, store your passwords with yourself, etc. You are your own custodian. This same concept can be applied to just about everything on the Internet, without losing the convenience of the custodial model, which is what we are out to accomplish. This may sound cool, or neat, but it is so much more than that. The custodial data model is amongst the greatest threats to human liberty the world has ever seen.
This `podcast <https://www.youtube.com/watch?v=aylDowaSdzU&t=270s>`_ may help expound upon why this is important.
How does the Embassy work?
--------------------------
The Embassy runs on the Raspberry Pi 4B hardware with a Cortex-a72 CPU, 4GB of RAM, and has 2.4ghz and 5.0ghz IEEE 802.11AC wireless capabilities and an internal speaker for audio feedback of system operations. It also features a high endurance MicroSD card, on which the operating system software is installed.
EmbassyOS is a stripped down version of Raspbian Buster Lite and handles all operations of your Embassy device. This core element of the technology stack is what enables you to set up, login, access your Embassy’s dashboard, and download and install services.
One of these operations is creating and managing Tor addresses, which are uniquely attributed to each service you download, as well as to the Embassy device itself. You can see your uniquely generated Tor address when you complete the setup process using the Setup App. This address is how you view your Embassy’s dashboard, which is actually just a website served up from your Embassy itself! It is authenticated, of course, so only you can access it.
You can connect to and manage your Embassy from any mobile device, desktop computer, or laptop computer. This is accomplished right through the browser by visiting your Embassy's private and unique URL.
Once on Embassy's web page, you can choose what services to install to the Embassy. Then, each installed service also receives its own private and unique URL, such that you can access it from the browser or any mobile app that supports using it as a backend.
The list of services will grow rapidly over the coming months, such that many things you currently do using cloud-based third party servers can be just as easily accomplished using your own personal cloud serving your own personal apps and storing your own private data. No trusted third parties at all.
What is EmbassyOS?
------------------
EmbassyOS is a new kind of Operating System (OS). It is built from the ground up to allow anyone to easily run their own ‘cloud,’ become independent from Big Tech, and own their own data. EmbassyOS allows anyone to easily self-host their own software services.
EmbassyOS is a custom-built Linux distribution, which is a stripped down and beefed up version of `Raspbian Buster Lite OS <https://www.raspberrypi.org/software/operating-systems/>`_, along with a suite of software tools which make it easy to:
* Install, uninstall, and upgrade services from the custom Marketplace (similar to your phone's app store)
* Manage and run services that YOU control
* Upgrade your Embassy software with the latest features and security updates
* Backup services, and restore from backups if needed
Start9 augmented the original Raspbian OS to include:
* a custom application management layer, specialized for installing, running, and backing up .s9pk packaged services
* a layer responsible for Embassy specific operations, such as Tor, Backups, and Notifications
The .s9pk extension is Start9's custom package format based on tar. It encompasses the necessary components to compress, host, and install a service on the marketplace.
What are EmbassyOS Services?
----------------------------
A Service can be any piece of software added to the Marketplace. All services are "self-hosted," meaning that you are in complete control of your data. This means you can run your own "cloud!" Learn more about managing services :ref:`here <managing-services>` and see our currently :ref:`Available Services <available-services>`.
Does the Embassy ship worldwide?
--------------------------------
No. We ship everywhere that DHL ships, with the unfortunate exception of Europe, where the VAT and Customs are so ridiculous that they cost as much as Embassy itself or more. Please consider buying your hardware locally, and purchasing EmbassyOS as a download from us instead.
Does the Embassy have international electrical plugs?
-----------------------------------------------------
Power supplies for EU, AU, US, and UK are available.
Is the power supply that comes with Embassy 220v compatible?
------------------------------------------------------------
Yes.
Is the software Open Source?
----------------------------
Yes! EmbassyOS is open sourced under the `Start9 Personal Use License <https://start9.com/license>`_. Some of our other projects are currently open sourced under MIT. You can find these in the Start9 `GitHub repository <https://github.com/Start9Labs>`_.
Is there a product warranty?
----------------------------
Yes! Start9 commits, to the best of our ability, to serving each beta Embassy product released into the wild. We will resolve any issue encountered with our provided hardware or software in a personalized matter. We strive to provide highly available, quality customer service.
Can you tell me about the License?
----------------------------------
EmbassyOS is published under our own Start9 Non-Commercial License, which has similar properties to many open source licenses with the exception that users cannot in any way, either through products or services, commercialize the source code, and any changes to the code or derivative works of the code are treated in the same manner. This means people will be welcome to access the source code, download it, use it, run it, fork it, change it, improve it - whatever they want - except sell it or sell services related to it.
What kind of Internet connection is required to use Embassy?
------------------------------------------------------------
In general, any modern Internet connection is usually fine. We have had reports from users on rural satellite connections with high latency (ping), and low up/download speeds who had issues accessing via Tor. You can check your internet connection at `SpeedTest <https://speedtest.net>`_ to find your ping and speed. If your ping is higher than 200ms and/or your speeds are lower than 5Mbps, you may want to host your Embassy somewhere with a better connection. Please don't hesitate to contact us with any questions.
I run a business, can I use an Embassy for tasks such as password management and file sharing?
----------------------------------------------------------------------------------------------
Absolutely. An Embassy would be a great addition to any business as it is easy to use and provides services that you control, with no subscription fees.
With the addition of `BTCPay Server <https://btcpayserver.org/>`_, you can even run your own payment processor and accept cryptocurrency payments with no third party necessary!
What are you using for a store backend? Do you store my data?
--------------------------------------------------------------
Here is our exact situation currently:
Embassy device sales are processed through Shopify, which we do not like, but it was expedient in the early days, especially for shipping, so we went with it. Aside from a master list of email addresses for those who have explicitly opted in to our mailing list, all customer data is contained within Shopify. We do not duplicate it anywhere. We are asking Shopify to delete our customer data, but they claim it will take upward of 3 months to comply and we of course have no guarantee the data will actually be deleted permanently. This is partly why we exist...as such, we will be moving off of Shopify and onto a self-hosted solution, where Start9 alone controls our customer data for Embassy purchases, which we will delete as a matter of policy following a short grace period after delivery.
For EmbassyOS sales, we took the maximally private approach right out of the gate. When you buy EmbassyOS, the only thing we need is an email address, and you can only pay with bitcoin. That's it. Then, unless you have explicitly requested that we keep your email for mailing list purposes, we delete the email immediately upon transaction completion.
So...in summary: (1) the shipping data we currently have is stored in Shopify (2) we are asking Shopify to delete all our customer data (3) we will be migrating off of Shopify (4) going forward, we alone will control customer data and will purge it regularly (5) you can always assemble the hardware yourself and just buy EmbassyOS from us with bitcoin, which only requires an email, which is gets purged immediately.
I want to help, but I'm not a developer. Are there any ways for non-coders to contribute?
------------------------------------------------------------------------------------------
1. Shill it to everyone and create awareness
2. Answer questions from new users in the community channels
3. Make tutorial videos
4. Write instruction manuals or commit to the docs

17
source/0ld-docs/support/FAQ/index.rst Normal file
View File

@@ -0,0 +1,17 @@
**************************
Frequently Asked Questions
**************************
A collection of common questions and concerns from our community.
.. toctree::
:maxdepth: 2
general-faq
embassy-faq
usage-faq
setup-faq
services-faq
bitcoin-faq
030-faq
dev-faq

101
source/0ld-docs/support/FAQ/services-faq.rst Normal file
View File

@@ -0,0 +1,101 @@
.. _services_faq:
********
Services
********
My Embassy is set up, now what?
-------------------------------
You can now access your Embassy and find the Services you want from the "Marketplace" tab, then clicking "Install." The Service will let you know if you need any "dependencies," or pre-requisite Services, first. After you have a Service installed, don't forget to "Start" the service.
What if I cannot connect to a Service?
--------------------------------------
Please make sure the service is started by viewing it in the Services tab in the Embassy dashboard menu. A green indicator bar should be visible.
Can it be used as a firewall?
-----------------------------
Potentially. The PiHole service is on the roadmap.
Will there be a VPN?
--------------------
We are looking into adding as a Wireguard service for VPN access when you are not home. A client-to-client VPN may also be possible.
Will there be an email server?
------------------------------
We do hope to add this functionality one day, however it has some technical challenges, and is not currently a high priority. If you would like to tackle this and help us get a self-hosted email server on the Embassy, please reach out in our `Matrix Community Dev Channel <https://matrix.to/#/#community-dev:matrix.start9labs.com>`_, and we will be happy to help in any way that we can.
Can the Embassy run 'X' Service??
---------------------------------
Potentially. Here is a `comprehensive list <https://github.com/awesome-selfhosted/awesome-selfhosted>`_ of self-hosted services, any of which can theoretically be run on the Embassy.
To get a general idea of what is required of an app, answer these questions:
1. Is it designed to be self-hosted?
2. Can it run on a Raspberry Pi?
3. If it has a P2P interface, does that interface support Tor?
4. Does it ship with it's own web interface? Or is there a Tor-enabled client app?
5. Is there someone willing to put in the time to package it up?
If all answers are yes, then it can run on EmbassyOS.
Packing up a service for the Embassy does not require extensive development skills. If you are interested in doing do, please see our service packaging guide :ref:`here <service_package_overview>`.
We are aggressively moving away from service development in favor of a more community driven approach. Meaning you, an app development team, or anyone else on Earth, can bring the Service they want to the Embassy Marketplace. You don't need our permission.
Does the Embassy operate as a Tor relay node?
---------------------------------------------
No, currently it is not, but we plan to add that functionality in the future.
Are files on File browser encrypted on disk?
--------------------------------------------
No, not currently.
Can I use my CUPS instance with other people? How does that work?
-----------------------------------------------------------------
Cups does not have multiple accounts support. Each person would need their own Embassy. We are considering adding multi-account support to Cups, but it's just not a priority at the moment.
How can I fix issues with Sphinx?
---------------------------------
If you are on Android, make sure Orbot is setup correctly, and if it is, try to restart it or your device. If you still have issues, *back up your keys,* delete all app data from your phone, uninstall, restart the Sphinx service on your Embassy, then reinstall and import your keys.
I get an error ("Unlock Wallet Failed") when trying to log in to RTL, what can I do?
------------------------------------------------------------------------------------
Stop and Restart the Service.
What is happening if I cannot connect with another user on Mastodon?
--------------------------------------------------------------------
You can only follow someone who has an account on a Mastodon server that supports Tor. It is a new feature, so many instances do not have it yet.
Other issues are typically related to the tor connection, check your tor daemon, orbot, or try to restart the service.
Can the browser extension be used with Bitwarden hosted on the embassy?
-----------------------------------------------------------------------
Yes, but only in a tor-enabled browser. Just add your .onion address as the server in the extension. Make sure that http:// is at the beginning, and NOT https://, as this will not work.
I want to use BTCPayServer on my website, but Tor is the only option, how can visitors access my BTCPay on clearnet?
--------------------------------------------------------------------------------------------------------------------
As the Embassy produces a Tor Hidden Service for each service, BTCPayServer is only available via Tor by default. For a brick and mortar business, this is no problem as you can use your own device for a customer to pay you on. If you run your own website, it is possible to set up a reverse proxy in order to serve BTCPay content to your clearnet visitors. A guide to doing this is available in the `BTCPayServer docs <https://docs.btcpayserver.org/ReverseProxyToTor/>`_.
We understand that this can be a frustrating limitation, and adding clearnet support is high on our list of priorities for the Embassy. This will allow a number of services to have better interoperability with the broader Web.
I'm having issues connecting to users or rooms in Matrix/Synapse, what can I do?
--------------------------------------------------------------------------------
Most issues in Matrix will be due to improper setup, or tor connectivity issues. Please follow the directions in the Synapse web interface closely, and be sure that you have a good tor connection on the device you are trying to connect with. As with all Tor addresses, make sure you are using http:// as a prefix (some apps will automatically prefix https://.
Please reach out to us if you are still unable to connect.
My Element desktop client stopped working after an OS update, what is happening?
--------------------------------------------------------------------------------
If you had to create a custom destkop shortcut, it is likely that this was reset with the system update, so you'll just need to remake it.
I don't see an answer to my question regarding a certain service. Is there more documentation?
-----------------------------------------------------------------------------------------------
While we are intent on providing the most friendly experience possible to our customers, ultimately it will be impossible for Start9 to create documentation and tutorials for every service we make available on the Embassy. Each service *should* have its own documentation produced by the service developers themselves, and we will do our best keep track, consolidate, and link to it. Also, much of the reason good tutorials don't exist is simply because no one in the community has taken the time to produce it. If you come across something useful or write something up yourself, please let us know and we will promote it. Otherwise we will do our best to answer questions as they arise and gradually build out tutorials where they are lacking.
I want to understand in depth how a Service works and it's available configuration options. Where can I go to learn more?
--------------------------------------------------------------------------------------------------------------------------
Depending on the app, the config options can be quite involved. Bitcoin Core, for example, has an enormous amount of complex options, almost none of which are useful to a normal user doing normal things. We chose some very sane defaults that should work for normal use cases. Here is an example config from the Bitcoin `GitHub <https://github.com/bitcoin/bitcoin/blob/master/share/examples/bitcoin.conf>`_.
By reading the descriptions in the link above, as well as doing some extra searching on your favorite search engine, you can begin to discover all the crazy ways in which someone can customize their Bitcoin node. Here is another list of `possible options <https://en.bitcoinwiki.org/wiki/Running_Bitcoind>`_.
We translated much of (but not all of) the tons of options into a clean and easy-to-use GUI with toggles, dropdowns, inputs, etc, which is what you're seeing in your config screen. If you notice the little "?" icons on the left of each option, clicking them will provide a brief description as to what the option does. Also, our config GUI restricts the possible values you can enter such that you don't accidentally crash Bitcoin. That said, be very careful about just randomly changing things, lest your node starts to behave strangely.
You can also check out our :ref:`Service Config Spec <service_config>` documentation for further details.

65
source/0ld-docs/support/FAQ/setup-faq.rst Normal file
View File

@@ -0,0 +1,65 @@
.. _setup_faq:
*************************
Setup and Troubleshooting
*************************
What do I do first?
-------------------
Simply plug the device into power and internet, most easily by using an empty ethernet port on your home internet router. That's it! After this, get the :ref:`Setup App <initial-setup>`, and follow the instructions.
How do I know if my Embassy is running?
---------------------------------------
After plugging into power and your router, you will hear 2 distinct sounds: first, a “bep” ‐ indicating the device is powering on, and second, a “chime” ‐ indicating the device is ready for setup.
My Embassy is really hot! Is this normal?
------------------------------------------
Yes, the Embassy's case is actually doing 'double duty' as a heat sync. This means that the metal of the case is actually touching the chips on the circuit board and drawing their heat out and away. This is known as "passive cooling," as no fan (and therefore no additional energy) is required to cool the system.
What if I can't connect to my Embassy?
--------------------------------------
Please ensure your phone / computer is connected to the same wired or wireless network as your Embassy. Be careful that you are not on a separate or "guest" network.
Why do I need the Bonjour service (Windows)?
--------------------------------------------
Because a major use case of Bonjour is wireless printing over the LAN, but your Windows machine can also use Bonjour to discover and connect with other devices on the LAN. In this case the Embassy.
My Tor sites aren't loading, what should I do?
----------------------------------------------
This is most likely a transient networking issue that will correct itself in a few minutes to an hour. If it does not, there are few things you can try:
1. On Android/Orbot, the most common solution is to restart your Android device.
2. Access your Embassy over :ref:`LAN <ssl-setup>` and restart it from the "Embassy" menu.
3. Restart your router.
Do I need to take any additional security precautions with my device, for example with my router/modem?
-------------------------------------------------------------------------------------------------------
Nothing special is required, however, it is best practice to use good passwords, i.e. for your WiFi and your Embassy. Here's a `comic <https://xkcd.com/936/>`_ explaining how to make strong passwords, simply.
What if I have an unique network issue, for example, with a firewall?
---------------------------------------------------------------------
The Embassy is designed to work as simply as possible, for as many as possible, while providing the ability to self-host in a private manner. If you have an agressive or custom firewall, or other custom network settings, there is a good chance that addtional configuration may be necessary. We will continue to learn about custom networking issues, update our docs with resources, and help in the community :ref:`channels <contact>` to the best of our ability.
Can I use the Embassy from behind a VPN, for example, if my router has a built-in VPN?
--------------------------------------------------------------------------------------
While this is possible, it adds complexity, which may lead to problems. You will need to understand the setup of your router/VPN and how it supports (or doesn't support) tor connections.
If you are having trouble with this, you might consider letting the Embassy out "in the clear," since everything is broadcast exclusively across the Tor network, offering a high level of privacy.
Why am I having trouble using my Embassy via the Brave browser?
---------------------------------------------------------------
Unfortunately, Brave does not treat .onion addresses in a 'secure context.' This is a known issue in Brave that is being tracked `here <https://github.com/brave/brave-browser/issues/13834>`_.
I'm getting this error: The shell command "apt-get update" returned a failure exit code: 100. What do I do?
------------------------------------------------------------------------------------------------------------
This has been fixed in newer updates. Please first make sure to update to the latest EOS version (2.16 or higher). If this does not work, please :ref:`contact us <contact>`.
Is it true that iOS has some limited functionality in regard to the Embassy?
----------------------------------------------------------------------------
The short answer is yes, but not much. Unfortunately, Apple does not allow any ability for Tor to run in the background (everything on the Embassy runs over Tor). Most of your Embassy services can be run with Tor-native apps, inside Consulate, or with another Tor browser, with the exception of RTL, Spark, and Matrix. Zap and Zeus wallets can be used in place of RTL/Spark, and we hope a Tor-native Element client will be available soon to allow for the use of Matrix.
I'm having trouble using Firefox for Tor addresses on Lineage, what can I do?
-----------------------------------------------------------------------------
Unfortunately, there seems to be a bug in Lineage that makes using Firefox over Tor currently unusable. Currently, this feature works fine on Calyx and Graphene.

96
source/0ld-docs/support/FAQ/usage-faq.rst Normal file
View File

@@ -0,0 +1,96 @@
.. _usage_faq:
***********
Basic Usage
***********
Is it easy to use?
------------------
Yes! The Embassy is designed to be plugged into power and internet, and after a short setup, is immediately ready to use. Getting Services is as easy as getting apps for a smartphone.
As with anything new, you should expect to spend a little time learning the functions and features, and keep in mind that some Services may be more complex to understand and use than others.
So I can run my own cloud?
--------------------------
Yes! No special skills or knowledge are required to host all your own services and replace those previously thought "necessary" for modern digital life.
Can I run multiple Embassies?
-----------------------------
Yes, but there is currently no way to synchronize or federate them. We are working on ways to make this possible in the future.
What if I forget my Embassy password?
-------------------------------------
Check out the `docs <https://docs.start9.com/user-manual/general/forgot-password.html>`_ on forgot password, and let us know if you have any additional questions. All your services and data will remain.
Can I move my Embassy to another location? What happens when I do this?
------------------------------------------------------------------------
Yes, you can move the Embassy to another network. Your service tor addresses will remain the same.
What’s the advantage of using the .local address over the .onion address?
-------------------------------------------------------------------------
If you are in your home network it is both faster and more private since the connection never leaves your household. The downside is that it won’t work if you’re on the go.
Can I use the .local addresses over the Tor Browser?
----------------------------------------------------
Unfortunately, no. The Tor Browser requires all web visits to first enter the Tor network. Once you have entered the Tor network there is no way to exit the Tor network in such a way that .local/mDNS addresses resolve.
Can I not use .local addresses on Android? Why not?
----------------------------------------------------
Unfortunately, no. Google has not included support for .local addresses via mDNS for Android.
Is the software Open Source?
----------------------------
Yes! EmbassyOS is open sourced under the `Start9 Personal Use License <https://start9.com/license>`_. Some of our other projects are currently open sourced under MIT. You can find these in the Start9 `GitHub repository <https://github.com/Start9Labs>`_.
Is there a product warranty?
----------------------------
Yes! Start9 commits, to the best of our ability, to serving each beta Embassy product released until the wild. We will resolve any issue encountered with our provided hardware or software in a personalized matter. We strive to provide highly available, quality customer service.
Can you tell me about the License?
----------------------------------
EmbassyOS is published under our own Start9 Non-Commercial License, which has similar properties to many open source licenses with the exception that users cannot in any way, either through products or services, commercialize the source code, and any changes to the code or derivative works of the code are treated in the same manner. This means people will be welcome to access the source code, download it, use it, run it, fork it, change it, improve it - whatever they want - except sell it or sell services related to it.
I run a business, can I use an Embassy for tasks such as password management and file sharing?
----------------------------------------------------------------------------------------------
Absolutely. An Embassy would be a great addition to any business as it is easy to use and provides services that you control, with no subscription fees.
With the addition of `BTCPay Server <https://btcpayserver.org/>`_, you can even run your own payment processor and accept cryptocurrency payments with no third party necessary!
Can I have multiple users on my Embassy?
----------------------------------------
Currently, the Embassy itself is designed to for a single user. There is no way to grant others access to your Embassy without sharing your personal, master password, which is not recommended. There are certain services, however, such as Bitwarden, File Browser, and Mastodon, that absolutely support multiple users (aka multi-tenancy, aka uncle Jim model) where people who trust you can create their own, personal accounts for these services on your Embassy. Just remind them that they are trusting you with their data, and that it might be preferable for them to take the final leap of self-sovereignty and get an Embassy of their own.
What can I do if I am having issues connecting to an Android app?
-----------------------------------------------------------------
Unfortunately, Orbot can be finicky. The best solution to Android issues is normally to restart Orbot, or to reboot the phone. This will solve most common problems.
What can I do if I am having issues connecting with Consulate?
--------------------------------------------------------------
In the top right menu, select 'Clear Cache.' If this does not solve the problem, delete the bookmarked site entirely, then re-add it. This will solve most connection issues.
If I uninstall a service, then re-install it, does any data remain?
-------------------------------------------------------------------
No. When uninstalling a service, you completely destroy everything associated with it. This is because each service runs in it's own 'container', which includes all the required software and operating system environment that it needs to function. When uninstalling, this container is wiped from your Embassy's system, and with it, any associated service data that you have not backed up.
This can be useful, as you may want to wipe a service and start anew. For example, you might want to receive a fresh Tor .onion address, or to spin up a new Lightning node. However, if you do this, YOU MUST BE 100% CERTAIN THAT YOU ARE PREPARED TO LOSE ALL DATA for this service. Also, keep in mind that other services may depend on the service you are uninstalling.
Do I need to delete existing backups before doing a new backup? Or does a new backup override the old backup?
-------------------------------------------------------------------------------------------------------------
No, you don’t need to delete the old backups. The technology we use updates the existing backup.
Can I clone my Embassy SD card for backup purposes?
---------------------------------------------------
Warning: **DO NOT do this if you are running LND or c-lightning**. If you clone the SD card, then go back to running LND or c-lightning, and you *ever* try to restore the SD card, there is a good chance you will lose *all your channel funds*. Also, if you try to use the SD card for a 2nd Embassy, that will also result in loss of funds. This has nothing to do with Start9 or the Embassy; it is inherent to the architecture of Lightning.
If you are not running LND or c-lightning, then *yes*, it is possible to do a deep clone of the SD card as a backup. But even here, there are some considerations: Start9 does not test/support this officially, which means it is untested. Also, it may take a while to do a deep clone of the card since the ones we ship are 128GB and there isn't a really effective way to clone the Embassy card that isn't a byte-for-byte copy. However, if you do a byte for byte copy (128GB), and run `PiShrink <https://github.com/Drewsif/PiShrink>`_ you could flash that image file onto a new card and restore all of your data.
Why would I even buy this when I can just build it for free??
-------------------------------------------------------------
(1) White glove support. Because each Embassy comes with a unique product key engraved on it, and we have a record of all product keys ever, we can ask the user to verify their product key in order to receive a higher tier of support, such as phone calls.
(2) Supporting the project. Buying an Embassy from Start9 is your way of supporting the development of the project. And it's not just out of gratitude, but rather, a recognition that if the project isn't funded, the cool software stops coming.
(3) Convenience. This is the big one. It's true, some people will choose to use the software without buying an Embassy, but most will not. Very few people on Earth are comfortable using the command line, compiling code, and configuring an OS. Furthermore, hardware is necessary. Sure, some people already have a Raspberry Pi, and others may try to re-purpose an old laptop, but many people would be choosing between buying the Embassy hardware components themselves and assembling vs buying pre-assembled at a reasonable markup. And it's not just a pi, the Ambassador utilizes audio feedback, so a speaker is necessary too. Finally, due to the product key aspect, we can gate certain features of our hosted Service Marketplace. As in, if you buy an Embassy from us, certain services may be free, whereas they may be charged if you don't buy from us. Nothing stops a user from getting the service themselves from elsewhere, but again, convenience.
Bottom line...We are charging a very marginal rate for something incredibly powerful, and we think the convenience of a plug-and-play device, free service marketplace, and free white glove support is where the money is. Anyone could build their own couches too, but here is a reason furniture stores exist. How much is your time worth?
The fastest way to get support is via our `Telegram <https://t.me/start9_labs>`_ or `Matrix <https://matrix.to/#/!lMnRwPWnyQvOfAoEnD:matrix.start9labs.com>`_ channels. You can also `email us <support@start9labs.com>`_. Please do not hesitate to reach out!

124
source/0ld-docs/support/concepts.rst Normal file
View File

@@ -0,0 +1,124 @@
.. _concepts:
Concepts
********
Depending on your background, the Embassy platform may deal with some unfamiliar concepts. While it is not strictly *necessary* for you to understand these concepts to use your Embassy, we know many of you would like to.
.. _start9:
"The Origin of “Start9”
=======================
Pokemon is a game for Gameboy. Twitch is a live video streaming app. “Twitch Plays Pokemon” was a popular phenomenon where Twitch users would collaborate to play a SHARED game of Pokemon on Gameboy. Here’s how it worked:
Participants would use the Twitch message board to enter commands that then got executed in the gameplay. For example, if someone entered the command "right”, that would cause the player to move 1 space to the right. Commands would execute immediately after they were received, and anyone could enter a valid command at any time. You can think of Twitch Plays Pokemon as the more practical equivalent of placing a Gameboy in the middle of a crowded room and telling everyone to push buttons at the same time. As you might expect, the gameplay of Twitch Plays Pokemon was quite “twitchy”, but in a very "infinite monkey theory" way, progress could eventually be made.
In an effort to streamline play, a new game mode was devised in which players would “vote” for the next command and, every 4 seconds, whatever command received the most votes over the previous 4 seconds would execute in the game. Also introduced in this mode was the ability to attach multipliers to a command, such that the command would execute that number of times. For example, “right2” would cause the player to move 2 spaces to the right. “right3” would cause the player to move 3 spaces to the right, and so on. The highest number any participant could place after a command was 9, meaning whatever command they entered would execute 9 times. As you might expect, gameplay in this mode was less chaotic, more efficient, but it also meant each participant had less direct and immediate influence over the game. If a group of even 5-10 got together and colluded on their votes, they could practically take over the game and make contrarian ideas irrelevant. The new game mode was called “Democracy”, and the original game mode became known as “Anarchy”. Which game mode was engaged was itself governed by a democratic process: if more participants wanted to play in Democracy mode, then Democracy mode engaged; if more wanted to play in Anarchy mode, then Anarchy mode engaged.
To summarize: in Anarchy mode, everyone had equal influence over the game, but progress was slow and clunky. In Democracy mode, progress was fast and efficient, but colluding groups could marginalize individual participants and ruin the game for them.
So…individual participants discovered a means of effective protest whenever Democracy mode became suffocating, but they could not garner enough votes to switch back to Anarchy mode. Someone would type the command “start9” into the comments. This command meant “open the start menu 9 times in a row”, which, as you might imagine, would be enormously disruptive if executed. The entire screen would be blocked by the start menu, over and over. Typing “start9” was a participant’s way of signaling to other participants that they felt marginalized by Democracy mode, and they were ready to fight back. If others felt the same, they could also begin typing “start9” - then, sure enough, “start9” would finally receive more votes than the colluding group’s command, and the menu opening would begin. Every 4 seconds, the menu would open 9 times…again, and again, and again…until finally, the colluding group would be forced to either cooperate in reverting the game mode back to Anarchy mode or quit altogether.
Playing in Anarchy mode was impractical, but people did not want to play a game where they had no voice, where a group of insiders had taken total control. And so “start9” became the battle cry of the individual, the out-group, a means of signaling to other individuals that it was time to fight back against the usurpers - to use their own rules against them, until there was no alternative but to return control to the individual participants.
.. _open-source:
Open Source
===========
The Internet itself was built on free and publicly available code, with the values of collaboration, peer review, communication, and openness built into its very foundation. This decentralized model evolved into the open source movement, which uses these values to discover new ways to solve problems across boundaries and industries.
Open source software centered around the concept of user freedoms: freedom to see, modify, and redistribute the code to make it work for the user in whatever way they needed. It does not necessarily mean free to use. It means that the software will be better, cheaper, and more flexible if it is freely accessible, openly modifiable, and shared.
If anyone can inspect, modify, and distribute the code, bugs are more rapidly resolved, security vulnerabilities are more quickly audited and exposed. Community driven development efforts enable diverse collaboration which increases project reliability and longevity.
Distinct from open source software is proprietary, or closed source, software. Closed source software is strictly moderated, cannot legally be altered, copied, or distributed, and is paid for to be used as intended without modification. Only the code owners have the right to access the code.
As a company founded on the principles of freedom, every service we support is open source. We believe in contributing to the future of this vibrant and passionate ecosystem.
Open Source ideas explained in `Lego <https://www.youtube.com/watch?v=a8fHgx9mE5U>`_.
.. _lan:
LAN
===
A Local Area Network (LAN) is a computer network that interconnects computers within a limited area such as a residence, school, laboratory, university campus, or office building.
Devices on a LAN are private and protected, such that only devices connected to the same Ethernet or WiFi network can see or communicate with them.
Your Embassy hosts itself on the LAN and is reachable by visiting its *.local* URL in the browser while also connected to the LAN.
.. note:: Any device connected to a LAN can inspect all communications on that LAN. To avoid snooping, your Embassy's LAN communications are encrypted using :ref:`ssl`, which requires :ref:`additional setup <ssl-setup>`.
.. _ssl:
SSL
===
Visiting websites on the Tor network is slow. We wanted to provide a better option to access the Embassy at home. That’s why we created an address for the Embassy that can be accessed on your Local Area Network.
By default, this `.local` address is served like a regular website, over HTTP. Browsers make it noticeable when visiting a site over HTTP in the URL bar - it could be red, show an unlocked lock, or warn that the connection is not secure.
SSL certificates are what enable websites to move from HTTP to HTTPS, which increases security and makes browsers happy. Using the Secure Sockets Layer protocol, HTTPS enabled websites use certificates to establish authenticated and encrypted links between networked computers. It’s the standard technology for keeping an internet connection secure and safeguarding any sensitive data that is being sent between two devices, preventing third parties from reading and modifying any personal information transferred. They also verify ownership of a website.
Valid SSL certificates are typically issued and obtained from Certificate Authorities. These trusted third parties generate and distribute certificates, signing them with their trusted private key, which allows the clients who use them to verify their authenticity. Websites obtain a certificate from a CA then load it onto their website’s hosting service or server, allowing the website to load over HTTPS and have all traffic to and from the website be encrypted and secure.
We decided to have the Embassy act as a Certificate Authority. It creates a self-signed certificate, which means that the private key used to sign the digital certificate is the Embassy’s own private key instead of a third party’s.
When you setup SSL for your Embassy and device, the certificate communicates to the client (a browser) that the server (the Embassy) demonstrated ownership of the domain (the `start9-xxxxxxxx.local` address) to the certificate authority (created on the Embassy) at the time of certificate issuance (during the setup process). The Embassy dashboard can then be accessed from a home network (LAN) using a secure HTTPS connection!
For more information on how to setup your devices to enable this feature visit :ref:`ssl-setup`.
.. _tor:
Tor
===
The Onion Router, or Tor, is a free and open source software that enables anonymous communication. By routing Internet traffic though a worldwide, volunteer overlay network of nodes, requests are bundled in layers of encryption like the layers of an onion. The request is relayed across nodes, decrypting a layer only to reveal the next relay destination, until the request meets its final destination, without revealing the source IP address.
If a malicious third party were to intercept a request, they would see a garbled mess of the remaining onion encryption, and would only know that it came from some onion node and was heading to some other onion node. The contents, source, and destination of the message are totally anonymous.
When you use Tor to communicate with services running on the Embassy, all the traffic is onion routed and encrypted, and there are no Tor exit nodes involved - it's totally private with no configuration needed.
Furthermore, every service on the Embassy has a different Tor address, including the device itself. This is for privacy reasons - should one Tor address be exposed, the others will not be compromised. Tor addresses are actually ed25519 keys, which means they also provide all the benefits of cryptographically secure private/public keys.
Here's an introductory video on `Tor <https://www.youtube.com/watch?v=6czcc1gZ7Ak>`__.
.. _node:
Bitcoin Full Node
=================
The Embassy runs a Bitcoin Full Node. When most people say "full node" what they mean (or ought to mean) is "fully validating node", meaning that the node is capable of enforcing the consensus rules of Bitcoin by accepting, validating, and relaying every transaction and block produced by the network. Fully validating nodes are necessary for Bitcoin to exist and function properly and are what protect the network from attackers attempting to bypass the consensus rules. A fully validating node (aka full node) does not need to store the entire blockchain to accomplish this. A node that stores the entire blockchain is called a "full archival node". It is the same as a full node, except that it stores every single valid transaction and block ever produced by the network. There are not many reasons why an individual would want to run a full archival node. Most of the benefits of node operatorship are encompassed by a basic full node described above. Full archival nodes have the added benefit of enabling a block explorer. For instace, if you were interested in looking up the history of a particular address or viewing the details of a transaction, neither of which were your own. If an address or transaction is your own, you can view those details using a pruned node.
All that said, it will soon be possible to run a full archival node with he embassy, should you determine you want block explorer functionality. This will require plugging in an external hard drive to the embassy and changing a setting in the app, and also a resycnhing of the blockchain from genesis.
A video explainin the importance of running a node can be found `here <https://www.youtube.com/watch?v=oX0Yrv-6jVs>`__.
You can learn more about Bitcoin `here <https://lopp.net/bitcoin>`__.
Bitcoin wallets
===============
The word "wallet" has come to mean a lot of things, depending on who you ask and what software you are using. There are (1) software "wallets", (2) hardware "wallets", (3) seed "wallets", and (4) branch "wallets". The one thing all these wallets have in common is that they have almost nothing in common. As the terms are used today, here is usually what they mean.
(1) SOFTWARE WALLETS - (such as FullyNoded and Specter) Software applications capable of interfacing with hardware wallets (see below), interfacing with one or more nodes, as well as address creation, transaction creation, transaction broadcasting, and transaction display. Most software wallets are also capable of creating and storing public/private keypairs, granting them properties of both hardware wallets (see below) and seed wallets (see below). When we say "wallet", we are referring to software applications that posses a user interface for interacting with the Bitcoin network. If a wallet is capable of creating, storing and using private keys, it should be referred to as just a wallet with signer ability.
(2) HARDWARE WALLETS – (such as ColdCard and Trezor) Physical devices that create and store public/private keypairs, exporting the public keys, NEVER exporting the private keys, and using the private keys to sign transactions on demand. Hardware wallets must interface with a software wallet in order to be useful to a user. For this reason, some have proposed renaming hardware wallets to "hardware signers" for clarity.
(3) SEED WALLETS - Basically just the root of a hierarchical deterministic tree of keypairs. It usually takes the form of a mnemonic phrase of 12 or 24 words. Why people refer to their mnemonic seed as a "wallet" is confusing. Just call it a seed.
(4) BRANCH WALLETS - This is how Specter uses the word wallet, and it is causing a lot of confusion. Whenever you create a new "wallet" in specter, you are actually creating a new hierarchical deterministic branch of your mnemonic seed - or in the case of multisig, multiple seeds. The branch you create can be based on "purpose" (segwit, non-segwit, single-sig, multi-sig, etc), "coin type" (Bitcoin, Doegecoin, etc), or "account" (for personal accounting). Change any of these parameters, and you have yourself a new wallet, which again is just a different branch of the same mnemonic seed that potentially abides by a different set of rules. Perhaps a better name for this concept is "bank". Instead of "wallets", you should be able to create different "banks" from your seed.
Lightning Network
=================
The Lightning Network is a "payment layer" that sits on top of the Bitcoin blockchain, which it uses for final settlement. This allows Bitcoin to scale without affecting the security of the protocol layer. It is easiest to think of Lightning Network as a system that allows anyone to use their Bitcoin to have a running tab (think bar tab) of money they owe each other. For example, 2 friends may have a "channel" (tab) between them that they use for exchanging value. The channel keeps track of who owes what. Those payments can be settled at any time on the Bitcoin blockchain if either or both parties decide to close out. One big incentive to use Lightning is that payments are extremely fast and fees are extremely low. You can find an introductory video explanation `here <https://www.youtube.com/watch?v=rrr_zPmEiME>`__.
You can learn more about Lightning `here <https://lopp.net/lightning>`__.

11
source/0ld-docs/support/contact.rst Normal file
View File

@@ -0,0 +1,11 @@
.. _contact:
*******
Contact
*******
`Telegram <https://t.me/start9_labs>`_ - best for one off questions or back and forth direct messages
`Matrix <https://matrix.to/#/#community:matrix.start9labs.com>`_ - we will eventually be migrating our community channel off telegram and onto this self hosted communication platform
`support@start9labs.com <mailto:support@start9labs.com>`_ - best for more involved questions

40
source/0ld-docs/user-manual/connecting.rst Normal file
View File

@@ -0,0 +1,40 @@
.. _connecting:
**********
Connecting
**********
With the :ref:`initial-setup` complete, your Embassy is now privately hosted on the Internet and can be accessed right from a web browser. Your Embassy's addresses (its Tor and LAN URLs) are completely private; no one else even knows they exist.
If you accidentally leak your Embassy's addresses, do not worry. You Embassy is also protected by your password; so only you can log in.
Tor
===
Connecting to your Embassy over :ref:`tor` requires using a browser that supports :code:`.onion` URLs.
Currently, Tor is the default and our recommended approach for most users. It *just works*. The one drawback, however, is latency; onion-routed communications over Tor can be slow. For a lightning fast experience, you can connect to your Embassy over LAN (below), but this requires additional setup.
Below are a list of our recommended browsers for Tor:
* `Start9 Consulate <https://apps.apple.com/us/app/consulate/id1528124570>`_ (iOS)
* `Firefox <https://mozilla.org/firefox/new/>`_ (Mac, Windows, Linux)
* `Firefox Beta <https://play.google.com/store/apps/details?id=org.mozilla.firefox_beta>`_ (Android)
* `Tor Browser <https://torproject.org/download/>`_ (Mac, Windows, Linux, Android)
* `Brave <https://brave.com/>`_ (Mac, Windows, Linux)
.. seealso::
:ref:`Setting up Tor for browsers <running-tor>`
:ref:`configure_firefox_tor`
`Announcing the Consulate Browser! <https://medium.com/@start9labs/announcing-the-consulate-browser-76d94a8599cb>`_
LAN
===
Connecting to your Embassy over :ref:`lan` has the benefit of being fast! It requires that your are connected to your home network and using a browser that supports *.local* URLs, which is true for most browsers.
.. seealso:: :ref:`Installing and trusting your Embassy's Root Certificate Authority SSL<ssl-setup>`

21
source/0ld-docs/user-manual/general/developer-options/alt-marketplace.rst Normal file
View File

@@ -0,0 +1,21 @@
***********************
Alternative Marketplace
***********************
EmbassyOS supports accessing alternative marketplaces by configuring a system file. Start9 is not responsible for issues encountered by downloading services from alternative marketplaces.
After SSH-ing into the Embassy, run the following commands::
sudo systemctl stop agent
sudo sh -c "echo '<alternative_marketplace_url>' > /root/agent/alt_registry_url.txt"
sudo systemctl start agent
The Embassy is now able to connect to the provided alternative registry.
----
To revert this change, simply delete the file::
sudo systemctl stop agent
sudo rm /root/agent/alt_registry_url.txt
sudo systemctl start agent

9
source/0ld-docs/user-manual/general/developer-options/index.rst Normal file
View File

@@ -0,0 +1,9 @@
*****************
Developer Options
*****************
.. toctree::
:maxdepth: 2
ssh-setup
alt-marketplace

22
source/0ld-docs/user-manual/general/developer-options/ssh-setup.rst Normal file
View File

@@ -0,0 +1,22 @@
.. _ssh-setup:
*********
SSH Setup
*********
.. warning:: This is an advanced feature and should be used with caution. Start9 is not responsible for any damage you might cause through SSH access.
Connecting via CLI
==================
#. Navigate to *Developer Options > SSH Keys*
#. Click the ``+`` button in the lower right hand corner.
#. Paste in your SSH key.
#. You can now access your Embassy from the command line using::
ssh pi@<LAN URL>
Connecting via SSH on Windows, using PuTTY
==========================================
One of our community members, @brewsbitcoin, has put together this guide for connecting via PuTTY on Windows: https://medium.com/@brewsbitcoin/ssh-to-start9-embassy-from-windows-4a4e17891b5a

19
source/0ld-docs/user-manual/general/embassy-config.rst Normal file
View File

@@ -0,0 +1,19 @@
**************
Config Options
**************
Click "Config". Here you can set custom configurations for your Embassy. Currently, you can change the "Device Name" and enable/disable "Auto Check for Updates."
.. figure:: /_static/images/embassy_config.png
:width: 90%
:alt: Embassy Config View
.. _auto-update:
Automatic check for updates enables you to choose whether you want to be informed of EmbassyOS updates. Enabling this feature makes a request to the Start9 Marketplace to see if a new OS version has been released, and notifies you if so. This request is only made when you log into a new session or refresh your current session.
.. figure:: /_static/images/embassy_auto_check_updates.png
:width: 90%
:alt: Embassy Config View
View of Embassy Config

74
source/0ld-docs/user-manual/general/forgot-password.rst Normal file
View File

@@ -0,0 +1,74 @@
***************
Forgot Password
***************
There is currently no way to reset you Embassy master password through a standard UI flow.
SSH/Linux
=========
If you already have :ref:`SSH keys registered with your Embassy<ssh-setup>` **OR** you have access to a Linux computer, you can reset your Embassy password without losing any data.
* SSH:
* Use the command line to gain SSH access to your Embassy::
ssh pi@start9-[network-id].local
* Check if you have sqlite3 installed. If not, install it::
which sqlite3
sudo apt install sqlite3
* Access the sqlite3 terminal::
sudo sqlite3 /root/agent/start9_agent.sqlite3
* Run::
delete from account;
.quit
* Exit the SSH session::
exit
* You can now use the Start9 Setup App to reclaim your Embassy and set a new password.
.. warning:: Running setup process will generate new certificate and Tor address for your Embassy.
* Linux computer:
* Shut down your Embassy, disconnect from power, and remove the microSD card.
* Insert the microSD card into your Linux computer and mount the drive::
mount [drive] [mount folder]
* Check if you have sqlite3 installed. If not, install it::
which sqlite3
sudo apt install sqlite3
* Access the sqlite3 terminal::
sudo sqlite3 /root/agent/start9_agent.sqlite3
* Run::
delete from account;
.quit
* Un-mount the microSD card::
umount [mount folder]
* Return the microSD card to your Embassy and power it on.
* You can now use the Start9 Setup App to reclaim your Embassy and set a new password.
.. warning:: Running setup process will generate new certificate and Tor address for your Embassy.
No SSH/Linux
============
You must factory reset your device by re-installing EmbassyOS, resulting in permanent loss of data. Visit the `image downloader <https://images.start9labs.com/download>`_ to obtain a new EmbassyOS image, then follow the `installation instructions </getting-started/diy.html#installing-embassyos>`_.

17
source/0ld-docs/user-manual/general/index.rst Normal file
View File

@@ -0,0 +1,17 @@
*******
General
*******
An overview of EmbassyOS general capabilities.
.. toctree::
:maxdepth: 2
embassy-config
updating
wifi
developer-options/index
power
notifications
lan-setup/index
forgot-password

24
source/0ld-docs/user-manual/general/notifications.rst Normal file
View File

@@ -0,0 +1,24 @@
*************
Notifications
*************
You can view and manage your Notifications inside the "Notifications" tab in the main menu. They include:
* successful or failed EmbassyOS updates
* successful or failed service installations
* successful or failed service backups
* successful or failed service updates
To delete a notification, slide the notification to the left and click the *trash* icon.
.. figure:: /_static/images/embassy_notifications.png
:width: 90%
:alt: Embassy Notifications
All notifications View
.. figure:: /_static/images/embassy_notification.png
:width: 90%
:alt: Embassy notification alert
Example notification alerts

18
source/0ld-docs/user-manual/general/power.rst Normal file
View File

@@ -0,0 +1,18 @@
*****
Power
*****
Restart
=======
#. Be patient while services shut down. A *tune* will play, indicating the shutdown is complete.
#. A gentle *bep* will sound when the Embassy is powered back on.
#. A *chime* will sound when the Embassy is ready to use.
Shutdown
========
#. Be patient while services shut down. A *tune* will play, indicating the shutdown is complete.
#. It is now safe to unplug the Embassy from power and the ethernet cable, if connected.
.. note:: After a shutdown, the *only* way to turn your Embassy back on is to unplug it and plug it back in. As such, we do not recommend shutting down your Embassy when you are not physically near it. Instead, you should use the restart option.

11
source/0ld-docs/user-manual/general/updating.rst Normal file
View File

@@ -0,0 +1,11 @@
******************
Updating EmbassyOS
******************
#. Navigate to ``Menu > Embassy``
#. Click "Check for Updates"
#. If there is an update available, you will be prompted to install it.
#. While updating, your Embassy will emit a gentle chime every 20 seconds.
#. You can also enable automatic check for updates in the :ref:`Embassy config <auto-update>` tab.
.. note:: Ensure you have a stable Internet connection, and do not unplug your Embassy during an update. Updates usually complete within a few minutes, but depending on the size of the update and your Internet bandwidth, they can sometimes take up to an hour.

19
source/0ld-docs/user-manual/general/wifi.rst Normal file
View File

@@ -0,0 +1,19 @@
***************
Setting up WiFi
***************
#. Click "WiFi".
#. Click the ``+`` button in the lower right corner.
#. Select the appropriate country.
#. Enter your WiFi SSID and password.
.. figure:: /_static/images/embassy_wifi.png
:width: 90%
:alt: Add WiFi
Add WiFi Network options
#. Save
* Clicking *Add* will save the network credentials but not try to connect immediately. This is useful, for example, if you are connected over Ethernet at home and want to add your office WiFi credentials.
* `Add and Connect`.
#. The saved network will appear in the list when successfully added. If you are successfully connected, the WiFi symbol will be green, at which point, you can safely disconnect the Embassy from your router.

81
source/0ld-docs/user-manual/initial-setup.rst Normal file
View File

@@ -0,0 +1,81 @@
.. _initial-setup:
*************
Initial Setup
*************
.. youtube:: DmTlwp5_zvY
Download the Setup App
======================
`App Store <https://apps.apple.com/us/app/start9-setup-app/id1528125889>`_
`Google Play <https://play.google.com/store/apps/details?id=com.start9labs.setup>`_
`APK direct download <https://github.com/Start9Labs/setup-app/releases>`_
Power On
========
Connect your Embassy to power and Internet, normally using an ethernet port on your home Internet router.
.. note:: To avoid networking issues, it is recommended to use your primary router, not an extender or mesh router.
You will hear 2 distinct sounds:
* "bep" ‐ Powering on
* "chime" ‐ Embassy is ready
Claim Your Embassy
==================
1. Ensure your phone is connected to the same WiFi network as your router.
.. warning:: Sometmies a router will have a "guest WiFi network," which might be different than the network your Embassy is placed on via ethernet.
2. Inside the Setup App, enter the product key located on the bottom of your Embassy
.. admonition:: Explanation
:class: toggle expand
The product key is used to discover your Embassy's IP address on the Local Area Network using a hashing function and a protocol named MDNS (or Zeroconf). Once in possession of the Embassy's local IP address, the Setup App can now communicate directly with the Embassy.
.. admonition:: Troubleshooting
:class: toggle expand
#. Confirm that the Embassy is plugged into both power and Ethernet.
#. Confirm the Embassy emitted two sounds when powering on: a bep and a chime.
#. Confirm you are entering the correct product key.
#. Confirm your phone is not connected to a "Guest" network
#. Confirm your phone is not using a VPN.
#. Close and reopen the Setup App and try again.
#. Rarely, certain routers do not support mDNS. Please see the "Advanced" tab.
.. admonition:: Advanced
:class: toggle expand
If your router does not support mDNS
* On your desktop or laptop computer, navigate to your router configuration settings within the browser. This is usually an IP address such as 192.168.1.1. A simple Google search will usually reveal how to access the router configuration settings for a particular brand.
* Once in the router config settings, find the section that lists the devices on your network. You should see an item labeled "start9labs". Take note of the associated IP address and enter it into the Setup App in the "LAN IP Address" input field.
3. Create your *permanent* master password and complete setup.
.. admonition:: Explanation
:class: toggle expand
In this step, the Setup App will provide your Embassy with three pieces of critical information:
* A ed25519 private key. Used by the Embassy to create a .onion public address for encrypted and anonymous communication over Tor.
* A 4096 bit RSA private key. Used by the Embassy to create a SSL certificate for encrypted communication over LAN.
* A master password. Used by the Embassy to authenticate you as its owner.
All three secrets are packaged together and transmitted to the Embassy encrypted with its product key.
.. warning:: There is also currently no way to change your password. Choose a strong master password. Write it down. Store it somewhere safe. DO NOT LOSE IT. If you lose this password, you may be forced to reset the device, resulting in permanent loss of data.
Setup Complete!
===============
Your Embassy is now hosted on the private web. You can view and manage your Embassy by visiting its unique Tor Address from any Tor-enabled browser. The Setup App contains our recommendations for various devices.

105
source/0ld-docs/user-manual/managing-services/backups.rst Normal file
View File

@@ -0,0 +1,105 @@
*******
Backups
*******
Creating frequent service backups is critical. If anything happens to your Embassy, these backups are your only path to recovering your data.
.. warning:: Backups are encrypted using your Embassy master password. If you forget your password, you lose your backups.
Creating A Backup
=================
To begin the backup process:
1. Enter a USB drive with sufficient capacity into a USB port on the device. The blue ports are USB 3.0. The black ports are USB 2.0.
2. Navigate to the `Services` sub menu from the main dashboard menu.
3. Select the service to be backed-up.
4. Select the floppy disc icon next to the `Last Backup` menu item. If a backup was never completed, this should say "never".
.. figure:: /_static/images/bitcoin_view.png
:width: 90%
:alt: Bitcoin Core Service Sub Menu
Bitcoin Core Service Sub Menu
5. In the modal prompt, select the available disc space. If no option is marked as available, ensure the USB drive has enough space and that it is properly inserted.
.. figure:: /_static/images/bitcoin_backup_view_storage.png
:width: 90%
:alt: Bitcoin Core Service Backup Storage
Backup menu with available storage space
.. figure:: /_static/images/bitcoin_backup_view_no_storage.png
:width: 90%
:alt: Bitcoin Core Service Backup No Storage
Backup menu with no available storage disc
6. Enter the master password to encrypt the backup.
7. "Creating Backup..." will appear on the service sub menu while the backup is in process.
.. figure:: /_static/images/bitcoin_creating_backup.png
:width: 90%
:alt: Bitcoin Core Service Backup No Storage
Creating Backup
8. A notification will emit when the backup has successfully completed.
9. The `Last Backup` menu item in the service will now indicate the date and time at which the last backup was made.
Restoring A Backup
==================
To begin the backup restore process:
1. Enter the same USB stick used to originally backup the service.
2. Navigate to the `Services` sub menu from the main dashboard menu.
3. Select the service to be backed-up.
4. Select the `Restore from backup` menu item.
.. figure:: /_static/images/restore_backup_menu.png
:width: 90%
:alt: Restore backup from Services tab
Restore backup from Services tab
5. In the modal prompt, select the same disc used to originally back up the service. If no option is marked as available, ensure the USB drive is properly inserted.
.. figure:: /_static/images/restore_backup_submenu.png
:width: 90%
:alt: Restore backup submenu
Restore backup sub-menu options
6. Note the warning that restoring will wipe current data.
.. figure:: /_static/images/backup_warning.png
:width: 90%
:alt: Backup warning message
Backup warning message
7. Enter the master password to decrypt the backup and select `Restore`.
.. figure:: /_static/images/decrypt_backup.png
:width: 90%
:alt: Decrypt backup
Decrypt backup view
8. "Restoring Backup..." will appear on the service sub menu while the restoration is in process.
.. note::
The service might be momentarily unreachable as it starts back up. This is expected behavior.
.. figure:: /_static/images/restoring_backup.png
:width: 90%
:alt: Restoring backup
Restoring backup view
9. A notification will emit when the backup restoration has successfully completed.

20
source/0ld-docs/user-manual/managing-services/index.rst Normal file
View File

@@ -0,0 +1,20 @@
.. _managing-services:
*****************
Managing Services
*****************
Services are self-hosted, open source projects made compatible for EmbassyOS. Each service has been independently developed by members of the open source community. The Embassy enables configuration, customization and a one click install.
.. note:: Some services require configuration before starting up. You can only connect to and use a service once it is in a *running* state.
.. toctree::
:maxdepth: 2
installing
instructions
backups
service-config
properties
logs
managing-deps

30
source/0ld-docs/user-manual/managing-services/installing.rst Normal file
View File

@@ -0,0 +1,30 @@
*******************
Install / Uninstall
*******************
.. note:: Some services have :ref:`dependencies<managing-dependencies>` on other services. Adding, updating, or removing a service can sometimes have requirements or consequences for other services. Your Embassy will inform you of these issues along the way.
Installing
==========
To add a new service, find it's listing inside the Service Marketplace: *Marketplace > [Service Name] > Install*.
Depending on the size of the service and your Internet connection, installation should take between 60 seconds and a few minutes.
After installation, you can view the service's instructions by navigating to *Services > [Service Name] > Instructions*
.. note:: You can only start and use a service once its dependencies are met, its :ref:`configuration<service-config>` complete, and is in a *running* state.
Updating
========
To see if an update is available for a service, you can click the *refresh* button inside the dashboard of the installed service or by visiting its listing in the Service Marketplace.
If an update is available, simply click "Update" and confirm the action.
Uninstalling
============
To remove a service, navigate to *Services > [Service Name] > Uninstall*.

19
source/0ld-docs/user-manual/managing-services/instructions.rst Normal file
View File

@@ -0,0 +1,19 @@
************
Instructions
************
To view the instructions for a particular service, navigate to *Services > [Service Name] > Instructions*.
.. figure:: /_static/images/bitcoin_instructions.png
:width: 90%
:alt: Bitcoin instructions menu item
Instructions menu item
.. figure:: /_static/images/bitcoin_instructions_view.png
:width: 90%
:alt: Bitcoin instructions view
Instructions view
.. note:: For advanced instructions and integration guides, visit the wrapper repository for an :ref:`available service <available-services>`.

7
source/0ld-docs/user-manual/managing-services/logs.rst Normal file
View File

@@ -0,0 +1,7 @@
************
Viewing Logs
************
Naviage to *Services > [Service Name] > Logs*
Every service emits logs while it is in a *running* state. Logs give an *under-the-hood* glimpse of a service and can be extremely useful for debugging purposes. To a non-technical user, logs may look like gibberish, and sometimes there is nothing to see at all.

13
source/0ld-docs/user-manual/managing-services/managing-deps.rst Normal file
View File

@@ -0,0 +1,13 @@
.. _managing-dependencies:
*********************
Managing Dependencies
*********************
Some services have dependencies on other services. A service may even require its dependency to be *configured* in a particular way.
Traditionally, managing dependencies was a massive headache and a huge barrier to running a personal server. But no more! The Embassy's revolutionary dependency management system makes the process transparent and simple.
If a service has one or more dependencies, or a dependency needs to be configured in a particular way, your Embassy will inform you and offer solutions.
Sometimes, a dependency can be satisfied in multiple ways. For example, Lightning has a dependency on Bitcoin. But that does not necessarily mean you need to have Bitcoin installed on your Embassy. You could just as easily configure Lightning to use another Bitcoin node located somewhere else!

13
source/0ld-docs/user-manual/managing-services/properties.rst Normal file
View File

@@ -0,0 +1,13 @@
**********
Properties
**********
Navigate to *Services > [Service Name] > Properties*
Properties are both static and dynamic information about a service. They could be almost anything: a default username/password, an invite code, or a list of peers - anything the service developer thought might be useful.
Properties may be accompanied by one or more of the following:
* a *help* icon for further explanation.
* a *copy* icon for copying the value to your clipboard.
* a *QR* icon for viewing the value as a QR code.

13
source/0ld-docs/user-manual/managing-services/service-config.rst Normal file
View File

@@ -0,0 +1,13 @@
.. _service-config:
**************
Service Config
**************
Navigate to *Services > [Service Name] > Config*
After installation or update, some services require configuration before they can be started.
Traditionally, configuring services was a massive headache and a huge barrier to running a personal server. But no more! The Embassy's revolutionary service config system makes the process transparent, simple, and safe.
Config options are defined by the service developer and can be almost anything. They are represented as simple UI elements - such as toggles and drop downs - and they include explanations and validations, such that users understand their purpose and are prevented from making mistakes.

0
source/dev-docs/dev-faq/faq-contributing.rst Normal file
View File

0
source/dev-docs/dev-faq/faq-service-packaging.rst Normal file
View File

0
source/dev-docs/example.rst Normal file
View File

12
source/dev-docs/index.rst Normal file
View File

@@ -0,0 +1,12 @@
***********************
Developer Documentation
***********************
An overview of EmbassyOS general capabilities.
.. toctree::
:maxdepth: 2
service-packaging/index
example
dev-faq/index

29
source/dev-docs/service-packaging/backups.rst Normal file
View File

@@ -0,0 +1,29 @@
.. _service_backups:
***************
Service Backups
***************
Everything within the root of the mounted volume directory will be stored in an EmbassyOS backup. This includes the config (config.yaml) and properties (stats.yaml) files, as well as any other persisted data within the volume directory.
For restoration purposes, it might be beneficial to ignore certain files or folders. For instance, ignore the shared/public folder that is mounted for dependencies that expose this feature as it causes data inconsistencies on restore.
In this case, create a `.backupignore` file. This file contains a list of relative paths to the ignored files.
Example
=======
The `btcpayserver wrapper <https://github.com/Start9Labs/btcpayserver-wrapper/blob/master/configurator/src/templates/.backupignore.templates>`_ demonstrates a good use of a backupignore template.
Ultimately, ``/datadir/.backupignore`` gets populated with:
.. code::
/root/volumes/btcpayserver/start9/public
/root/volumes/btcpayserver/start9/shared
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

617
source/dev-docs/service-packaging/config.rst Normal file
View File

@@ -0,0 +1,617 @@
.. _service_config:
****************************
Service Config Specification
****************************
Overview
========
Most self-hosted applications require the user to tell the app how to behave using a config file in a specific format, environment variables, command-line arguments, or some combination of these inputs. One of the coolest features of EmbassyOS is that, when packaged correctly, the app's configuration will be available to the user as a slick GUI that always produces a valid configuration no matter how little experience or skill the user has.
With EmbassyOS, this means a service wrappers' configuration requires a particular format and rule structure to ensure it integrates smoothly with the user interface. This format enables clean handling of improper values and dependency management.
The outcome of this step is two files:
:ref:`config_spec.yaml <config_spec>`
:ref:`config_rules.yaml <config_rules>`
These files contain a detailed mapping of configuration options with acceptable values, defaults, and relational rule-sets.
For example, if the user chooses config option A, then config option B must be between 5 and 10. This enables a simple GUI configuration experience, complete with validations and protections, for users. They do not have to worry about the consequences of a wrong value in a ``.conf`` file.
.. _config_spec:
Config Spec
===========
Overview
--------
.. figure:: /_static/images/service/bitcoin_config.png
:width: 80%
:alt: Bitcoin Config
This file defines the structure of configuration options your service depends on to run. It additionally can include configuration options that users might want to enable for more advanced or customized usage. Ultimately, these values influence the UI elements for a user to interact with. Specifically, they evaluate to the options available when managing a service, such as:
- Prior to service installation when the user needs to be made aware of any necessary dependency configurations
- When the user installs a service and the service is in the "Needs Config" state
- Whenever a user edits a service config
- When config pointers get updated
The neat part about this file is that each ValueSpec type gets translated into a specific front end component. For instance, boolean values display as a toggle button.
.. figure:: /_static/images/service/boolean_toggle.png
:width: 80%
:alt: Example boolean toggle
Another advantage is the ability to define default values. These values automatically get populated if the user selects the ``Default`` option when setting up a service in ``Needs Config`` state. This is super convenient for users who want to get up and running quickly.
Types
-----
ConfigSpec Type:
.. code::
key: ValueSpec
ValueSpec Type: Boolean | Enum | List | Number | Object | String | Union | Pointer (see below for details)
Implementation Guide
--------------------
The following section contains implementation specifications for the ``config_spec.yaml`` file.
- All keys are ``kebab-case`` strings, which correspond to the service (app) id
- All values are one the following specs (ie. ``ValueSpec`` type):
:ref:`boolean <boolean>`
:ref:`enum <enum>`
:ref:`list <list>`
:ref:`number <number>`
:ref:`object <object>`
:ref:`string <string>`
:ref:`union <union>`
:ref:`pointer <pointer>`
- In the examples for each value spec type below, ``Option`` means the key is optional. Otherwise, the key is required.
- Descriptions are optional, but recommended
- Name corresponds to the name of the config field
- Find a complete example :ref:`here <example_config_spec>`
- Change warning text displays when the value is altered
.. _boolean:
Boolean
^^^^^^^
Config value specification denoted as a boolean value. A default value is required.
``ValueSpec`` Type:
.. code::
type: boolean
name: String
description: Option<String>
changeWarning: Option<String>
default: Boolean
Example:
.. code:: yaml
fetch-blocks:
type: boolean
name: Fetch Blocks
description: Fetch blocks from the network if pruned from disk
default: true
.. _enum:
Enum
^^^^
Config value specification denoted as an enum value. Enums values must be a unique set. If no default is provided, ``null`` will be the assumed value.
ValueSpec Type:
.. code::
type: enum
name: String
description: Option<String>
changeWarning: Option<String>
default: Option<Enum>
values: Set<String>
.. code:: yaml
theme-mode:
type: enum
name: Theme Mode
values:
- NIGHT
- DAY
valueNames:
NIGHT: Night
DAY: Day
default: NIGHT
.. _list:
List
^^^^
The list type describes an array of values. The values must consist of the same subtype, which can be any of the ValueSpec types available in the EmbassyOS config specification.
Lists of any type do not contain the default for each item in list. The list *itself* can have a default. If no default is provided, ``null`` will be the assumed value.
Range is loosely based off mathematical range syntax, with infinity replaced with ``*``:
``[ || ]`` = inclusive
``( || )`` = noninclusive
``*`` = infinity on either end
eg:
.. code::
[0,*) - all numbers to infinity including 0
ValueSpec Type:
.. code::
type: list
name: String
description: Option<String>
subtype: enum || number || object || string || union
range: NumRange<unsigned integer>
spec: ValueSpec
default: ValueSpec
Example:
.. code:: yaml
allowed-calls:
type: list
name: Allowed Calls
description: The list of all RPC methods this user is allowed to make
subtype: enum
range: "[0, *)"
spec:
type: enum
values:
- item
- item
.. _number:
Number
^^^^^^
A number value within an optionally defined range. Nullable field is required. If ``nullable`` is true, the default is assumed to be ``null`` if it is not provided.
ValueSpec Type:
.. code::
type: number
name: String
description: Option<String>
changeWarning: Option<String>
default: Boolean
nullable: Boolean
range: Option<NumRange<64 bit floating point>>
integral: Boolean
units: Option<String>
Example:
.. code:: yaml
type: number
name: Peer Message Timeout
description: How long to wait for a response from a peer before failing
nullable: false
integral: true
units: Seconds
range: "[0, *)"
default: 30
.. _object:
Object Type
^^^^^^^^^^^
A nested representation of a ConfigSpec. The object type takes the same structure under the ``spec`` key as a ConfigSpec: a key indicates the field name, and the value denotes the ValueSpec type for that field.
There is no default option for the object type. Rather, the option ``null-by-default`` should be used to indicate the default as ``null``. If null by default is true, nullable must be true. If null by default is false, nullable could be either.
``unique-by`` indicates whether duplicates can be permitted in the list.
ValueSpec Type:
.. code::
type: object
name: String
description: Option<String>
changeWarning: Option<String>
nullable: Boolean
null-by-default: Boolean
display-as: Option<String>
unique-by: UniqueBy
spec: ConfigSpec
type UniqueBy = null | string | { any: UniqueBy[] } | { all: UniqueBy[] }
Example:
.. code:: yaml
type: object
name: Advanced
description: Advanced settings for Bitcoin Proxy
nullable: false
spec:
tor-only:
type: boolean
name: Only Tor Peers
description: Use Tor for all peer connections
default: false
peer-timeout:
type: number
name: Peer Message Timeout
description: How long to wait for a response from a peer before failing
nullable: false
integral: true
units: Seconds
range: "[0, *)"
default: 30
max-peer-age:
type: number
name: Maximum Peer Age
description: How long to wait before refreshing the peer list
nullable: false
integral: true
units: Seconds
range: "[0, *)"
default: 300
max-peer-concurrency:
type: number
name: Maximum Peer Concurrency
description: How many peers to reach out to concurrently for block data
nullable: true
integral: true
range: "[1, *)"
default: 1
.. _string:
String
^^^^^^
There are various options for string values. They can optionally be marked as copyable or masked, such as for passwords, which will reflect the UI element display. A pattern, expressed in regex, can be denoted. If it exists, this field requires both the pattern type (ie. Regex) and pattern description (ie. an explanation of the pattern requirements).
If the default type is ``Entropy``, the charset can optionally specify an inclusive ranged character set (ie. "a-f,0-9").
ValueSpec Type:
.. code::
type: string
name: String
description: Option<String>
changeWarning: Option<String>
copyable: Option<boolean>
masked: Option<boolean>
nullable: Boolean
default: String | Entropy
pattern: Option<Regex>
pattern-description: Option<String>
Entropy Type:
.. code::
charset: Option<String>
len: integer
Examples:
.. code::
color:
type: string
name: Color
description: Color value for the Lightning Network
nullable: false
pattern: "[0-9a-fA-F]{6}"
patternDescription: |
Must be a valid 6 digit hexadecimal RGB value. The first two digits are red, middle two are green and final two are
blue
default:
charset: "a-f,0-9"
len: 6
password:
type: string
name: Password
description: The password for the RPC User
nullable: false
copyable: true
masked: true
default:
charset: "a-z,A-Z,0-9"
len: 22
.. _pointer:
Pointer
^^^^^^^
The pointer type *points* to a config value on another service installed on EmbassyOS (ie. app subtype) or to the EmbassyOS system (ie. system subtype). When pointing to another service, the ``index`` field indicates the path to the desired config variable.
ValueSpec Type:
.. code::
type: pointer
name: String
description: Option<String>
changeWarning: Option<String>
subtype: app | system
app-id: String (*always* kebab case)
target: AppPointerSpecVariants | SystemPointerSpecVariants
index: Option<String> (dependent on target being AppPointerSpecVariants)
AppPointerSpecVariants = LanAddress | TorAddress | TorKey | Config
SystemPointerSpecVariants = HostIp
Example:
.. code::
user:
type: pointer
name: RPC Username
description: The username for the RPC user for Bitcoin Core
subtype: app
app-id: bitcoind
target: config
index: "rpc.username"
.. _union:
Union
^^^^^
This type describes a necessary dependency. Multiple variants can be expressed to enable the user the option to connect to another service (internal dependency) or outside source (external dependency).
For example, the Bitcoin Proxy service is united with an instance of Bitcoin. Three variants are defined: internal, external, and a quick connect. In this case, internal refers to the Bitcoin Core instance running on EmbassyOS, and defines the RPC credentials necessary for connecting; external refers to a Bitcoin Core node running on a different device, and defines the RPC credentials necessary for connecting; quick connect refers to yet another method of connecting to a Bitcoin Core node, optimized for convenience.
Default is required and corresponds to one of the variants.
``Tag`` is the key that will be rendered on the UI element.
ValueSpec Type;
.. code::
type: union
name: String
description: Option<String>
changeWarning: Option<String>
default: Boolean
tag: Tag
variants: Map<String, ConfigSpec>
display-as: Option<String>
unique-by: any | all | exactly | notUnique
Tag Type:
.. code::
id: String
name: String
description: Option<String>
variant-names: Map<String, String>
.. _example_config_spec:
Example:
.. code:: yaml
bitcoind:
type: union
name: Bitcoin Core
description: The Bitcoin Core node to connect to
tag:
id: type
name: Type
description: |
- Internal: The Bitcoin Core service installed to your Embassy
- External: A Bitcoin Core node running on a different device
- Quick Connect: A Quick Connect URL for an unpruned Bitcoin Core node
variant-names:
internal: Internal
external: External
quick-connect: Quick Connect
default: internal
variants:
internal:
address:
type: pointer
name: Local Address
description: The LAN IP address of your Bitcoin Core service
subtype: app
app-id: bitcoind
target: lan-address
user:
type: pointer
name: RPC Username
description: The username for the RPC user for Bitcoin Core
subtype: app
app-id: bitcoind
target: config
index: "rpc.username"
password:
type: pointer
name: RPC Password
description: The password for the RPC user for Bitcoin Core
subtype: app
app-id: bitcoind
target: config
index: "rpc.password"
external:
addressext:
type: string
name: Public Address
description: The public address of your Bitcoin Core RPC server
nullable: false
userext:
type: string
name: RPC Username
description: The username for the RPC user on your Bitcoin Core RPC server
nullable: false
passwordext:
type: string
name: RPC Password
description: The password for the RPC user on your Bitcoin Core RPC server
nullable: false
quick-connect:
quick-connect-url:
type: string
name: Quick Connect URL
description: The Quick Connect URL for your Bitcoin Core RPC server
nullable: false
pattern: 'btcstandup://[^:]*:[^@]*@[a-zA-Z0-9.-]+:[0-9]+(/(\?(label=.+)?)?)?'
patternDescription: Must be a valid Quick Connect URL. For help, check out https://github.com/BlockchainCommons/Gordian/blob/master/Docs/Quick-Connect-API.md
.. _config_rules:
Config Rules
============
This file defines the configuration rules, or the rule-set that defines dependencies between config variables. In practice, config rules are for auto-configuring self dependencies. Self dependencies are internal dependencies of a service, such as if the setting of one config variable informs the option of another setting. These "dependencies" are configured as rules.
A rule is a boolean expression that we demand to be true. It is not true if the expression fails the rule parser.
They follow the `Backus–Naur <https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form>`_ meta-syntax for writing rules.
Rules are composed of two main concepts:
* Variables - accessor into a configuration
* Terms - either a variable or type literal (ie. a boolean term is a boolean variable, a boolean expression, or a comparison operation between numbers or strings)
Variables can be booleans, numbers, or strings, and have a different syntax depending on the type. These type annotations check your config rules against your config spec and throw an error if invalid.
- ``?`` - Casts to boolean value. If the value is not a boolean, this notes whether or not the value is null.
- ``#`` - Treat the value as a number. If it is not a number, the value will be parsed as NaN. String numbers are not currently supported.
- ``'`` - Cast the value into a string. Applies to any value except for an object or a list.
- ``!`` - Equals not.
.. note::
Config rules are processed in order.
If application does not satisfy a rule, a set of suggestions should be provided. These suggestions are in the form of the operation to preform:
- ``Set`` - set the value
- ``Push`` - add to the value (such as to a list)
- ``Delete`` - delete the value
.. code:: typescript
enum SuggestionVariant = Set | Delete | Push
interface Set {
var: String, // fully qualified path without typecast
// one of the following three variants are required
to: Option<String> // a string expression, use when tying another config value
to-value: Option<String>
to-entropy: Option<{
charset: String (eg. 'a-z,A-Z,0-9')
len: Number
}>
}
interface Delete {
src: String, // path to key - removes if in a list
}
interface Push {
to: String,
value: String, // string literal of value to be set
}
Set Examples:
.. code:: yaml
- SET:
# the key in config you want to set
var: 'users.[first(item => ''item.name = "c-lightning")].password'
# the value in config that you will set
to-entropy:
charset: "a-z,A-Z,0-9"
len: 22
- SET:
var: 'users.[first(item => ''item.name = "c-lightning")].fetch-blocks'
to-value: true
Push Examples:
.. code:: yaml
- PUSH:
to: "users"
value:
name: c-lightning
allowed-calls: []
- PUSH:
to: 'users.[first(item => ''item.name = "c-lightning")].allowed-calls'
value: "getnetworkinfo"
Full example from `c-lightning manifest <https://github.com/Start9Labs/c-lightning-wrapper/blob/master/manifest.yaml>`_:
.. code:: yaml
config:
- rule: '''users.*.name = "c-lightning"'
description: 'Must have an RPC user named "c-lightning"'
suggestions:
- PUSH:
to: "users"
value:
name: c-lightning
allowed-calls: []
- SET:
var: 'users.[first(item => ''item.name = "c-lightning")].password'
to-entropy:
charset: "a-z,A-Z,0-9"
len: 22
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

40
source/dev-docs/service-packaging/docker.rst Normal file
View File

@@ -0,0 +1,40 @@
.. _service_docker:
******************
Service Dockerfile
******************
Dockerfile
==========
This purpose of the Dockerfile is to define how to build the image for the service. It declares the environment and building stages.
The Dockerfile is responsible for mounting the service application to whatever volume the manifest specifies, typically ``/root/.<service-id>``.
Since the build requires specific arm runtime environments, these base images can be imported into the Dockerfile as a starting point so the base system does not need to be completely redefined. This enables importing a specific build environment version that encapsulates any necessary libraries for running the service build, eg. golang, rust.
For instance:
``FROM alpine:3.12``
``FROM arm32v7/alpine``
``FROM arm32v7/golang:alpine``
We recommended using ``alpine`` since it produces the smallest image. We try to keep the image under 100MB when possible.
Entry-point
===========
The ``docker_entrypoint.sh`` defines what to do when the service application starts.
It consists of a bash script that completes any environment setup (eg. creating folder substructure), sets any environment variables, and executes the run command. The only required feature of this file is to execute the run commands for EmbassyOS.
Example
=======
The `LND wrapper <https://github.com/Start9Labs/lnd-wrapper/blob/master/Dockerfile>`_ features a well defined Dockerfile, for example.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

44
source/dev-docs/service-packaging/index copy.rst Normal file
View File

@@ -0,0 +1,44 @@
.. _service_pacakge:
***********************
Service Packaging Guide
***********************
Welcome! If you are here, you are interested in becoming part of the mission to change the future of personal computing. This guide will take you through the process of packaging a service for EmbassyOS, a novel, self-hosted, sovereign computing platform.
A service in this context is any open source project that has been bundled into the appropriate format to run on EmbassyOS. By configuring and packaging a project according to this guide, it can be installed on EmbassyOS with no command line or technical expertise required. This opens up an entire platform for self-hosted software to run independent of third parties in a completely private and sovereign way for all individuals.
This guide is technical, but breaks down the steps for deployment. If you have any feedback or questions concerning this guide, please don't hesitate to `reach out <https://matrix.to/#/#community-dev:matrix.start9labs.com>`_ or submit a pull request with alterations.
To start, you will need to acquire EmbassyOS for testing the packaged service. This can be done by:
- building from `source <https://github.com/Start9Labs/embassy-os/blob/master/CONTRIBUTING.md#setting-up-your-development-environment>`_
- following the :ref:`DIY <diy>` guide
- :ref:`purchasing <purchasing>` the ready to run personal server
While you are waiting to receive or assemble a device, you can begin the process of packaging a project. The sections below outline these steps in detail.
Happy building!
.. toctree::
:maxdepth: 1
Overview <overview>
Wrapper <wrapper>
Manifest <manifest>
Docker <docker>
Makefile <makefile>
Config <config>
Properties <properties>
Instructions <instructions>
Backups <backups>
Submission process
------------------
When you have built and tested your project for EmbassyOS, please send Start9 a submission with the project repository to ``dev@start9labs.com``. After being reviewed for security and compatibility, the service will be deployed to the marketplace and available for all EmbassyOS users to download.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

18
source/dev-docs/service-packaging/index.rst Normal file
View File

@@ -0,0 +1,18 @@
*****************
Service Packaging
*****************
An overview of EmbassyOS general capabilities.
.. toctree::
:maxdepth: 2
overview
wrapper
manifest
docker
makefile
config
properties
instructions
backups

23
source/dev-docs/service-packaging/instructions.rst Normal file
View File

@@ -0,0 +1,23 @@
.. _service_instructions:
************************************
Service Instructions & Documentation
************************************
Within each wrapper repository should exist a ``docs`` directory. This folder should include any pertinent documentation, instructions, external integrations, or other details about the service that users or developers might find relevant.
If an ``instructions.md`` file is included, this markdown formatted file will be rendered in the "Instructions" tab within the service detail menu on EmbassyOS:
.. figure:: /_static/images/service/bitcoin_instructions.png
:width: 80%
:alt: Bitcoin Instructions
Example
=======
The `bitcoind wrapper <https://github.com/Start9Labs/bitcoind-wrapper/tree/master/docs>`_ demonstrates a good use of instructions and external integrations.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

30
source/dev-docs/service-packaging/makefile.rst Normal file
View File

@@ -0,0 +1,30 @@
.. _service_makefile:
****************
Service Makefile
****************
.. note::
*This file is optional*
A Makefile serves as a convenience for outlining the build. This helps streamline additional developer contributions to the project. Please reference the GNU `documentation <https://www.gnu.org/software/make/manual/html_node/Introduction.html>`_ for implementation details.
An alternative to using ``make`` is to use the `nix <https://nixos.wiki/wiki/Nix>`_ specification.
This purpose of this file is to:
- Read the docker container and build the project
- Build all prerequisites for running the docker file
- Build all dependencies
- Package ``config_rules.yaml``, ``config_spec.yaml``, ``manifest.yaml``, and ``image.tar`` into an ``.s9pk`` extension by invoking ``appmgr``.
Example
=======
The `LND wrapper <https://github.com/Start9Labs/lnd-wrapper/blob/master/Makefile>`_ features a well defined Makefile, for example.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

352
source/dev-docs/service-packaging/manifest.rst Normal file
View File

@@ -0,0 +1,352 @@
.. _service_manifest:
****************
Service Manifest
****************
Overview
========
This file describes the service and it's requirements. It is used to:
- create a listing in the marketplace
- denote any installation considerations
- define dependency requirements
Each time a service is updated, the manifest should be updated to include the new version, release notes, and any pertinent updates to the install, uninstall, or restoration flows. All this information is displayed in the marketplace listing, and the optionally denoted alerts will be displayed when appropriate to provide the user with more information.
For instance, `LND displays alerts <https://github.com/Start9Labs/lnd-wrapper/blob/master/manifest.yaml#L28>`_ around restoration since data will be overwritten.
There is nothing you need to do as a developer to set up Tor for running a service. This is *completely* handled by EmbassyOS - a Tor address will be automatically generated when the service is installed. Just define the port and which version of Tor the service needs in this manifest file! You do, however, need to ensure the service is in fact capable of running over Tor.
The manifest is also responsible for outlining service :ref:`dependencies <dependencies>`. By defining rules using the :ref:`EmbassyOS DSL specification <config_rules>`, users can easily and selectively install, uninstall, and update any service without getting stuck in dependency hell. EmbassyOS presents this information in a polished install/uninstall/update wizard, so there's no need for editing configuration files or jumping into the command line. For you as a developer, this simply means populating this key in the manifest!
Formatting
==========
- Serialization language:``.yaml``
- Case style: ``kebab-case``
Type definitions
================
Below are the types and sub-type definitions, with necessary elaborations. Any item that contains ``Option<>`` is an optional field.
.. code:: yaml
# manifest version compatibility ie. v0 (this is currently the only option)
compat: v0
# service id, used for uniqueness and BE identification ie. bitcoind
id: String
# version number of the release conforming to the semantic versioning scheme
version: String
# display name of service
title: String
# an object containing a short and long description of the service. TODO character lengths
description:
short: String
long: String
# a link to the release tag notes in GitHub, or a short description TODO character length
release-notes: String
# a notification message that should caution the user with any service particularities, eg. beta tech
install-alert: Option<String>
# a notification message warning users of potential problems with uninstalling, such as dependency failures or data loss
uninstall-alert: Option<String>
# a notification message containing warning or details about backup restoration
restore-alert: Option<String>
# denoting the existence of instructions.md
has-instructions: Boolean
# required semver version range of EmbassyOS to run service eg. ">=1.0.0"
os-version-required: VersionReq
# recommended semver version range of EmbassyOS to run service eg."^1.0.0"
os-version-recommended: VersionReq
# a list of objects of ports to run the service on localhost and tor
ports:
- internal: String
tor: String
# currently only tar is supported
image:
type: String
# shared memory container size
shm-size-mb: Option<usize>
# path to mount the image on the volume, ie: /root/bitcoind
mount: String
# read only data exposed to dependencies (path is relevant to mount)
public: Option<String>
# shared filesystem segment with each of your dependencies (path is relevant to mount)
shared: Option<String>
# deprecated - will default to an empty vector
assets: []
# version of tor support, eg. v2, v3
hidden-service-version: String
# A map of dependent services, see below for more details
dependencies: Dependencies
.. _dependencies:
Dependencies
============
Many services depend on other libraries and services on EmbassyOS (such as Bitcoin), sometimes even a particular version of those services, which need to be specified by the developers so that EmbassyOS can handle installing these dependencies under the hood.
The key of each field in the dependencies object is the lowercase, kebab-case app ID of the service that is depended on. Each dependency contains a set of rules that need to be fulfilled as true if the dependency is to be properly installed. The "config rules" here are for auto-configuring dependencies - the action defined by the rule will be executed if the service is auto configured with defaults during initial setup. This simplifies and streamlines the user experience. The interface should provide suggestions for the behavior if the denoted rule cannot be met with previous configurations.
Let's take this snippet for example:
.. code:: yaml
...
dependencies:
btc-rpc-proxy:
version: "^0.1.0"
optional: Can configure an external bitcoin node.
description: Required for fetching validated blocks.
config:
- rule: '''users.*.name = "c-lightning"'
description: 'Must have an RPC user named "c-lightning"'
suggestions:
- PUSH:
to: 'users'
value:
name: c-lightning
...
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`
The service ``btc-rpc-proxy`` is a dependency of the service ``c-lightning``. ``c-lightning`` requires it to be installed at a version >=0.1.0 <0.2.0. There exists a rule that states the config option ``user.name`` must be equal to "c-lightning". If this value does not exist for ``user.name`` when accessed, ``PUSH`` the value "c-lighting" to the field. This all takes place during the initial service configuration, before the service is started for the first time.
.. note::
Dependency config rules are processed in order.
Type definitions
----------------
Types for ``manifest.yaml`` fields:
.. code:: typescript
interface Dependencies [{
serviceId: DepInfo
}]
interface DepInfo {
version: String // ie. 0.11.1.1
optional?: String,
description?: String,
config: [ConfigRule],
],
}
interface ConfigRule {
rule: String, // ie. 'users.*.name = "lnd"
description: String,
suggestions: [SuggestionVariant]
}
interface SuggestionVariant {
SET: {
var: String,
to: SetVariant,
},
DELETE: {
src: String,
},
PUSH: {
to: String,
value: Value,
},
}
interface SetVariant {
to: Option<String>,
to-value: Option<Value>, // ie. true/false
to-entropy: Option<{
charset: String // ie. 'a-z,A-Z,0-9'
len: number
}>
}
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`
Examples
--------
Actual ``manifest.yaml`` files for existing services:
LND
^^^
.. code:: yaml
compat: v0
id: lnd
version: 0.11.1.1
title: Lightning Network Daemon
description:
short: "A complete implementation of a Lightning Network node by Lightning Labs"
long: "LND fully conforms to the Lightning Network specification (BOLTs). BOLT stands for: Basis of Lightning Technology. In the current state lnd is capable of: creating channels, closing channels, managing all channel states (including the exceptional ones!), maintaining a fully authenticated+validated channel graph, performing path finding within the network, passively forwarding incoming payments, sending outgoing onion-encrypted payments through the network, updating advertised fee schedules, and automatic channel management (autopilot)."
release-notes: https://github.com/lightningnetwork/lnd/releases/tag/v0.11.1-beta
ports:
- internal: 8080
tor: 8080
- internal: 9735
tor: 9735
- internal: 9911
tor: 9911
- internal: 10009
tor: 10009
image:
type: tar
mount: /root/.lnd
public: public
has-instructions: true
os-version-required: ">=0.2.8"
os-version-recommended: ">=0.2.8"
install-alert: |
READ CAREFULLY! LND and the Lightning Network are considered beta software. Please use with caution and do not risk more money than you are willing to lose. We encourage frequent backups. If for any reason, you need to restore LND from a backup, your on-chain wallet will be restored, but all your channels will be closed and their funds returned to your on-chain wallet, minus fees. It may also take some time for this process to occur.
uninstall-alert: "READ CAREFULLY! Uninstalling LND will result in permanent loss of data, including its private keys for its on-chain wallet and all channel states. Please make a backup if you have any funds in your on-chain wallet or in any channels. Recovering from backup will restore your on-chain wallet, but due to the architecture of the Lightning Network, your channels cannot be recovered. All your channels will be closed and their funds returned to your on-chain wallet, minus fees. \n"
restore-alert: |
Restoring LND will overwrite its current data, including its on-chain wallet and channels. Any channels opened since the last backup will be forgotten and may linger indefinitely, and channels contained in the backup will be closed and their funds returned to your on-chain wallet, minus fees.
assets: []
hidden-service-version: v3
dependencies:
btc-rpc-proxy:
version: "^0.2.4"
optional: Can alternatively configure an external bitcoin node.
description: Used to fetch validated blocks.
config:
- rule: '''users.*.name = "lnd"'
description: 'Must have an RPC user named "lnd"'
suggestions:
- PUSH:
to: "users"
value:
name: lnd
allowed-calls: []
- SET:
var: 'users.[first(item => ''item.name = "lnd")].password'
to-entropy:
charset: "a-z,A-Z,0-9"
len: 22
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getinfo"'
description: 'RPC user "lnd" must have "getinfo" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getinfo"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getbestblockhash"'
description: 'RPC user "lnd" must have "getbestblockhash" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getbestblockhash"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "gettxout"'
description: 'RPC user "lnd" must have "gettxout" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "gettxout"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getblockchaininfo"'
description: 'RPC user "lnd" must have "getblockchaininfo" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getblockchaininfo"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "sendrawtransaction"'
description: 'RPC user "lnd" must have "sendrawtransaction" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "sendrawtransaction"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getblockhash"'
description: 'RPC user "lnd" must have "getblockhash" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getblockhash"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getblock"'
description: 'RPC user "lnd" must have "getblock" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getblock"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getblockheader"'
description: 'RPC user "lnd" must have "getblockheader" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getblockheader"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "estimatesmartfee"'
description: 'RPC user "lnd" must have "estimatesmartfee" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "estimatesmartfee"
- rule: '''users.[first(item => ''item.name = "lnd")].allowed-calls.* = "getnetworkinfo"'
description: 'RPC user "lnd" must have "getnetworkinfo" enabled'
suggestions:
- PUSH:
to: 'users.[first(item => ''item.name = "lnd")].allowed-calls'
value: "getnetworkinfo"
- rule: 'users.[first(item => ''item.name = "lnd")].fetch-blocks?'
description: 'RPC user "lnd" must have "Fetch Blocks" enabled'
suggestions:
- SET:
var: 'users.[first(item => ''item.name = "lnd")].fetch-blocks'
to-value: true
bitcoind:
version: "^0.21.0"
optional: Can alternatively configure an external bitcoin node.
description: Used to subscribe to new block events.
config:
- rule: "zmq-enabled?"
description: "Must have an ZeroMQ enabled"
suggestions:
- SET:
var: "zmq-enabled"
to-value: true
Cups
^^^^
.. code:: yaml
compat: v0
id: cups
version: "0.3.6"
title: "Cups Messenger"
description:
short: "Real private messaging"
long: "Cups is a private, self-hosted, peer-to-peer, Tor-based, instant messenger. Unlike other end-to-end encrypted messengers, with Cups on the Embassy there are no trusted third parties."
release-notes: |
Features
- Adds instructions defined by EmbassyOS 0.2.4 instructions feature
ports:
- internal: 59001
tor: 59001
- internal: 80
tor: 80
image:
type: tar
mount: /root
has-instructions: true
os-version-required: ">=0.2.4"
os-version-recommended: ">=0.2.4"
assets:
- src: httpd.conf
dst: "."
overwrite: true
- src: www
dst: "."
overwrite: true
hidden-service-version: v3
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

103
source/dev-docs/service-packaging/overview.rst Normal file
View File

@@ -0,0 +1,103 @@
.. _service_package_overview:
************************
Service Package Overview
************************
There are several main components that comprise a service package for EmbassyOS. This overview will introduce them and following sections will dive into technical specifics.
First, let's get your system setup with the necessary software dependencies.
Environment Setup
=================
At minimum, ``docker``, ``docker-buildx``, and ``appmgr`` are required. The rest of the recommendations serve to optimize the build process.
Recommended Dependencies
------------------------
`docker <https://docs.docker.com/get-docker>`_
`docker-buildx <https://docs.docker.com/buildx/working-with-buildx/>`_
`appmgr <https://github.com/Start9Labs/embassy-os/tree/master/appmgr>`_
`cargo <https://doc.rust-lang.org/cargo/>`_
`yq (version 4) <https://mikefarah.gitbook.io/yq>`_
`make <https://www.gnu.org/software/make/>`_
`musl <https://github.com/Start9Labs/rust-musl-cross>`_
Package Components
==================
Image
-----
Each service boils down to a Docker image. We're not going to dive into Docker specifics in this guide, since there exists tons of `resources <https://docs.docker.com/>`_ for developing with this containerization tool.
Because the service ultimately runs on a Raspberry Pi, the created Docker image should be a snapshot of an arm based linux environment. The service image is then mounted to the EmbassyOS image during installation. This path is defined in the :ref:`manifest <service_manifest>` configuration file.
The image is immutable, meaning that when the service is updated, the image is replaced with a completely new image containing the updated features.
Volume
------
Each service application gets a volume allocated to it by EmbassyOS. All service application data is stored in this directory and is persisted across updates.
The volume directory (for seeding data into the volume) is typically: ``/root/volumes/<service-id>``.
.. warning::
Any files that are in the image at the volume path will be overwritten when a backup restore occurs.
Dependencies
------------
When it comes to running your own server, managing dependencies is perhaps the most difficult part. The term "dependency hell" emerged from this sentiment. Even the best developers have lost significant amounts of time trying to find, correct, or clarify documentation for dependencies or dependency configuration. Individuals who manage their own servers have specific technical skills and are willing to devote the time and effort necessary to maintain them. Companies have entire departments dedicated to this feat.
Some other personal server products aimed at non-technical individuals tackle this problem by simply hard coding dependencies. Since EmbassyOS is a platform for running all open-source, self-hosted software, it is not possible to hard code every possible service, service dependency, and service dependency configuration forever. Instead, Start9 built a new, unprecedented operating system that touts a generalized, intuitive approach to dependency management and service configuration. EmbassyOS enables users to easily and selectively install, uninstall, and update any service they want without getting stuck in dependency hell.
This may sound cool or neat, but it is more than that: *it’s novel*. This has never been done before.
The key to making the system work is a new, domain-specific-language (DSL) and set of standards that are used by developers to define the rules and requirements of their services. Run in the context of EmbassyOS, these rules and requirements appear as simple UI elements, such as inputs, toggles, and drop downs, and they are enforced by validations and clear user instructions. Using this system, what previously required involved time and expertise, can now be done by anyone in a matter of seconds.
This DSL is utilized in the :ref:`config rules <config_rules>` and :ref:`dependencies <dependencies>` key in the service manifest.
Manifest
--------
This file describes the service and its requirements. It is used to:
- create a listing in the marketplace
- denote any installation considerations
- define dependency requirements
Each time a service is updated, the manifest should be updated to include the new version, release notes, and any pertinent updates to the install, uninstall, or restoration flows. All this information is displayed in the marketplace listing, and the optionally denoted alerts will be displayed when appropriate to provide the user with more information about the particularities of the service.
For instance, `LND displays alerts <https://github.com/Start9Labs/lnd-wrapper/blob/master/manifest.yaml#L28>`_ around restoration since data will be overwritten.
There is nothing you need to do as a developer to enable the service to run over Tor. This is *completely* handled by EmbassyOS - a Tor address will be automatically generated and an Nginx server configured (if a client application) when the service is installed. Just define which version of Tor your service needs in this manifest file!
Config
------
Most self-hosted applications require the user to tell the app how to behave using a config file in a specific format, environment variables, command-line arguments, or some combination of these inputs. One of the coolest features of EmbassyOS is that, when packaged correctly, the app's :ref:`configuration <service_config>` will be available to the user as a slick GUI that always produces a valid configuration no matter how little experience or skill the user has.
With EmbassyOS, this means a service wrappers' configuration requires a particular format and rule structure to ensure it integrates smoothly with the user interface. This format enables clean handling of improper values and configuration dependencies.
.s9pk Bundle
------------
The configuration and manifest files get bundled into the ``.s9pk`` package, which is `built using appmgr <https://github.com/Start9Labs/embassy-os/tree/master/appmgr>`_. Each new version release should include the updated version of these files re-bundled into a new binary. This is the file that will be downloaded from the marketplace. Upon user initiation, EmbassyOS then un-packages and installs the service.
Hello World Example
-------------------
For reference, the `Hello world <https://github.com/Start9Labs/hello-world-wrapper>`_ repository should be used as an example. A project template can be cloned using the "Use this template" button in GitHub.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

25
source/dev-docs/service-packaging/properties.rst Normal file
View File

@@ -0,0 +1,25 @@
.. _service_properties:
******************
Service Properties
******************
The output of this step is a file titled ``stats.yaml``. This file contains a mapping of the values that will be displayed in the ``Properties`` section in a service's menu.
.. figure:: /_static/images/service/service_properties.png
:width: 80%
:alt: Service Properties
Service Properties Tab
Due to the fact that config variables are only available when the service is running, this file can only be populated at runtime. In services Start9 has wrapped or created, we typically handle this in ``configurator/src/main.rs``. This file is essentially a script that acquires the necessary values at runtime from config (eg. ``/root/.lnd/start9/config.yaml``), and dynamically populating them to the ``stats.yaml`` file, marking each value with the appropriate keys for UI display (ie. masked or copyable). Running the configurator is typically included in the ``docker_entrypoint.sh`` file.
Example
=======
A good example of the configurator producing the ``stats.yaml`` file can be found `here <https://github.com/Start9Labs/lnd-wrapper/blob/master/configurator/src/main.rs>`_.
.. role:: raw-html(raw)
:format: html
:raw-html:`<br />`

42
source/dev-docs/service-packaging/wrapper.rst Normal file
View File

@@ -0,0 +1,42 @@
.. _service_wrapper:
***************
Service Wrapper
***************
Each service is bound with a wrapper repository, which contains everything you need to build a service.
The purpose of this repo is:
- Denote any dependencies required to run and build the project
- To define the necessary, ``config_rules.yaml``, ``config_spec.yaml`` and ``manifest.yaml`` options
- To build the project into the ``.s9pk`` format digestible to EmbassyOS
- Link to the source project as a git submodule
- Define the docker file for running the project on EmbassyOS
- Provide documentation for the project, especially user runbook instructions
- symlink of ``instructions.md`` from ``docs`` directory to wrapper repo root, if included
File Structure
==============
The project structure should be used as a model:
.. code-block:: bash
├── Dockerfile
├── Makefile (optional)
├── README.md
├── config_rules.yaml
├── config_spec.yaml
├── <submodule_project_dir>
├── docker_entrypoint.sh
├── docs
│ └── instructions.md
└── manifest.yaml
Submodule
==========
`Git submodules <https://www.git-scm.com/book/en/v2/Git-Tools-Submodules>`_ allow use of another project while in the working project directory. Setting up this feature enables linking of the source service repository so that its context is available.
Run ``git submodule add <link_to_source_project>``

26
source/index.rst
View File

@@ -7,7 +7,8 @@ Welcome to the Start9 Docs!
Here you will find guidance and information about Embassy personal server and its operating system, EmbassyOS. If you identify an error with the docs or would like to contribute to them, please use the GitHub link at the top of this page.
EmbassyOS is designed to work out of the box with a minimal setup and immediate practicality. That being said, there are a great many different use-cases and utilities that can be added at your convenience. You can get started right away with Initial Setup <link>. In the `User Manual <link>`, you will find information on what EmbassyOS can do for you, as well as configuration and customization options. Use our Knowledgebase <link> to learn more about the technologies behind Embassy. When you're ready to build, please check out our `Developer Docs <link>`. Please don't hestitate to `Contact Us <link>` if you have any issues, questions, or suggestions that are not covered here.
EmbassyOS is designed to work out of the box with a minimal setup and immediate practicality. That being said, there are a great many different use-cases and utilities that can be added at your convenience. You can get started right away with `Initial Setup <link>`. In the `User Manual <link>`, you will find information on what EmbassyOS can do for you, as well as configuration and customization options. Use our `Knowledgebase <link>` to learn more about the technologies behind Embassy. When you're ready to build, please check out our `Developer Docs <link>`. Please don't hestitate to `Contact Us <link>` if you have any issues, questions, or suggestions that are not covered here.
Table of Contents
=================
@@ -16,29 +17,24 @@ Table of Contents
:maxdepth: 2
:caption: User Manual
- Introduction
- Purchasing
- Initial Setup
- Device-specific Setup Guides
user-manual/getting-started
user-manual/walkthrough
user-manual/getting-started/index
user-manual/walkthrough/index
user-manual/services
user-manual/configuration
user-manual/tuning
user-manual/troubleshooting
user-manual/configuration/index
user-manual/tuning/index
user-manual/troubleshooting/index
.. toctree::
:maxdepth: 2
:caption: Knowledgebase
knowledgebase/concepts
knowledgebase/faq
knowledgebase/concepts/index
knowledgebase/faq/index
.. toctree::
:maxdepth: 2
:caption: Developer Docs
dev-docs/service-packaging
dev-docs/service-packaging/index
dev-docs/packaging-example
dev-docs/dev-faq
dev-docs/dev-faq/index

5
source/knowledgebase/concepts/bitcoin-lightning.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _bitcoin-lightning:
*********************
Bitcoin and Lightning
*********************

5
source/knowledgebase/concepts/embassy-os.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _embassy-os:
*********
EmbassyOS
*********

15
source/knowledgebase/concepts/index.rst Normal file
View File

@@ -0,0 +1,15 @@
********
Concepts
********
An overview of EmbassyOS general capabilities.
.. toctree::
:maxdepth: 2
open-source
self-hosting
networks
bitcoin-lightning
start9
embassy-os

5
source/knowledgebase/concepts/networks.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _networks:
********
Networks
********

5
source/knowledgebase/concepts/open-source.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _open-source:
***********
Open Source
***********

5
source/knowledgebase/concepts/self-hosting.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _self-hosting:
****************
Hosting Software
****************

0
source/knowledgebase/concepts/start9.rst Normal file
View File

5
source/knowledgebase/faq/faq-basic-use.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _faq-basic-use:
*********
Basic Use
*********

5
source/knowledgebase/faq/faq-bitcoin.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _faq-bitcoin:
*******
Bitcoin
*******

5
source/knowledgebase/faq/faq-embassy.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _faq-embassy:
*******
Embassy
*******

115
source/knowledgebase/faq/faq-general.rst Normal file
View File

@@ -0,0 +1,115 @@
.. _faq-general:
*******
General
*******
What is Start9Labs?
-------------------
Start9Labs is a company based in Denver, CO that builds the Embassy and EmbassyOS.
What is the Embassy?
--------------------
The Embassy is a "shelf-top" computer built using a `Raspberry Pi <https://www.raspberrypi.org/products/raspberry-pi-4-model-b/>`_ for hardware and running EmbassyOS software.
The internet as we know it is organized into questioners, or clients, and answerers, or servers. When you open a mobile email app, say Gmail, the app (client) begins asking questions: "have I received new mail?", "what are my last 50 messages?", "what drafts am I in the midst of writing?", and so on. Your app's questions are sent to and heard by a Google-run server which then provides answers back to the client and are subsequently displayed to the screen.
The Embassy is exactly that: your very own "answerer", just like Google's, except managed simply and with ease by and for you alone.
In other words, it is a generalized private personal server capable of running all sorts of self hosted open source software.
When you see your credit card information on your banking app, your messages in your texting app, your passwords in your password management app, all of that information comes from somewhere in the cloud: some server run by some company somewhere on the planet. Who can see the data stored in that server? Who can edit it? It's not always clear, but the increasingly common practice of selling your data to advertisers and the high-profile cyber-security breaches of the last decade suggest a pessimistic outlook.
One thing is for certain though: if you control your server, then you control your data. Your finances, your communications, all of it is actually yours -- and only yours -- with an Embassy.
Why do I care?
--------------
As an example, let's talk about the password manager, Bitwarden. It may help convey the concept of a personal server. Currently, when you use Bitwarden, your passwords are stored on a physical device (aka server) owned and operated by the Bitwarden team. Your phone or laptop sends requests to their server when you want to do anything: create an account, create a new password, retrieve existing passwords, etc. Your passwords are stored on their device, encrypted with your Bitwarden password. They are the custodian of your passwords, similar to getting a safe deposit box at the bank. The bank keeps your valuables in their vault, presumably they don't know what's in the box, and any time you want access to your box, you ask the bank for permission. This is exactly how a hosted Bitwarden experience works, as well as just about everything on the internet. When you install Bitwarden on your Embassy, by contrast, it's like building your own safe deposit box in a private bunker whose location is only known to you and whose keys only you posses. You create an account with yourself, store your passwords with yourself, etc. You are your own custodian. This same concept can be applied to just about everything on the Internet, without losing the convenience of the custodial model, which is what we are out to accomplish. This may sound cool, or neat, but it is so much more than that. The custodial data model is amongst the greatest threats to human liberty the world has ever seen.
This `podcast <https://www.youtube.com/watch?v=aylDowaSdzU&t=270s>`_ may help expound upon why this is important.
How does the Embassy work?
--------------------------
The Embassy runs on the Raspberry Pi 4B hardware with a Cortex-a72 CPU, 4GB of RAM, and has 2.4ghz and 5.0ghz IEEE 802.11AC wireless capabilities and an internal speaker for audio feedback of system operations. It also features a high endurance MicroSD card, on which the operating system software is installed.
EmbassyOS is a stripped down version of Raspbian Buster Lite and handles all operations of your Embassy device. This core element of the technology stack is what enables you to set up, login, access your Embassy’s dashboard, and download and install services.
One of these operations is creating and managing Tor addresses, which are uniquely attributed to each service you download, as well as to the Embassy device itself. You can see your uniquely generated Tor address when you complete the setup process using the Setup App. This address is how you view your Embassy’s dashboard, which is actually just a website served up from your Embassy itself! It is authenticated, of course, so only you can access it.
You can connect to and manage your Embassy from any mobile device, desktop computer, or laptop computer. This is accomplished right through the browser by visiting your Embassy's private and unique URL.
Once on Embassy's web page, you can choose what services to install to the Embassy. Then, each installed service also receives its own private and unique URL, such that you can access it from the browser or any mobile app that supports using it as a backend.
The list of services will grow rapidly over the coming months, such that many things you currently do using cloud-based third party servers can be just as easily accomplished using your own personal cloud serving your own personal apps and storing your own private data. No trusted third parties at all.
What is EmbassyOS?
------------------
EmbassyOS is a new kind of Operating System (OS). It is built from the ground up to allow anyone to easily run their own ‘cloud,’ become independent from Big Tech, and own their own data. EmbassyOS allows anyone to easily self-host their own software services.
EmbassyOS is a custom-built Linux distribution, which is a stripped down and beefed up version of `Raspbian Buster Lite OS <https://www.raspberrypi.org/software/operating-systems/>`_, along with a suite of software tools which make it easy to:
* Install, uninstall, and upgrade services from the custom Marketplace (similar to your phone's app store)
* Manage and run services that YOU control
* Upgrade your Embassy software with the latest features and security updates
* Backup services, and restore from backups if needed
Start9 augmented the original Raspbian OS to include:
* a custom application management layer, specialized for installing, running, and backing up .s9pk packaged services
* a layer responsible for Embassy specific operations, such as Tor, Backups, and Notifications
The .s9pk extension is Start9's custom package format based on tar. It encompasses the necessary components to compress, host, and install a service on the marketplace.
What are EmbassyOS Services?
----------------------------
A Service can be any piece of software added to the Marketplace. All services are "self-hosted," meaning that you are in complete control of your data. This means you can run your own "cloud!" Learn more about managing services :ref:`here <managing-services>` and see our currently :ref:`Available Services <available-services>`.
Does the Embassy ship worldwide?
--------------------------------
No. We ship everywhere that DHL ships, with the unfortunate exception of Europe, where the VAT and Customs are so ridiculous that they cost as much as Embassy itself or more. Please consider buying your hardware locally, and purchasing EmbassyOS as a download from us instead.
Does the Embassy have international electrical plugs?
-----------------------------------------------------
Power supplies for EU, AU, US, and UK are available.
Is the power supply that comes with Embassy 220v compatible?
------------------------------------------------------------
Yes.
Is the software Open Source?
----------------------------
Yes! EmbassyOS is open sourced under the `Start9 Personal Use License <https://start9.com/license>`_. Some of our other projects are currently open sourced under MIT. You can find these in the Start9 `GitHub repository <https://github.com/Start9Labs>`_.
Is there a product warranty?
----------------------------
Yes! Start9 commits, to the best of our ability, to serving each beta Embassy product released into the wild. We will resolve any issue encountered with our provided hardware or software in a personalized matter. We strive to provide highly available, quality customer service.
Can you tell me about the License?
----------------------------------
EmbassyOS is published under our own Start9 Non-Commercial License, which has similar properties to many open source licenses with the exception that users cannot in any way, either through products or services, commercialize the source code, and any changes to the code or derivative works of the code are treated in the same manner. This means people will be welcome to access the source code, download it, use it, run it, fork it, change it, improve it - whatever they want - except sell it or sell services related to it.
What kind of Internet connection is required to use Embassy?
------------------------------------------------------------
In general, any modern Internet connection is usually fine. We have had reports from users on rural satellite connections with high latency (ping), and low up/download speeds who had issues accessing via Tor. You can check your internet connection at `SpeedTest <https://speedtest.net>`_ to find your ping and speed. If your ping is higher than 200ms and/or your speeds are lower than 5Mbps, you may want to host your Embassy somewhere with a better connection. Please don't hesitate to contact us with any questions.
I run a business, can I use an Embassy for tasks such as password management and file sharing?
----------------------------------------------------------------------------------------------
Absolutely. An Embassy would be a great addition to any business as it is easy to use and provides services that you control, with no subscription fees.
With the addition of `BTCPay Server <https://btcpayserver.org/>`_, you can even run your own payment processor and accept cryptocurrency payments with no third party necessary!
What are you using for a store backend? Do you store my data?
--------------------------------------------------------------
Here is our exact situation currently:
Embassy device sales are processed through Shopify, which we do not like, but it was expedient in the early days, especially for shipping, so we went with it. Aside from a master list of email addresses for those who have explicitly opted in to our mailing list, all customer data is contained within Shopify. We do not duplicate it anywhere. We are asking Shopify to delete our customer data, but they claim it will take upward of 3 months to comply and we of course have no guarantee the data will actually be deleted permanently. This is partly why we exist...as such, we will be moving off of Shopify and onto a self-hosted solution, where Start9 alone controls our customer data for Embassy purchases, which we will delete as a matter of policy following a short grace period after delivery.
For EmbassyOS sales, we took the maximally private approach right out of the gate. When you buy EmbassyOS, the only thing we need is an email address, and you can only pay with bitcoin. That's it. Then, unless you have explicitly requested that we keep your email for mailing list purposes, we delete the email immediately upon transaction completion.
So...in summary: (1) the shipping data we currently have is stored in Shopify (2) we are asking Shopify to delete all our customer data (3) we will be migrating off of Shopify (4) going forward, we alone will control customer data and will purge it regularly (5) you can always assemble the hardware yourself and just buy EmbassyOS from us with bitcoin, which only requires an email, which is gets purged immediately.
I want to help, but I'm not a developer. Are there any ways for non-coders to contribute?
------------------------------------------------------------------------------------------
1. Shill it to everyone and create awareness
2. Answer questions from new users in the community channels
3. Make tutorial videos
4. Write instruction manuals or commit to the docs

5
source/knowledgebase/faq/faq-lightning.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _faq-lightning:
*********************
The Lightning Network
*********************

5
source/knowledgebase/faq/faq-services.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _faq-services:
********
Services
********

15
source/knowledgebase/faq/index.rst Normal file
View File

@@ -0,0 +1,15 @@
***
FAQ
***
An overview of EmbassyOS general capabilities.
.. toctree::
:maxdepth: 2
faq-general
faq-basic-use
faq-embassy
faq-services
faq-bitcoin
faq-lightning

5
source/user-manual/configuration/basic-config.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _basic-config:
*******************
Basic Configuration
*******************

13
source/user-manual/configuration/index.rst Normal file
View File

@@ -0,0 +1,13 @@
*************
Configuration
*************
An overview of EmbassyOS general capabilities.
.. toctree::
:maxdepth: 2
basic-config
tor-setup/index
lan-setup/index
limitations/index

5
source/user-manual/configuration/lan-setup/android.rst Normal file
View File

@@ -0,0 +1,5 @@
.. android:
*******
Android
*******

19
source/user-manual/configuration/lan-setup/index.rst Normal file
View File

@@ -0,0 +1,19 @@
.. _lan-setup:
************
Local Access
************
.. warning::
This guide assumes you are already :ref:`running Tor on your phone or computer<running-tor>`.
Once you have completed the above guide, select your device's operating system below:
.. toctree::
:maxdepth: 2
linux
mac
windows
android
ios

5
source/user-manual/configuration/lan-setup/ios.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _iOS:
***
iOS
***

5
source/user-manual/configuration/lan-setup/linux.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _linux:
*****
Linux
*****

5
source/user-manual/configuration/lan-setup/mac.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _mac:
***
Mac
***

5
source/user-manual/configuration/lan-setup/windows.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _windows:
*******
Windows
*******

5
source/user-manual/configuration/limitations/android.rst Normal file
View File

@@ -0,0 +1,5 @@
.. android:
*******
Android
*******

19
source/user-manual/configuration/limitations/index.rst Normal file
View File

@@ -0,0 +1,19 @@
.. _limitations:
*****************
Known Limitations
*****************
.. warning::
This guide assumes you are already :ref:`running Tor on your phone or computer<running-tor>`.
Once you have completed the above guide, select your device's operating system below:
.. toctree::
:maxdepth: 2
linux
mac
windows
android
ios

5
source/user-manual/configuration/limitations/ios.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _iOS:
***
iOS
***

5
source/user-manual/configuration/limitations/linux.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _linux:
*****
Linux
*****

5
source/user-manual/configuration/limitations/mac.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _mac:
***
Mac
***

5
source/user-manual/configuration/limitations/windows.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _windows:
*******
Windows
*******

12
source/user-manual/configuration/tor-setup/index.rst Normal file
View File

@@ -0,0 +1,12 @@
*********
Tor Setup
*********
An overview of EmbassyOS general capabilities.
.. toctree::
:maxdepth: 2
lan-setup/index
tor-os/index
tor-firefox/index

5
source/user-manual/configuration/tor-setup/tor-firefox/android.rst Normal file
View File

@@ -0,0 +1,5 @@
.. android:
*******
Android
*******

19
source/user-manual/configuration/tor-setup/tor-firefox/index.rst Normal file
View File

@@ -0,0 +1,19 @@
.. _tor-firefox:
********************
Using Tor on Firefox
********************
.. warning::
This guide assumes you are already :ref:`running Tor on your phone or computer<running-tor>`.
Once you have completed the above guide, select your device's operating system below:
.. toctree::
:maxdepth: 2
linux
mac
windows
android
ios

5
source/user-manual/configuration/tor-setup/tor-firefox/ios.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _iOS:
***
iOS
***

5
source/user-manual/configuration/tor-setup/tor-firefox/linux.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _linux:
*****
Linux
*****

5
source/user-manual/configuration/tor-setup/tor-firefox/mac.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _mac:
***
Mac
***

5
source/user-manual/configuration/tor-setup/tor-firefox/windows.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _windows:
*******
Windows
*******

5
source/user-manual/configuration/tor-setup/tor-os/android.rst Normal file
View File

@@ -0,0 +1,5 @@
.. android:
*******
Android
*******

19
source/user-manual/configuration/tor-setup/tor-os/index.rst Normal file
View File

@@ -0,0 +1,19 @@
.. _tor-os:
******************
Using Tor Natively
******************
.. warning::
This guide assumes you are already :ref:`running Tor on your phone or computer<running-tor>`.
Once you have completed the above guide, select your device's operating system below:
.. toctree::
:maxdepth: 2
linux
mac
windows
android
ios

5
source/user-manual/configuration/tor-setup/tor-os/ios.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _iOS:
***
iOS
***

5
source/user-manual/configuration/tor-setup/tor-os/linux.rst Normal file
View File

@@ -0,0 +1,5 @@
.. _linux:
*****
Linux
*****

Some files were not shown because too many files have changed in this diff Show More