Right, this repo is a strfry plugin. The way nostr1.com works is there is a NextJS application that serves the management UI and the API using nostr login + JWT tokens for authentication. LNbits for lightning invoices.

There are two agents that watch the API for new relays to deploy. The stack it uses for the relays is based on wildcard DNS, with a wildcard SSL certificate pointing to an A record (or multiple A records), and each machine runs haproxy and strfry(s). When the agents see a new relay has been requested, they configure haproxy, and configure a new strfry instance inside a systemd-nspawn container.

The relay uses the spamblaster plugin which is in contact with the API about what filtering rules and settings to use. It stays up to date by polling and applies the changes on the fly. In the future it will have a websocket connection listening for changes instead of polling. The other option with this plugin is that if you want to run the relay yourself, you can do so, and use the management interface just to manage it's settings vs. nostr1.com deploying it for you.

I wanted the project to remain cloud-free and I wanted it to be as efficient with server resources as possible. So there is no lock-in and no additional dependencies. The full stack can run on any linux machine with systemd-nspawn containers.

Reply to this note

Please Login to reply.

Discussion

No replies yet.