So you want to make a SAFE Website

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:

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

Note also that all other kinds of links I mentioned earlier also work:

But a problem is that a cross site unversioned link also works, though it shouldn’t have in order to follow perpetual web requirements.

For example with the following index.html file in files container pointed to by safe://test2 NRS map:

<!DOCTYPE html>
<html lang="en">
    <h1>My simple safe site</h1>
    <h2>Relative link</h2>
    <img src="img/safe_logo_blue.svg">
    <h2>Absolute link</h2>
    <img src="/img/safe_logo_blue.svg">
    <h2>Versioned safe link</h2>
    <img src="safe://test/img/safe_logo_blue.svg?v=1">
    <h2>Unversioned safe link</h2>
    <img src="safe://test/img/safe_logo_blue.svg">

The 4 images are displayed correctly. This is OK for the first 3 links, but the last one shouldn’t have been displayed because this version of safe://test2 will appear differently by issuing a new version of safe://test with a new safe_logo_blue.svg image.

Of course, a web site is allowed to evolve but the problem here is that it is modified without changing its version (I mean version of safe://test2 NRS map).


Aha. Yeh. You’re right. We’ve a fix in place for this for resources from the same domain ( ie. Unspecified version of IMG/whatever.jpg will now resolve to the current version of the NRS map).

What you’re describing (as I understand) is that we should be blocking resources X domain wise, when no version is specified.

This should be pretty easy to get in atop the other fix. Though I wonder what the http response for this should be (as we need to be sending http in the end.) Perhaps just 403 forbidden for now. And the browser can log xdomain unspecified version or some such…


You could instead just ignore the element and display a placeholder image, like when local links were not implemented: