Merge branch 'main' of github.com:silverbulletmd/silverbullet

website/Authelia.md

@@ -1,4 +1,4 @@
-How to setup SilverBullet with Authelia
+How to set up SilverBullet with Authelia
 
 For SilverBullet to work as intended, some files will need to be excluded from your authentication method of choice. These files always need to be accessible, for example for offline or [[PWA]] support.
 

website/CHANGELOG.md

@@ -4,11 +4,11 @@ release.
 ---
 
 ## Next
-* Removed built-in multi-user [[Authentication]], `SB_AUTH` is no longer supported, use `--user` or `SB_USER` instead, or an authentication layer such as [[Authelia]].
+* Removed built-in multi-user [[Authentication]], `SB_AUTH` is no longer supported; use `--user` or `SB_USER` instead or an authentication layer such as [[Authelia]].
-* Work on supporting multiple database as well as storage back-ends, reviving [[Install/Deno Deploy]] support.
+* Work on supporting multiple database and storage backends, reviving [[Install/Deno Deploy]] support.
-* This is now documented on the brand new [[Install/Configuration]] page.
+* This is now documented on the brand-new [[Install/Configuration]] page.
 * A new `silverbullet sync` command to [[Sync]] spaces.
-* Technical refactoring in preparation of multi-tenant deployment support (allowing you to run a single SB instance and serve multiple spaces and users at the same time)
+* Technical refactoring in preparation for multi-tenant deployment support (allowing you to run a single SB instance and serve multiple spaces and users at the same time)
   * Lazy everything: plugs are now lazily loaded (after a first load,  manifests are cached). On the server side, a whole lot of infrastructure is now only booted once the first HTTP request comes in
 
 ---
@@ -23,10 +23,10 @@ release.
 * General support for highlighting errors (underlined) in the editor. Currently implemented for:
   * All YAML fenced code blocks (and [[Frontmatter]]): will now highlight YAML parse errors
   * [[Live Queries]]: will highlight non-existing query sources and non-existing template references in `render` clauses
-* Basic [[Table of Contents]] support: any page _with 3 headers or more_, now has a “Table of Contents” widget appear (see this very page). You can toggle this feature using the {[Table of Contents: Toggle]} command.
+* Basic [[Table of Contents]] support: any page _with 3 headers or more_ now has a “Table of Contents” widget appear (see this very page). You can toggle this feature using the {[Table of Contents: Toggle]} command.
 * Tapping/clicking the top bar (outside of the page name and action buttons) now scrolls your page to the very top.
-* Slightly more gracious error reporting on load, when using the Online [[Client Modes]] and the server is offline.
+* Slightly more gracious error reporting on load when using the Online [[Client Modes]] and the server is offline.
-* Any page tagged with `#template` is no longer indexed (beside as a `template`)
+* Any page tagged with `#template` is no longer indexed (besides as a `template`)
 * Upgraded set of emoji (completed via the :thinking_face: syntax) to 15.1 (so more emoji)
 * Various bug fixes
 

website/Install/Configuration.md

@@ -9,35 +9,35 @@ $network
 # Run mode
 $runmode
 
-* `SB_SYNC_ONLY`: If you want to run SilverBullet in a mode where the server purely functions as a simple file store, and doesn’t index or process content on the server, you can do so by setting this environment variable to `true`. As a result, the client will always run in the Sync [[Client Modes|client mode]].
+* `SB_SYNC_ONLY`: If you want to run SilverBullet in a mode where the server purely functions as a simple file store and doesn’t index or process content on the server, you can do so by setting this environment variable to `true`. As a result, the client will always run in the Sync [[Client Modes|client mode]].
 
 # Security
 $security
 
-SilverBullet enables plugs to run shell commands. This is used by e.g. the [[🔌 Git]] plug to perform git commands. This is potentially unsafe. If you don’t need this you can disable this functionality:
+SilverBullet enables plugs to run shell commands. This is used by e.g. the [[🔌 Git]] plug to perform git commands. This is potentially unsafe. If you don’t need this, you can disable this functionality:
 
-* `SB_SHELL_BACKEND`: Enable/disable running of shell commands from plugs, defaults to `local` (enabled), set to `off` to disable. Only enabled when using a local folder for [[$storage]].
+* `SB_SHELL_BACKEND`: Enable/disable running of shell commands from plugs, defaults to `local` (enabled), set to `off` to disable. It is only enabled when using a local folder for [[$storage]].
 
 # Authentication
 $authentication
 SilverBullet supports basic authentication for a single user.
 
 * `SB_USER`: Sets single-user credentials, e.g. `SB_USER=pete:1234` allows you to login with username “pete” and password “1234”.
-* `SB_AUTH_TOKEN`: Enables `Authorization: Bearer <token>` style authentication on the [[API]] (useful for [[Sync]] and remote HTTP storage back-ends).
+* `SB_AUTH_TOKEN`: Enables `Authorization: Bearer <token>` style authentication on the [[API]] (useful for [[Sync]] and remote HTTP storage backends).
 
 # Storage
 $storage
-SilverBullet support multiple storage back-ends for keeping your [[Space]] content.
+SilverBullet supports multiple storage backends for keeping your [[Space]] content.
 
 ## Disk storage
-This is default and simplest back-end to use: a folder on disk. It is configured as follows:
+This is the default and simplest backend to use: a folder on disk. It is configured as follows:
 
-* `SB_FOLDER`: Sets the folder to expose. In the docker container this defaults to `/space`.
+* `SB_FOLDER`: Sets the folder to expose. In the docker container, this defaults to `/space`.
 
 ## AWS S3 bucket storage
 It is also possible to use an S3 bucket as storage. For this, you need to create a bucket, create an IAM user and configure access to it appropriately.
 
-Since S3 doesn’t support an efficient way to store custom meta data, this mode does require a [[$database]] configuration (see below) to keep all file meta data.
+Since S3 doesn’t support an efficient way to store custom metadata, this mode does require a [[$database]] configuration (see below) to keep all file metadata.
 
 S3 is configured as follows:
 
@@ -49,7 +49,7 @@ S3 is configured as follows:
 * `AWS_REGION`: e.g. `eu-central-1`
 
 ## Database storage
-It is also possible to store space content in the [[$database]]. While not necessarily recommended, it is a viable way to setup a simple deployment of SilverBullet on e.g. [[Install/Deno Deploy]]. Large files will automatically be chunked to avoid limits the used database may have on value size.
+It is also possible to store space content in the [[$database]]. While not necessarily recommended, it is a viable way to set up a simple deployment of SilverBullet on e.g. [[Install/Deno Deploy]]. Large files will automatically be chunked to avoid limits the used database may have on value size.
 
 This mode is configured as follows:
 
@@ -67,16 +67,16 @@ This mode is configured as follows:
 
 # Database
 $database
-SilverBullet requires a database back-end to (potentially) keep various types of data:
+SilverBullet requires a database backend to (potentially) keep various types of data:
 
 * Indexes for e.g. [[Objects]]
-* Storing some encryption related secrets (for [[Authentication]])
+* Storing some encryption-related secrets (for [[Authentication]])
-* Space content, when the “Database storage” storage back-end is used
+* Space content, when the “Database storage” storage backend is used
 
-Currently only two databases are supported: [Deno KV](https://deno.com/kv), and a dummy in-memory database.
+Currently, only two databases are supported: [Deno KV](https://deno.com/kv) and a dummy in-memory database.
 
 ## Deno KV database
-When self-hosting SilverBullet (that is: on any other server than on [[Install/Deno Deploy]]), KV uses a local SQLite file to keep data. This efficient and performant.
+When self-hosting SilverBullet (that is, on any server other than on [[Install/Deno Deploy]]), KV uses a local SQLite file to keep data. This is efficient and performant.
 
 KV can be configured as follows:
 

website/Install/Deno Deploy.md

@@ -1,16 +1,16 @@
 > **warning** Experimental
-> This setup is not battle tested, use at your own risk
+> This setup is not battle-tested, use it at your own risk
 
 You can deploy SilverBullet to [Deno Deploy](https://deno.com/deploy) for free, and store space content in [Deno KV](https://deno.com/kv).
 
 # Steps
 Sign up for a (free) [Deno Deploy account](https://dash.deno.com/projects) and “Create an empty project” there.
 
-Jump to the “Settings”, give your project a nicer name and configure the following environment variables:
+Jump to the “Settings”, give your project a nicer name, and configure the following environment variables:
 
 * `SB_FOLDER`: `db://`
 * `SB_PORT`: `8000`
-* `SB_SYNC_ONLY`: `1` (Deno Deploy does not currently supports Workers, so running indexing etc. on the server will not work)
+* `SB_SYNC_ONLY`: `1` (Deno Deploy does not currently support Workers, so running indexing etc. on the server will not work)
 * `SB_USER`: (e.g. `pete:letmein`) — this is **super important** otherwise your space will be open to anybody without any authentication
 * `SB_AUTH_TOKEN`: (Optional) If you would like to migrate existing content from elsewhere (e.g. a local folder) using [[Sync]], you will want to configure an authentication token here (pick something secure).
 

website/Sync.md

@@ -1,4 +1,4 @@
-The SilverBullet CLI has a `sync` command that can be used to synchronize local as well as remote [[Space|spaces]]. This can be useful when migrating between different [[Install/Configuration$storage|storage implementations]]. It can also be used to back up content elsewhere. Under the hood this sync mechanism uses the exact same sync engine used for the Sync [[Client Modes]].
+The SilverBullet CLI has a `sync` command that can be used to synchronize local as well as remote [[Space|spaces]]. This can be useful when migrating between different [[Install/Configuration$storage|storage implementations]]. It can also be used to back up content elsewhere. Under the hood, this sync mechanism uses the exact same sync engine used for the Sync [[Client Modes]].
 
 # Use cases
 * **Migration**: you hosted SilverBullet on your local device until now, but have since set up an instance via [[Install/Deno Deploy]] and want to migrate your content there.
@@ -16,7 +16,7 @@ silverbullet sync --snapshot snapshot.json <primaryPath> <secondaryPath>
 
 Where both `primaryPath` and `secondaryPath` can use any [[Install/Configuration$storage]] configuration.
 
-The `--snapshot` argument is optional, when set it will read/write a snapshot to the given location. This snapshot will be used to speed up future synchronizations.
+The `--snapshot` argument is optional; when set, it will read/write a snapshot to the given location. This snapshot will be used to speed up future synchronizations.
 
 To synchronize two local folders (named `testspace1` and `testspace2`) (not particularly useful, you may as well use `cp` or `rsync`):
 
@@ -38,4 +38,4 @@ SB_AUTH_TOKEN=1234 silverbullet sync --wipe-secondary . https://notes.myserver.c
 ```
 
 # Backup
-To perform a backup, you may simply run the `sync` commands mentioned above regularly. Be sure to always specify the `--snapshot` flag in this case, and be sure to actually backup your local copy, e.g. using git.
+To perform a backup, you may simply run the `sync` commands mentioned above regularly. Be sure to always specify the `--snapshot` flag in this case, and be sure to actually back up your local copy, e.g. using git.