neil/silverbullet
1
0
Fork 0
Code

Fix web typos (#600)

Browse Source
This commit is contained in:
Jim Tittsler 2023-12-16 02:58:12 +09:00 committed by GitHub
parent 9f082c83a9
commit 3d87f7a25b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 28 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
website/CHANGELOG.md
View File

@ -4,11 +4,11 @@ release.
--- ---
## Next ## 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. * 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 * 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: * 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 * 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 * [[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. * 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) * Upgraded set of emoji (completed via the :thinking_face: syntax) to 15.1 (so more emoji)
* Various bug fixes * Various bug fixes

24
website/Install/Configuration.md
View File

@ -9,30 +9,30 @@ $network
# Run mode # Run mode
$runmode $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
$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
$authentication $authentication
SilverBullet supports basic authentication for a single user. 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_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
$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 ## 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 ## 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. 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.
@ -67,16 +67,16 @@ This mode is configured as follows:
# Database # Database
$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]] * 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 ## 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: KV can be configured as follows:

6
website/Install/Deno Deploy.md
View File

@ -1,16 +1,16 @@
> **warning** Experimental > **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). 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 # Steps
Sign up for a (free) [Deno Deploy account](https://dash.deno.com/projects) and “Create an empty project” there. 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_FOLDER`: `db://`
* `SB_PORT`: `8000` * `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_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). * `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).

4
website/Sync.md
View File

@ -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 # 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. * **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. 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`): To synchronize two local folders (named `testspace1` and `testspace2`) (not particularly useful, you may as well use `cp` or `rsync`):