chore: typos
This commit is contained in:
committed by
Greg Heartsfield
parent
087b68128f
commit
06fcaad9a1
@@ -10,7 +10,7 @@ and reduce spam and abuse.
|
||||
|
||||
This will likely evolve substantially, the first goal is to get a
|
||||
basic one-way service that lets an externalized program decide on
|
||||
event persistance. This does not represent the final state of gRPC
|
||||
event persistence. This does not represent the final state of gRPC
|
||||
extensibility in `nostr-rs-relay`.
|
||||
|
||||
## Considerations
|
||||
|
||||
@@ -33,7 +33,7 @@ The LNBits instance must have a signed HTTPS a self signed certificate will not
|
||||
|
||||
### Concepts
|
||||
|
||||
All authors are initially not admitted to write to the relay. There are two ways to gain access write to the relay. The first is by attempting to post the the relay, upon receiving an event from an author that is not admitted, the relay will send a direct message including the terms of service of the relay and a lighting invoice for the admission cost. Once this invoice is payed the author can write to the relay. For this method to work the author must be reading from the relay. An author can also pay and accept the terms of service via a webpage `https://<relay-url>/join`.
|
||||
All authors are initially not admitted to write to the relay. There are two ways to gain access write to the relay. The first is by attempting to post the the relay, upon receiving an event from an author that is not admitted, the relay will send a direct message including the terms of service of the relay and a lighting invoice for the admission cost. Once this invoice is paid the author can write to the relay. For this method to work the author must be reading from the relay. An author can also pay and accept the terms of service via a webpage `https://<relay-url>/join`.
|
||||
|
||||
## Design Details
|
||||
|
||||
|
||||
@@ -117,9 +117,9 @@ Assumptions:
|
||||
|
||||
* `Traefik` version is `2.9` (other versions not tested).
|
||||
* `Traefik` is used for provisioning of Let's Encrypt certificates.
|
||||
* `Traefik` is running in `Docker`, using `docker compose` and labels for the static configuration. An equivalent setup useing a Traefik config file is possible too (but not covered here).
|
||||
* `Traefik` is running in `Docker`, using `docker compose` and labels for the static configuration. An equivalent setup using a Traefik config file is possible too (but not covered here).
|
||||
* Strict Transport Security is enabled.
|
||||
* Hostname for the relay is `relay.example.com`, email adres for ACME certificates provider is `name@example.com`.
|
||||
* Hostname for the relay is `relay.example.com`, email address for ACME certificates provider is `name@example.com`.
|
||||
* ipv6 is enabled, a viable private ipv6 subnet is specified in the example below.
|
||||
* Relay is running on port `8080`.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Start by building the application from source. Here is how to do that:
|
||||
3. `cargo build --release`
|
||||
|
||||
### Place the files where they belong
|
||||
We want to palce the nostr-rs-relay binary and the config.toml file where they belong. While still in the root level of the nostr-rs-relay folder you cloned in last step, run the following commands:
|
||||
We want to place the nostr-rs-relay binary and the config.toml file where they belong. While still in the root level of the nostr-rs-relay folder you cloned in last step, run the following commands:
|
||||
1. `sudo cp target/release/nostr-rs-relay /usr/local/bin/`
|
||||
2. `sudo mkdir /etc/nostr-rs-relay`
|
||||
2. `sudo cp config.toml /etc/nostr-rs-relay`
|
||||
|
||||
@@ -179,7 +179,7 @@ attempts to persist them to disk. Once validated and persisted, these
|
||||
events are broadcast to all subscribers.
|
||||
|
||||
When verification is enabled, the writer must check to ensure a valid,
|
||||
unexpired verification record exists for the auther. All metadata
|
||||
unexpired verification record exists for the author. All metadata
|
||||
events (regardless of verification status) are forwarded to a verifier
|
||||
module. If the verifier determines a new verification record is
|
||||
needed, it is also responsible for persisting and broadcasting the
|
||||
|
||||
Reference in New Issue
Block a user