[Draft] Roadmap for RoboSats Federation

[Reckless-Satoshi]

Introduction

At the moment, anyone can spin up a new RoboSats instance. It's free source code and that's how it should be used. However spinning up new instances leads to two issues: 1) further fragmentation of an already very thin p2p market and 2) lose of revenue for further platform development (operation becomes detach from code maintenance).

Currently there is a single RoboSats coordinator that is operated by the devs, so these two problems mentioned before are not an issue. However, this approach is also problematic as centralization makes RoboSats susceptible to attacks. In addition, given the recent attacks to Open Source devs, it would also be best if we can completely detach code development from any of the regulatory risks of operating the p2p coordinator.

In this issue I propose a solution to federate RoboSats model into many p2p coordinators competing in a market. Coordinators can each host their own frontends and, by default, show every other coordinator member orders (seamless joint order books). Users self-hosting the sovereign node app will always be able to add/delete federation members as they wish.

Definitions

RoboSats the app with cool robots to exchange BTC for fiat P2P. Coordinator the party in charge of allowing matchmaking and source of trust. Creates the invoices. Maintains the RoboSats backend and infrastructure. Source of trust. Federation the set of all coordinators/operators of RoboSats backends. Devs those contributing code. Dev fund the pool of capital coming from dev tax and donations used to maintain and improve RoboSats.

Tasks towards RoboSats Federation Minimum Viable Product:

Frontend:

• [ ] Read from static/federation.json the list of RoboSats coordinators and their .onion addresses.
• [ ] Book page requests all orders from all coordinators. Shows each row on coordinator's color as well as the coordinator logo. Book page allows for filtering by Federation member.
• [ ] If a user clicks on the order of another coordinator, it should trigger an api/usergen/ request (so that Robot / Avatar / Token hash / PGP pubkey and encPrivKey exists as well on the coordinator's database)
• [ ] Everything else in the trade pipeline remains the same. However the /order/ API requests will be made to that order's coordinator .onion address.
• [ ] Each coordinator, on its hosted frontend should be able to opt-in and out of showing other coordinators orders. They can do so by editing the static file they host in static/federation.json. Users who are self-hosting the frontend can delete/add as they wish.
• [ ] Optional. At the end of a trade, the user rates the coordinator (instead of "What do you think of RoboSats?"). The order ID, rating and coordinator alias is sent to every Federation member. The ratings will help keep coordinators informed about their own performance and other federation members performance. It will allow for sorting access to coordinator addresses in the docs / github / frontends according to some non-arbitrary criteria.

Backend:

• [ ] Optional. coordinators backend could periodically fetch stats from other coordinators and "keep them in check". E.g. a coordinator might not want to show in its frontend orders of Federation members whose LN node is down, whose trade fee is very large, not contributing Sats to the dev fund, etc.

How to become a RoboSats Federation Member

Who can become a RoboSats operator in the Federation? Anyone. Simply open a PR adding a new entry to /frontend/static/federation.json. However, bear in mind it's a market, you will need to gain users trust and failing to satisfy users of your instance might exclude you.

Before jumping in, be mindful that operating RoboSats is not just "pasive income" and you might first want to have as much experience as possible on system management, running a LN node, the legal system of your jurisdiction, general opsec, docker/kubernetes, customer support and have a deep understanding of RoboSats.

New coordinator submission example .json https://github.com/Reckless-Satoshi/robosats/blob/138311a1b7b96d7f66a202e16e7c76715b6755bd/frontend/static/federation.json#L2-L22

The fields description, contact methods and cover letter are not required (but can be used to add customization and a nice touch).

Short list of what a coordinator is expected to do:

• Run RoboSats production environment.
• Build reputation and users trust.
• Keep a well maintained LN node (Note: Sats at risk, RoboSats backend is not hack proof).
• Solve users disputes fairly.
• Be informed about their jurisdiction regulation.
• Compete with other RoboSats operators on a free market (e.g. compete on fees, user support, transparency, awesomeness, reachability, outreach, etc).
• Earn Sats from trade revenue and stack sats for bringing easy and private p2p to the masses!
• Stream Sats to the RoboSats dev fund (voluntary).

RoboSats production orchestration already exists, yet it has been closed source for security reasons until now. There is two flavors, 1) a well-tested docker-compose orchestration and 2) an elegant but little tested Kubernetes orchestration (as layered Kustomization, so only YAMLS, no Helm chart). The infra as code will be open-sourced at some point in the near future.

Funding development

Dev tax We are going to call it Dev tax but it is voluntary, so it's technically a donation. To be better defined in the future, an example: master branch will default to donate 20% (streaming Sats) of operator profits for development, project marketing budget, etc. Of course, operators can choose to set this setting to 0. We hope there will be some pressure by users to prefer to trade on coordinators that are donating to maintain the codebase.

[satoshibug2008]

Hello @Reckless-Satoshi , I am so happy to see that Robosats is going in this direction. I have some doubts that I want to address:

1. The definition of Coordinator and Operator is same person, why this distinction is being made? It makes it more confusing.
2. There is no mention of the different fees structure that the Coordinator or Operator can impose and how frontend will address that info from different operators in the federation?
3. Rating system should be not optional but mandatory, with granular level survey to ask about experience, fees and if the order goes to dispute how was it handled out of 5 stars and even comments needs to be stored and displayed to public for each coordinator. This will create a good marketing tool for different operators in the federation that they advertise.
4. Lastly, the frontend and backend of the Robosats needs to separated into different repo that is very clear and people don't confuse when trying to install backend. Or extra steps need to be taken to separate backend and frontend in the same repo.
5. I suggest, 20% donation for now is good for dev tax but I imagine going in future when robosats becomes stable and doesn't require active maintenance, it can be reduced. The way I imagine it is by doing what BTC did. With every block added to the block chain height of BTC dev tax gets reduced by x% small percentage and that can x% is decided by decaying function that depends on BTC block height. The finer details of this function can be discussed also later.

[Reckless-Satoshi]

1. The definition of Coordinator and Operator is same person, why this distinction is being made? It makes it more confusing.

I think so far we have been using both in some communications (mostly on Telegram). However, both are the same. Let's stick with "Coordinator" and deprecate the use of "Operator".

2. There is no mention of the different fees structure that the Coordinator or Operator can impose and how frontend will address that info from different operators in the federation?

Indeed. Probably a Tooltip should show on click/hover over the Coordinator logo showing the parameters that coordinator runs (/api/info/ endpoint).

3. Rating system should be not optional but mandatory, with granular level survey to ask about experience, fees and if the order goes to dispute how was it handled out of 5 stars and even comments needs to be stored and displayed to public for each coordinator. This will create a good marketing tool for different operators in the federation that they advertise.

Agree. It's a must, however not strictly necessary to start decentralizing RoboSats in practice into several coordinators. It can (should) be implemented later once we have a minimum viable federation.

5. I suggest, 20% donation for now is good for dev tax but I imagine going in future when robosats becomes stable and doesn't require active maintenance, it can be reduced. The way I imagine it is by doing what BTC did. With every block added to the block chain height of BTC dev tax gets reduced by x% small percentage and that can x% is decided by decaying function that depends on BTC block height. The finer details of this function can be discussed also later.

It's an interesting approach, I really like it! Though I am not sure if assuming Dev costs must proportionally decrease over time makes sense, maybe best not to hardcode a decay. There will always be new exciting features that can be enabled, security threats that come with wider adoption, scalability improvements, new systems to launch at. After all, the tax will be voluntary and cannot be enforced, so the market (every coordinator) will end up finding a sweet spot.