So you want to make a SAFE Website

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.

Upload data

So now, let’s say you have a local folder mysite that contains index.html and css/styles.css so it’s not ugly.

$ safe files put -r mysite/

This will upload your folder to the SAFE Network :open_mouth: . 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! :open_mouth: :open_mouth: ). To do that and register a site… such as thesite:

$ 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 safe://thesite. -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!

Bonus Track

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!

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.


This makes me want to build a site very soon, hope that it will be rain this weekend. :slightly_smiling_face:


I have uploaded a simple safe site (safe://test) on the shared vault but I can’t verify the result (I have done this in a ssh session on a headless Ubuntu server from Windows).

The only thing I can check is this:

root@WS:~/safe-cli/target/debug# ./safe cat safe://test -iii
Native data type: PublishedSeqAppendOnlyData
Type tag: 1100
XOR name: 0xd10f0c7c38b50d4c947610a0715eb49514621d9fb3f76699d8dc44936dc506e5

Resolved using NRS Map:
PublicName: "test"
Container XOR-URL: safe://hnyydyw5xyknabqan31b8fkpyrd4nydtwpausi3urhtxqob4fk78n6siaybqh
Native data type: PublishedSeqAppendOnlyData
Type tag: 1500
XOR name: 0x36f028580bb02cc8272a9a020f4200e346e276ae664e45ee80745574e2f5ab80
Version: 1
| NRS name/subname | Created              | Modified             | Link                                                                     |
| test             | 2019-08-29T21:56:05Z | 2019-08-29T21:56:05Z | safe://hnyynyzeo6ddh8n4o4urwqaekyhk6s1kteao7u639q3w35dqrjr5pawdqkbnc?v=1 |

Files of FilesContainer (version 1) at "safe://test":
| Name                    | Size | Created              | Modified             | Link                                                              |
| /img/safe_logo_blue.svg | 5851 | 2019-08-29T21:54:30Z | 2019-08-29T21:54:30Z | safe://hbyyyyn5ey35si9umca83jkuo6t6qkmkwcp6s9t3g964d9u8fyippaza6z |
| /index.html             | 353  | 2019-08-29T21:50:22Z | 2019-08-29T21:50:22Z | safe://hbyyyydfxtk4hnrx9ppatuzjrh8o765456ij4pn3kwbuhw4rjyykmeiiyn |

I have recorded the whole cli session that creates it. I will upload it on asciinema but be tolerant because I made many mistakes (main one is forgetting --recursive flag in initial version)


You’ll probably need to use a full URL for the image as the browser seems to not yet like a relative path


I have added full URL for image (“safe://test/img/safe_logo_blue.svg”). Is it better?

Note: thanks to asciinema I could retrieve and copy/paste the long safe xor-urls.


It’s then probably not yet able to fetch content requested by the page itself and only from the address bar, I’ll leave it to @joshuef to confirm when he comes back online


And thanks to the whole history of the site stored in the vault, to be debug the problem he can retrieve:

  • previous version with relative URL with: safe://test?v=1

  • current version with absolute URL with: safe://test?v=2 or safe://test


Here is the link to the session on asciinema:


To be done once:

  • create account
  • authorize cli

Can be done many times (until safe coin balance is exhausted):

  • create files container
  • create NRS container
  • update files container
  • update NRS container

And the complete history of the site is perpetually stored in the shared vault (well, not yet because this is not the final safe network)


Yeh I think we’ve a bit of work to get done w/ resolution (defaulting to index.html eg).

Aye I’ll be looking at this shortly, thanks @tfa (and nice work on the vid too!)


FYI atm the mo we’re aware the the browser POC has had a hiccup with packaging, so you’ll see errors in the packaged versions right now. I’ll update when they’ve been fixed :+1:


I am thinking now that syntax “safe://test/img/safe_logo_blue.svg” cannot work because that would open the door to history rewriting (just change the version of the pointed to file and the current or a past version of the web site is changed without changing its version).

Maybe you simply meant “/img/safe_logo_blue.svg”, which I suppose will get the image at the version of the file container pointed to by the nrs currently displayed. So, I have made a third version of safe://test with this absolute url for the image (perpetual address is safe://test?v=3)

Can anyone tell me if it works?

1 Like

@tfa it doesnt work now, but it should. I’m seeing a bunch of errors locally to do with the fetch functionality there.

It’s a good example of where to head next after getting compilation on the go! So thanks for that!

And yes, you’re spot on w/ the need for relative files. That’s also something we’ve spoken about, and are thiking to block rendering of resources from outside the page’s FilesContainer to keep everything versioned. (And as it’s the SAFE network, you would be able to link to the original content direct, you’ll just need to update your NRS container too)


I made another attempt: append the version to the image url: safe://test/img/safe_logo_blue.svg?v=3. This syntax should be allowed for cross site links without risk of rewritten history.

This didn’t work either.

As an extreme solution I tried to put the xorl url of the image (safe://hbyyyyn5ey35si9umca83jkuo6t6qkmkwcp6s9t3g964d9u8fyippaza6z) to make the link work. But even that didn’t work.

But xorl url wouldn’t have been a good solution, because you must make several passes to upload a whole site. First referenced files and then referencing files, iteratively. This is even not solvable if there are circular references.

So, we really need:

  • Local absolute link /img/safe_logo_blue.svg
  • Local relative link img/safe_logo_blue.svg
  • Cross site versioned link safe://test/img/safe_logo_blue.svg?v=3

Ooookkay. After some hearty digging around the undergrowth of electron / neon and webpack, we’ve gotten updated browser POCs up for linux and mac.

You can find those here: Release [Working] PoC for CLI / new API fetch integration · maidsafe/sn_browser · GitHub

This does not touch resolution of resources in any way FYI @tfa, so there’s no change there yet.

I’ll be diving into that stuff once I have sorted the windows browser POC.


This complains that --recursive was given more than once.


Yes, -r is shorthand form of --recursive and you put it twice.


I’m reporting a problem with the instructions from the OP!


Ah good spot. I don’t have perms to edit the OP. I’ll ping someone who does. Thanks!


@happybeing & @tfa - that’s it fixed now!


Now relative links are working, thanks for that:

I tested this on a local vault with:

  • safe_vault tag 0.19.2 built from source
  • safe-authenticator-cli tag 0.3.0 built from source
  • safe-cli latest commit (27d58b7) built from source
  • SAFE Browser latest version (0.15.1) downloaded binary