So you want to make a SAFE Website

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:


Results of safe files put -r ~/xtest and safe files put -r ~/xtest/ commands are not the same.

IMO, the presence or absence of a trailing slash on the directory name shouldn’t change the result. So, I opened an issue about this problem 20 days ago but didn’t receive any news about it. I would be glad if someone from @maidsafe could comment on this.


Fyi: that difference in behavior also exists for the Linux command rsync (with a recursive flag). That rsync behavior was confusing for me at first, but now I’m used to it.


Thanks @draw, I didn’t know rsync command behaves like this.

I agree that consistency with this command is a very good reason to have implemented safe files put command like they did:

  • Without a trailing /: the last element of source path is root of destination path
  • With a trailing /: the last element of source path is omitted in destination path
$ rsync -r remote:xtest .
$ tree .
└── xtest
   ├── img
   │   └── safe_logo_blue.svg
   └── index.html

2 directories, 2 files
$ rm -rf xtest
$ rsync -r remote:xtest/ .
$ tree .
├── img
│   └── safe_logo_blue.svg
└── index.html

1 directory, 2 files

I will close my issue with this remark.


I think both approaches have their (dis)advantages. Lower priority atm for Maidsafe I guess


Ok, for now I won’t close the issue and I will wait for comments from Maidsafe.


They have already answered somewhere that this was done for consistency with rsync.


rsync is a very common UNIX/Linux tool. Hell, it can even be made to work on Windows, so I am led to believe… If Maidsafe were to step away from consistency with the industry standards, at least in terms of common practice and usability, I for one would be very annoyed - and quite surprised.