You’ve seen the new CLI exists, and a proof of concept browser. But how easy will it really be to get a site onto the SAFE Network?
SAFE CLI and Authenticator daemon
You’ll need to have the SAFE CLI downloaded onto your system. You can follow our guide for that.
Once you have the Authenticator daemon running locally (also in that guide), you can begin.
$ safe auth login --self-auth will log you into the Authenticator daemon, authorise the CLI and save that authentication locally for you.
So now, let’s say you have a local folder
mysite that contains
css/styles.css so it’s not ugly.
$ safe files put -r mysite/
This will upload your folder to the SAFE Network . The
/ at the end is important to set the root of your newly created
FilesContainer to be
mysite (and not have
mysite as a folder within it). You can read more about this in the SAFE CLI User Guide.
It will in return, print out some info about your new files on the network. The
Files Container URL is important and we’ll need it for the next step…
Create a Public Name
The SAFE Network uses a distributed Name Resolution System to allow you to register easy, human-readable URLs (but without any third party! ). To do that and register a site… such as
$ safe nrs create thesite -l <link to FilesContainer URL>?v=0
?v=0 is needed here to specify a version to point to. The SAFE Network Fundamentals note that all public data must be versioned. And this way, we can easily track any/all changes to a Public Name.
And now, you can check your site on the network via;
$ safe cat safe://thesite/index.html
Updating your domain.
The SAFE Network distinguishes between updating a
FilesContainer, and updating an NRS Name. The latter, must always be versioned (as we saw above).
When you have changes to your site, you can update your NRS using the
files API thus:
$ safe files sync ./mysite/ safe://thesite -u -d -r
-u here updates the corresponding
NrsContainer as well as the
FilesContainer, so your changes will be reflected at
-d signifies that any deleted files will be deleted in the next version of the containers, too.
-r is again, to sync recursively.
And now, if you access
safe://thesite/index.html, you’ll see your changed files:
But Wait! There’s more…
Not only can you update your site easily, but inherent in the SAFE Network (as I may have mentioned), is versioning. So you can actually access older versions of a site via the version query param:
$ safe cat "safe://thesite?v=0", will show you your first content, for example!
I can’t believe it’s not the internet!
Right? That’s probably what you’re thinking now: Why doesn’t the internet do this?! Why do I have to faff around with domain registrars, pay money and not own my stuff? Why do I need a server? UGH.AMIRITE?
I hope so.
Anyway, that’s it (for now). Three commands for getting your data on the SAFE Network. Hopefully, you’ll find it useful and be able to integrate it into your workflows, pretty easily!
And if it’s not enough. We’ve got more coming. So just sit back, relax, and read our weekly dev updates.
As it stands it’s all still alpha software, so any and all feedback is welcome!
If you want to actually see your site in action, we have a browser proof of concept available for download that works with the SAFE CLI and the Vault too!
Note: The latest version of the SAFE CLI is not compatible with the latest version of the SAFE Browser at the moment so for now you’ll need to use SAFE CLI v0.6.0 (follow the instructions here to start the Authenticator daemon but make sure to install safe-authd v0.0.1).
Learn more about the CLI commands
If you want to learn even more about the commands and use cases supported by the SAFE CLI, please refer to the SAFE CLI User Guide, we strongly recommend you to give it a read to be able to make use of all the functionality it provides.