Files
blastr/README.md
Tony Giorgio 71dc2becac Staging
2023-06-16 12:00:44 -05:00

101 lines
3.7 KiB
Markdown

# blastr
A nostr cloudflare workers proxy relay that publishes to all known online relays.
![blastr diagram](./docs/images/blastr-diagram.png)
This takes advantage of the high availabilty of cloudflare serverless workers on the edge that are rust wasm-based with 0ms cold starts. Learn more about [cloudflare workers](https://workers.cloudflare.com/).
This is write only for now and is compatible with nostr clients but also features a simple POST api endpoint at `/event`. All events get queued up to run in batches by another worker that spins up every 30s if there's any events lined up, or once a certain amount of events are queued up.
This will help ensure that your events are broadcasted to as many places as possible.
## Development
With `wrangler`, you can build, test, and deploy your Worker with the following commands:
```sh
# install wrangler if you do not have it yet
$ npm install -g wrangler
# log into cloudflare if you havent before
$ wrangler login
# compiles your project to WebAssembly and will warn of any issues
$ npm run build
# run your Worker in an ideal development workflow (with a local server, file watcher & more)
$ npm run dev
# deploy your Worker globally to the Cloudflare network (update your wrangler.toml file for configuration)
$ npm run deploy
```
## Staging
Production deployments happen automatically but staging is manually for now. Deploy whenever you need to test changes before merging to master.
```
wrangler publish --env staging
```
### Setup
There's a few cloudflare components that Blastr uses behind the scenes, namely a KV store and multiple queues to distribute the load.
Right now some of these are hardcoded for us since they have to map from the `wrangler.toml` file to the rust codebase. Need a TODO for making this more dynamic.
#### KV store
This doesn't rebroadcast events that have already been broadcasted before. So we have a KV for that.
We also have a KV for storing the NWC requests and responses to get around ephemeral events.
```
wrangler kv:namespace create PUBLISHED_NOTES
wrangler kv:namespace create PUBLISHED_NOTES --preview
wrangler kv:namespace create NWC_REQUESTS
wrangler kv:namespace create NWC_REQUESTS --preview
wrangler kv:namespace create NWC_RESPONSES
wrangler kv:namespace create NWC_RESPONSES --preview
```
#### Queues
```
wrangler queues create nostr-events-pub-1-b
wrangler queues create nostr-events-pub-2-b
wrangler queues create nostr-events-pub-3-b
wrangler queues create nostr-events-pub-4-b
wrangler queues create nostr-events-pub-5-b
wrangler queues create nostr-events-pub-6-b
wrangler queues create nostr-events-pub-7-b
wrangler queues create nostr-events-pub-8-b
wrangler queues create nostr-events-pub-9-b
wrangler queues create nostr-events-pub-10-b
```
Read the latest `worker` crate documentation here: https://docs.rs/worker
### CICD
There's an example workflow here for publishing on master branch pushes. You need to set `CF_API_TOKEN` in your github repo secrets first.
You also should either remove or configure `wrangler.toml` to point to a custom domain of yours:
```
routes = [
{ pattern = "example.com/about", zone_id = "<YOUR_ZONE_ID>" } # replace with your info
]
```
and any other info in `wrangler.toml` that is custom to you, like the names / id's of queues or kv's.
### WebAssembly
`workers-rs` (the Rust SDK for Cloudflare Workers used in this template) is meant to be executed as compiled WebAssembly, and as such so **must** all the code you write and depend upon. All crates and modules used in Rust-based Workers projects have to compile to the `wasm32-unknown-unknown` triple.
Read more about this on the [`workers-rs`](https://github.com/cloudflare/workers-rs) project README.