More typos

source/contributing/services/config.rst

@@ -17,9 +17,9 @@ The outcome of this step is two files:
 
 :ref:`config_rules.yaml <config_rules>`
 
-These files contain a detailed mapping of configuration options with acceptable values, defaults and relational rule-sets. 
+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. 
+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:
 
@@ -84,7 +84,7 @@ The following section contains implementation specifications for the ``config_sp
     :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
+- 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
@@ -152,8 +152,8 @@ ValueSpec Type:
 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 be have a default. If no default is provided, ``null`` will be the assumed value.
+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 ``*``:
 
@@ -171,7 +171,7 @@ eg:
 
 ValueSpec Type:
 
-.. code:: 
+.. code::
 
     type: list
     name: String
@@ -237,7 +237,7 @@ Example:
 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. 
+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.
 
@@ -379,7 +379,7 @@ ValueSpec Type:
     target: AppPointerSpecVariants | SystemPointerSpecVariants
     index: Option<String> (dependent on target being AppPointerSpecVariants)
 
-    AppPointerSpecVariants = LanAddress | TorAddress | TorKey | Config 
+    AppPointerSpecVariants = LanAddress | TorAddress | TorKey | Config
     SystemPointerSpecVariants = HostIp
 
 Example:
@@ -403,7 +403,7 @@ This type describes a necessary dependency. Multiple variants can be expressed t
 
 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. 
+Default is required and corresponds to one of the variants.
 
 ``Tag`` is the key that will be rendered on the UI element.
 
@@ -508,7 +508,7 @@ Example:
 Config Rules
 ============
 
-This file defines the configuration rules, or the rule-set that defines dependencies between config variables. 
+This file defines the configuration rules, or the rule-set that defines dependencies between config variables.
 
 A rule is a boolean expression that we demand to be true. It is not true if the expression fails the rule parser.
 
@@ -519,22 +519,22 @@ 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. 
+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. 
+- ``#`` - 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.
 
 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 
+    - ``Set`` - set the value
 
     - ``Push`` - add to the value (such as to a list)
 
     - ``Delete`` - delete the value
 
-.. code:: typescript 
+.. code:: typescript
 
     enum SuggestionVariant = Set | Delete | Push
 
@@ -589,7 +589,7 @@ Push Examples:
         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>`_: 
+Full example from `c-lightning manifest <https://github.com/Start9Labs/c-lightning-wrapper/blob/master/manifest.yaml>`_:
 
 .. code:: yaml
 
@@ -611,4 +611,4 @@ Full example from `c-lightning manifest <https://github.com/Start9Labs/c-lightni
 .. role:: raw-html(raw)
     :format: html
 
-:raw-html:`<br />`
+:raw-html:`<br />`

source/contributing/services/makefile.rst

@@ -5,7 +5,7 @@ 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.
@@ -15,9 +15,9 @@ An alternative to using ``make`` is to use the `nix <https://nixos.wiki/wiki/Nix
 This purpose of this file is to:
 
 - Read the docker container and build the project
-- Build all prerequisite 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``. 
+- 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
 =======
@@ -27,4 +27,4 @@ The `LND wrapper <https://github.com/Start9Labs/lnd-wrapper/blob/master/Makefile
 .. role:: raw-html(raw)
     :format: html
 
-:raw-html:`<br />`
+:raw-html:`<br />`

source/contributing/services/overview.rst

@@ -4,7 +4,7 @@
 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. 
+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.
 
@@ -36,15 +36,15 @@ 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. 
+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 a 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.
+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. 
+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. 
+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>``.
 
@@ -54,7 +54,7 @@ The volume directory (for seeding data into the volume) is typically: ``/root/vo
 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. 
+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.
 
@@ -75,7 +75,7 @@ This file describes the service and it's requirements. It is used to:
 
 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. 
+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!
 
@@ -100,4 +100,4 @@ For reference, the `Hello world <https://github.com/Start9Labs/hello-world-wrapp
 .. role:: raw-html(raw)
     :format: html
 
-:raw-html:`<br />`
+:raw-html:`<br />`