You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Much of this repository can be reused for any self-hosted bitcoin core + lightning application. Those bits could be split off and moved into a seperate repository, e.g. "lightning-box".
I'm not entirely sure where to spit things, but here's my current thinking.
AWS
Options:
AWS templates can be installed with a handy Launch Stack button. It's possible to pass parameters into the form through the URL. One such parameter could be the GitHub URL of the target application that is to be installed on top of the "lightning box".
To reduce trust on the lightning box maintainers, and to rely less on passing parameters around through URL's, each application could generate its own template file, which the application creator can then publish. In the case of Rails, lightning box could be a Gem with an AWS template generator. The downside of this approach is that it becomes tricky to line-by-line compare each application template with the upstream original, and it becomes more difficult to build an auto-update mechanism for the lightning box stuff.
At the moment I think option 1 is better.
Bitcoin Core, C-Lightning, Postgres
These ship by default. If someone wants to swap any of these components, that should be fairly easy by adding a dropdown to the AWS template.
Lightning Charge
I intend to fuse this into Rails (#13), so see next section.
Rails, Puma, ReactJS, admin panel, invoices
Although Lightning Box could be framework agnostic, there's a lot of reusable stuff in the Rails & ReactJS setup. Especially if a Lightning Charge replacement is integrated. Particularly:
None of this prohibits anyones from building support for a completely different stack (e.g. NodeJS based), as long as it can access the database.
Although I'd like to split Lightning Box into multiple repositories, it's not obvious how, especially because the admin panel deeply integrates with the full stack.
The text was updated successfully, but these errors were encountered:
Much of this repository can be reused for any self-hosted bitcoin core + lightning application. Those bits could be split off and moved into a seperate repository, e.g. "lightning-box".
I'm not entirely sure where to spit things, but here's my current thinking.
AWS
Options:
AWS templates can be installed with a handy Launch Stack button. It's possible to pass parameters into the form through the URL. One such parameter could be the GitHub URL of the target application that is to be installed on top of the "lightning box".
To reduce trust on the lightning box maintainers, and to rely less on passing parameters around through URL's, each application could generate its own template file, which the application creator can then publish. In the case of Rails, lightning box could be a Gem with an AWS template generator. The downside of this approach is that it becomes tricky to line-by-line compare each application template with the upstream original, and it becomes more difficult to build an auto-update mechanism for the lightning box stuff.
At the moment I think option 1 is better.
Bitcoin Core, C-Lightning, Postgres
These ship by default. If someone wants to swap any of these components, that should be fairly easy by adding a dropdown to the AWS template.
Lightning Charge
I intend to fuse this into Rails (#13), so see next section.
Rails, Puma, ReactJS, admin panel, invoices
Although Lightning Box could be framework agnostic, there's a lot of reusable stuff in the Rails & ReactJS setup. Especially if a Lightning Charge replacement is integrated. Particularly:
A Rails Application template could be a good tool for this.
None of this prohibits anyones from building support for a completely different stack (e.g. NodeJS based), as long as it can access the database.
Although I'd like to split Lightning Box into multiple repositories, it's not obvious how, especially because the admin panel deeply integrates with the full stack.
The text was updated successfully, but these errors were encountered: