Skip to content

Latest commit

 

History

History
100 lines (65 loc) · 3.66 KB

README.md

File metadata and controls

100 lines (65 loc) · 3.66 KB

blastr

A nostr cloudflare workers proxy relay that publishes to all known online relays.

blastr diagram

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.

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:

# 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 project README.