robosats
robosats copied to clipboard
RoboSats
Abillity for Peer to Host Their Own Server (Federation)
Is your feature request related to a problem? Please describe. All peers currently depend on the infrastructure of Robosats. It is less than ideal as there is a central point of failure in this model
Describe the solution you'd like If peers can host their own servers and federate them, then there are many 'nodes' in the network, making it stronger
Additional context I know this is likely a big lift, and merely want to plant the seed as an idea for the future. Thanks for the great work you are doing! :)
Hey @kn0wmad very interesting!
I will share here my comments regarding this topic on the RoboSats Dev Telegram channel for the broader audience of Github.
RoboSats is a central coordinator of a P2P marketplace. The exchange itself can't be hosted by untrusted parties (many problems to solve: unsafe escrows? Pricing oracle? Dispute solving?).
However, users running a local app (as frontend) in their nodes to interact with the coordinator would benefit of higher security / ease of access / functionalities and privacy (e.g. super private notifications!). This app would in many ways be similar LOOP/LIT: the users run an interface that interacts with their nodes, yet the Swap provider is Lightning Labs centrally.
RoboSats is a Lighting app and relies on a single LN node. There is no foreseeable way a single LN node can be federated or decentralized. But there is some other components of the infrastructure that could potentially be decentralized and run on every pleb node.
Moonshot idea
A super wild idea that has already flown over the dev Telegram a few times would be to deploy RoboSats as a decentralized Kubernetes cluster (alla https://github.com/c3os-io/c3os). Where nodes would just run a docker container that will be tasked with pods. Cons: High complexity. Node runners can read memory and inject: potentially stealing Sats. No computation power benefit as RoboSats is really not compute intense. High latency. Whoever is running a node benefits nothing (it is still a webapp). Pros: Ultra high availability?.... and woah, cool, matches the ethos! :D
https://nitter.net/robosats/status/1564892599881814016
This original inquiry was to help get RoboSats onto Embassy, and we would gladly help make that happen. What is needed to accomplish this?
https://hub.docker.com/r/recksato/robosats-client also suggests that the coordinator can be changed, which suggests other coordinators could be hosted, what would be involved here?
This original inquiry was to help get RoboSats onto Embassy, and we would gladly help make that happen. What is needed to accomplish this?
As you pointed, we launched a few days ago a robosats-client app as a docker container that is well suited for those running sovereign nodes (DockerHub). It's only the client, but believe it fits very well Embassy too.
Let's work towards including it on Embassy. I am sorry I am not very familiar with the Embassy ecosystem. What are the steps to follow once the app is dockerized? Should we build a robosats-wrapper following the recipe (e.g. JAM) using the robosats-client image as base?
https://hub.docker.com/r/recksato/robosats-client also suggests that the coordinator can be changed, which suggests other coordinators could be hosted, what would be involved here?
Indeed, the p2p coordinator can be changed. This is maybe something a user might want: if the current RoboSats operation ceases; to connect to another coordinator; or even to use the testnet features.
I am preparing a more concise Issue covering the topic on how RoboSats can be decentralized into a federation. I think there is a way it can be done, though each participant in the federation must be trusted. Future updates of this dockerized client app will be key for the federation: but it must be adapted to work with several coordinators at once (that will take quite a lot of development and planning)
Let's work towards including it on Embassy. I am sorry I am not very familiar with the Embassy ecosystem. What are the steps to follow once the app is dockerized? Should we build a robosats-wrapper following the recipe (e.g. JAM) using the robosats-client image as base?
Yes, absolutely. Dockerization and Tor connections are usually the hardest parts, so it should not be a problem. We have dev docs, located here. The process is accurate, but I am currently in the process of simplifying and updating to include our latest best practices. Any feedback would be massively appreciated. In future, service packaging will be largely automated by our SDK's CLI tool.
We also have a dev community on Matrix or Tor Matrix. We can also chat via DM on Telegram if you prefer
We have dev docs, located here.
Very clear instructions here. I see we can skip directly into 5 - Create Manifest. Unfortunately I won't have time for this in the next few weeks.
I went ahead and started a RoboSats room in our Matrix: #s9-testing-robosats:matrix.start9labs.com
and a template repo, which you can copy or fork (for credit purposes): https://github.com/kn0wmad/robosats-wrapper - this is just a skeleton at this time
It's safe to say that with the release of v0.6.0 with "The Federation Layer" this is the first moonshot feature to go into production! Closing this issue :rocket: