Having fun with sandboxing and I’ve got updates abound
- Nodes now generate RPC public/private keys on startup in a node subfolder called
- I’ve added a
sn_api similar to the
AuthdClient, which issues remote procedure calls
- On sending procedure calls, a one-time passphrase is generated and signed by the client to verify the sender’s identity. Message integrity itself is still managed by TLS, so I think that covers the bases
- Nodes can take the RPC port on the command line, and runs the service on localhost on the specified port. If not provided, disables the interface entirely.
sn_launch_tool was modified to assign a random port number between [34005, 36133) and default launches nodes with the rpc interface enabled. This is more of a temporary sorta hack to test things out.
- Added a
node subcommand in
sn_cli to test this out (more on that in a second).
Baby’s First CLI Command
Inspired by a thought I had a few months ago, here’s something basic that is not particularly easy to do yet. You can’t ask a running node for its
node_id (e.g. it’s public key on the Safe Net) or its
reward_key. You can check the logs, but that’s not possible to do programmatically, so it’s annoying to do for multiple nodes at once… So the first command I decided to try was
get-id, which just queries the node via the RPC interface for its
node_id and its public
This leads to the following flow:
> safe node run-baby-fleming
Launching genesis node (#1)...
running node with rpc on port 33496
> safe node get-id --rpc-port 33496 --cert-base-path <genesis_node_base>/rpc/
Interested in Playing Around?
I created a few new branches so if you want to try this locally, you can now!
To clone the sn_node, run:
> git clone --branch node-rpc https://github.com/Scorch-Dev/sn_node
> cd sn_node
> cargo build --release
And similarly for sn_api, run:
> git clone --branch node-rpc-client https://github.com/Scorch-Dev/sn_api
> cd sn_api
> cargo build --release
At this point maybe rename your stable versions of the
safe executables to something like
safe_stable. Then copy the built binaries to those locations
> mv ~/.safe/safe ~/.safe/safe_stable
> mv ~/.safe/node/sn_node ~/.safe/node/sn_node_stable
> cp sn_api/target/release/safe ~/.safe/
> cp sn_node/target/release/sn_node ~/.safe/node/
Things Left to Do
This is still definitely a work in progress, so there’s a few things left to iron out.
- I mentioned this in my last post, but it wasn’t a bug in
qjsonrpc that I had found, but just something I failed to notice. My machine resolves
localhost to IPV6, so that’s why I had trouble when binding the node to IPV4. Currently, that hasn’t been fixed yet. If your machine resolves
localhost to IPV4, this won’t work for you in all probability.
- Code style needs work. Some floating constants/magic numbers are still present here and there.
get-id doesn’t return structured data yet. It’s just a formatted String for now.
- Currently the
NodeRpcClient isn’t cached, so we just build a new one each time we send a request, which is wasteful.
- Command line parameters to
sn node get-id are a little ugly. The problem is that each node potentially runs from a different directory and on a different port, so I’m not sure what the best way to streamline this is yet…
- This only works on
localhost, similar to
As of now, I’m not sure how far I will take this or not, but for now I’m just having a good time making my node do fun things. Perhaps I can patch it into my local node for the next test-net even. Might be cool to try.
Maybe @bochaco or @joshuef would have some info about this, but do you think MaidSafe might be interested in eventually pulling a feature like this into the upstream repo? It’s still too rough now for that, but I’m wondering about looking forward. Like mentioned earlier, there are security implications. I also don’t know if MaidSafe is in a spot where they want to accept bigger community patches/features at any point in the semi-near future. Both for the sake of stability and resource bandwidth (e.g. reviewing and working with PRs). Beyond that, it was also mentioned that such a feature could be tunneled through safe in the future, so not sure how that would gel with using
qjsonrpc on the backend.
Anyway, that’s what I’ve got for now. Ideas, improvements, etc. are welcomed, and stay “Safe” all