Problem: paid relays are difficult to run

Nostr is increasingly relying on paid relays, but they are expensive to run and difficult to scale.

The skill set required to manage paid relays is considerably diverse, covering many differing fields of expertise.

The work of relay operators is often duplicated by other operators, making the overall economics less efficient than it could be.

The risk of doing all of this needs to be taken by a single person, and the only real way to spread this risk out at the moment is to create some kind of centrally planned business structure.

### Possible Solution:

Deploy a Rocket to manage a set of paid relays.

Separate out the different skills involved in running a paid relay such that there are more people available because the required skill set is narrower.

Developers can focus on incrementally solving problems to improve the relay software.

Devops guys can focus on devops stuff.

Frontend guys can focus on making it easy for users to subscribe.

Everyone who's solving problems in the critical path becomes a merit holder, as is standard behaviour under the nostrocket protocol.

Payment for subscribing to the paid relay set goes directly to merit holders in proportion to their merits, as is standard under the non-custodial nostrocket protocol.

### How this might work

This would start with a single relay, deployed by this Rocket's first contributor.

Problem: there is no relay deployed under this Rocket.

Solution: first contributor deploys an instance of the Rocket's relay (probably just nostr-rs-relay with a grpc management layer).

The relay subscribes to the Nostrocket state to get a list of allowed pubkeys (people who have paid this "relay" Rocket).

The first contributor submits a merit requests for the cost of the VPS and his time (and approves it himself).

When there's a problem that falls outside of his domain of expertise or outside his time constraints (e.g. perhaps something to do with the relay implementation), he logs a problem in the relay Rocket's branch of the problem tracker.

If he was fair and reasonable with his first merit request, then perhaps someone with the required skill set will send a patch to resolve the problem, and then submit a merit request for this. If the first contributor approves the solution, this second contributor now has merits to vote on subsequent merit requests. By definition, both parties completely agree that the number of merits each now holds are in direct proportion to the value of the work they did to contribute to this paid relay rocket.

When users pay to join the relay, the payments round-robin between these two merit holders, weighted by the percentage of merits they hold. This makes payments to the set of merit holders non-custodial and eventually-consisitent with the "cap table" of this rocket. This is standard behaviour for all payments for products/services created through Nostrocket.

Now when there's a problem that is in neither of these two contributors field of expertise, perhaps someone else will contribute. And the process continues.

If there's a problem with spam, this probably something that can be improved upon with a patch from a developer.

If users are having trouble subscribing because the web interface sux, a frontend guy can solve that with a patch.

### Architecture of the relay set

The architecture of the relay set would probably be something like this:

Relays forward all incoming events that they haven't seen before to all the other relays in the set, so that new events can then be seen on any relay in the set.

Paid users only need to connect to a single relay in the set.

They should connect to whichever one is fastest for them. Would be pretty easy to make a simple PWA to find the fastest one.

If there are not enough relay deployments available to handle the number of paid users, that's simply a problem to solve. It could be solved by the first contributor if they have the time and inclination administer a second instance, or it could be solved by anyone else, by deploying a new instance of the same relay software.

Since each relay instance can be run by different people, there's redundancy not only in terms of technical aspects but also social aspects.

If a relay operator doesn't comply with the protocol (perhaps they take payments directly instead of through the official channels), then the merit holders would probably vote to remove them from the set, and deny all further merit requests by them. This would also be the case if they are unable to continue solving the original problem (making a relay available). Shouldn't be too hard to write a script to solve the problem of validating uptime and speed standards.

Anyway, just an idea.