Clams Remote Websocket #126
Conversation
There was a problem hiding this comment.
It appears you were following the built-in web-ui as an example. The web-ui was setup as an additional interface within the Core Lightning package as it is included within the package rather than the UI being a separate service depending on CLN.
As Clams is a separate service, the Clams interface and properties would be exposed in that package rather than Core Lightning. To my understanding, Clams will only require one change to Core Lightning: exposing the config option to to allow connections to port 7272.
| websocket: | ||
| name: Clams Websocket | ||
| description: Websocket endpoint for Clams Remote. | ||
| tor-config: | ||
| port-mapping: | ||
| 7272: "7272" | ||
| lan-config: | ||
| 7272: | ||
| ssl: true | ||
| internal: 7272 | ||
| ui: false | ||
| protocols: | ||
| - tcp | ||
| - http | ||
| - ws |
There was a problem hiding this comment.
Exposing an additional interface on Core Lightning shouldn't be necessary as Clams will have its own user interface which to my understanding is how the user would interact with Clams.
There was a problem hiding this comment.
So there are two onion endpoints that will be exposed in this project overall. This this particular pull request, we expose one endpoint which is Core Lightning's websocket interface. This allows any Clams Remote client running in Tor Browser to directly connect back to and control Core Lightning via websocket (assuming they have the required rune).
The second onion endpoint is the web server that serves Clams Remote static build output. This is addressed in another repository that I'll be making public soon.
There was a problem hiding this comment.
Connecting Clams to another service (CLN) on the same server using the tor network seems inefficient and undesirable. Unless there is a Clams limitation I am not understanding that would prevent this, I would think it would be far more desirable for Clams to connect locally to the Core Lightning container, c-lightning.embassy.
Looking at the Clams documentation for testing locally, I believe you should be able to get Clams connect to https://c-lightning.embassy:7272 assuming port 7272 has been exposed.
There was a problem hiding this comment.
Ok I think I see what you're saying now. As far as I know, that is not the model of Clams Remote. remote.clams.tech is just a web server that for the most part, serves static HTML/CSS/JS to requesting parties (Clams Remote is a PWA). The container running the web server that serves these files should NOT require access to any RPC interfaces on the c-lightning container (e.g., via network bridge), nor should it require access to any .lightning volumes. It's purpose is to simply serve the Clams Remote PWA to requesting web browser clients.
Once the PWA is loaded in the end-users browser, users can connect to one or more CLN nodes. The ONLY way to achieve this in Sovereign manner (i.e., no proxies) is to connect directly to your node. The method Clams Remote supports for this is direct websocket. This is configured in the users browser context, along with any authorization/rune information. This preferable from a security point of view that we know that connection/authorization information to your node is held exclusively on the user's device.
There was a problem hiding this comment.
Btw I pushed some commits to my implementation to the Clams Remote. https://github.com/farscapian/clams-startos . That works in conjunction with this pull request as described.
There was a problem hiding this comment.
To confirm, you have tested the package of Clams Remote with this PR, and it is working as expected?
Connecting Clams to CLN over tor when they are running on the same box is not ideal, but this seems to be a limitation of Clams at present.
There was a problem hiding this comment.
Yes, the clams-startos repo I posted above works in conjunction with this pull request and works as expected.
| "clams-websocket-tor-address": { | ||
| name: "Websocket Tor Address", | ||
| description: "The Tor address of the CLN websocket service.", | ||
| type: "pointer", | ||
| subtype: "package", | ||
| "package-id": "c-lightning", | ||
| target: "tor-address", | ||
| interface: "websocket", | ||
| }, |
There was a problem hiding this comment.
Exposing an additional interface on Core Lightning shouldn't be necessary as Clams will have its own user interface which to my understanding is how the user would interact with Clams.
scripts/procedures/getConfig.ts
Outdated
| "clams_remote_websocket": { | ||
| type: "boolean", | ||
| name: "Clams Remote", | ||
| description: "Enable Core Lightning's websocket interface for Clams Remote.", |
There was a problem hiding this comment.
As an additional interface isn't being exposed on Core Lightning, this description should be updated to something like "Accept incoming connections on port 7272, allowing Clams Remote to connect to Core Lightning"
scripts/procedures/properties.ts
Outdated
There was a problem hiding this comment.
Properties is reserved for displaying information about the service itself, usually not dependent services. As Clams will be a dependent of Core Lightning, these Properties related to Clams would be exposed in the Properties of the Clams service itself, not Core Lightning.
There was a problem hiding this comment.
I agree with this and will try to surface this in the Clams Remote repo, which I will make public soon.
There was a problem hiding this comment.
So here's the trouble I'm having at the moment getting this done. What is the standard way to get information from c-lightning over to the clams-www service? It seems like we're just creating files in /root/.lightning/start9/ . However, I don't want to mount that entire directory into clams-remote (www) service since it would violate least privilege. Can I create another mount?
There was a problem hiding this comment.
Please forgive me, I'm new to this repo so trying to figure things out as I go, appreciate the patience.
docker_entrypoint.sh
Outdated
There was a problem hiding this comment.
The Clams service should have its own tor address; exposing a tor address for Clams in the Core Lightning service should only be necessary if Clams were built into the Core Lightning package.
There was a problem hiding this comment.
The Clams Service does have its own tor address. Will try to surface the property in the Clams app.
farscapian
force-pushed
the
feat/websocket
branch
from
15c7bf7
to
36e135b
Compare
|
I've updated this branch with two commits. What's not in these updates is my attempt to expose the "Clams Remote Websocket URI" property (currently in Core Lightning) as a property in Clams Remote. It involved adding volume mounts and communicating sensitive data (including rune) which I didn't feel comfortable with. I would really prefer Clams Remote remain a standalone webserver with minimal privileges... This means the user will have to visit the Core Lightning service to access the correct information (websocket connection URI (property) and Core Lightning Rune (action)) to get Clams Remote configured in their browser. |
These changes add a websocket interface dedicated to Clams Remote. This interface listens on the LAN and has a dedicated onion address (written to /root/.lightning/start9/clamsRemoteWebsocketTorAddress in container) listening at port 7272 (http for onion). CLN is configured via the '--bind-addr=ws::7272' method. The "Clams Remote Websocket URI" is surfaced as a property. A configuration item to turn off the service is placed under "Advanced->Clams Remote" (off by default).
These changes are needed to support connections by Clams Remote. That team will be submitting the Clams Remote package to Start9 after they have evaluated the solution.
Special thanks to @chrisguida for helping with concept and getting this whole thing started, and for providing excellent advice! This project is the result of the Bitcoin++ Buenos Aires Hackathon project, which won the Best User Experience prize.