SAFEpress Status Updates

On this topic I will post monthly status updates. If you want to comment on them it would help if you’d do so on the SAFEpress Google group where they are also posted, rather than here.

For more on the project, see


PS These updates also appear with links in tact at under “Status”


July 2015

The SAFEpress vision was announced on the SAFE Network forum
as a community endeavour, free (as in free) open source with GPLv3
licensing. No shareholders, but the possibility of rewards for
contributors, generated by SAFE Network itself.

The announcement quickly received a lot of positive comment and
discussion about how to do this, so we’re already attracting people
offering to work on the different parts of the project. Not just
programmers, but also designers, front-end developers, website builders,
enthusiastic users and plain fans. If you want to learn more or think
you might also contribute, see contact us.

The SAFEpress github repository was set up, and an Outline Design
published. This enables contributors from anywhere to collaborate on
any aspect of the project, including the vision, its design and of
course development. You can begin contributing by cloning the
repository, picking a task, and submitting your work and updates as a
pull request… even to this website! This is just a standard template,
so if you want to improve it, or create a whole new website go ahead:
add it to the task list in the with your github name, a pull request to update the task list and off you go.

The SAFEpress twitter feed went live, as did this website. It begins…


August 2015

We submitted some ideas to MaidSafe for how to support dynamic
websites entirely on the client side (no server means no server side
scripting!). We wait with baited breath for feedback, readily expecting
some neat solution that we didn’t think of ;-).

Our task lists are now on Trello
so anyone can claim something or record what they are working on and
keep others updated. Its really your choice, if you think something is
useful, add a card and do it!

We now have a SAFEpress Google Group for team and community discussions. Join us or just drop by to say hi!


September 2015

Mostly quiet due to holidays n stuff, and trying out some
stunning developments in SAFEnetwork: the “Uploader” safe_dns example
can be found here and allows you to create a demo website on a local vault network!

Also planning some things to do in October while waiting for news
on the SAFE REST API, particularly how Structured Data can provide some
backend functionality.

The team has shrunk a little due to distractions and other
priorities so there is plenty of scope for people to get involved. We
could do with input on how to make a nice front end, how to do a client
side CMS, poking around to make a versatile backend in the client, that
talks to SAFEnetwork, etc etc. But don’t be shy, with this project
anyone can help out - from chatting about us on social media, enhancing
this simple website, or telling us what you’d like to do with SAFEpress,
and of course asking us questions: it all helps!


A post was merged into an existing topic: SAFEpress Questions

Awesome stuff, I even wasn’t fully aware of your project… I did some reading on it awhile ago but I’m not that much on the forum because the spare time I have after ‘work and home jobs’ I’m studying… Currently trying to understand rust because I love the way it’s build and documented.


Happy New Year everyone. It is January 1st 2016 and lots of exciting
developments coming this year for SAFEnetwork, starting with the first
live testnet very soon, I hope. This is a short update on SAFEpress
during the last quarter of 2015.

October-December 2015

SAFEpress has been a bit quiet lately - other team members have
not been checking in so in assuming they’ve lost interest or lack time,
though new people have also joined and started getting up to speed. At
the same time there is continued interest and support, so we need more

Personally I’ve been busy with other work, so not spent any time with code,
but I’ve still been thinking.

Reading about similar projects on the SAFEnetwork
forum got me rethinking my ideas on the back-end and data architecture.
This involved both throwing things up in the air so to speak, and
coming up with plans for building something simple to help test ideas
and experiment with the SAFEnetwork API.

I’m held back by time and also uncertainty about
implementation - particularly about how Structured Data can be used on
SAFEnetwork to represent relational documents such as blog-post /
blog-comment. So for now I don’t have enough time or knowledge to push this
sized project along without a lot of help, so we’re really in need of
more people doing more things to establish a what and a how, and begin
doing it.

So if you are interested in creating dynamic web apps for
SAFEnetwork and contributing to the early phase of a “WordPress for
SAFEnetwork” please get in touch and join our Google group (details of
this and other SAFEpress resources are at


Really glad to have the update, Mark.

I know what it’s like to get busy elsewhere. :sunglasses:


April 2016

Not quite a full status update but a mini alert :slight_smile:

The new SAFEpress approach, given my limited resources is to start with support for remoteStorage.js and see what I can build with that. The nice part about this is that it has lots of benefits way beyond SAFEpress, including the ability to run existing remoteStorage web apps on SAFEnetwork, and offline with auto sync when connected, like a free personal cloud across all your devices.

Join me if you like to tinker with JavaScript… this plus @eblanshey’s SAFE JavaScript API could be big, but I don’t have much time so it will also be slooooow if its just me.

More here on the SAFEpress forum:

Towards a SAFE Website CMS… extenting remoteStorage / unhosted to SAFEnetwork


May 2016

A proper update at last including some actual code! Nothing impressive or useful yet, but a foundation into which I can begin to add spoonfuls of SAFE API :slight_smile:

Details on the SAFEpress Google Group:


All that time previously spent modding is paying off for future safe press users!

1 Like

SAFEpress Mini Update - 16th May 2016

I had a mini triumph late last night and want to share… :slight_smile:

I modified the remoteStorage backend and got a sample web app to send an auth request to the Launcher and receive an “Unauthorized” response. That was after some crucial and patient help from @raucao of the remoteStorage team, helping me figure out what the differences were between node.js and pure (in-browser) JavaScript coding is about, and how to use their slightly bespoke build system (I was only one edit away from that working but … needed the crucial second pair of eyes to help me find it :slight_smile:)

So what what has been achieved so far:

  • a SAFE Network backend loads in a sample App and the user can choose to try and connect to SAFEnetwork. When they do it sends an authorization request to the SAFE Launcher which responds “Unauthorized” (because there isn’t a network I think).
  • I copied the MaidSafe /auth example code (link below) and adapted from node.js to pure JavaScript. I posted a summary of what I did to achieve this on the remoteStorage forum.
  • I included libsodium, and had to find a replacement for node.js Buffer (the MaidSafe code uses both). Later I’ll try to do without libsodium as it is a whopper, but first I want a functioning remoteStorage backend.
  • I had to configure the remoteStorage build system to include my code and the libraries I needed. And all this without breaking the remoteStorage build system and test suite :slight_smile:

I’m crowing about this because I’m new to the whole JavaScript ecosystem. If I can do this, there’s a good chance others can, and I may now be able help out when people are stuck.

I pushed the code and you can view it here. I recommend viewing only while wearing sunglasses :wink: If you look carefully you can see the small section that corresponds to the MaidSafe docs /auth example code. Very little else in that file is real or working, just a copy of a totally different backend for Dropbox.

This topic is for status updates and announcements only so please follow up on the SAFEpress Google Group.


Just to confirm my small triumph - with testnet3 and SAFE Launcher logged into an account my remoteStorage Demo application succeeds in getting authorised:

Step 1 of 3 - Logged into SAFE Network:

Step 2 of 3 - remoteStorage Web App requests access to my SAFE storage

Step 3 of 3 - Launcher shows it in list of authorised SAFE Apps! :slight_smile:

This topic is for status updates and announcements only so please follow up on the SAFEpress Google Group.


Status Update - July 2016

The latest update is posted on our Google Group (link below).

TL;DR Summary

I have a simple App (screenshot below) talking to the SAFE NFS API using SAFE Launcher (API v0.4 - the one with encrypted communications). It is buggy, but successfully authorises with launcher, creates directories and stores files, and can retrieve the content of stored files. I’m using “mock routing” to do this which makes development much easier as it simulates the network and so I’m not dependent on what the testnets or the developer network are doing, internet access and so on.

To get here I have had two goes at creating a SAFE backend for remoteStorage.js (a reference client for the remoteStorage protocol). My first attempt was based on an extension to the rs.js client that supports DropBox and the second is based in their GoogleDrive version. (Note: there is also a reference server that implements the RS protocol. RS servers are available commercially, or users can install it on their own hosting or servers, so you don’t need to use a commercial service or even a third party - this is what is about).

I’m now looking into how to handle versioning (which rs.js expects but is not yet available in the SAFE NFS API). I hope to be able to work around the bugs I’m seeing - some of which are almost certainly due to my not having worried about versioning or file metadata yet!

Full update here: Status Update - 13th July 2016


Hi there,

Râu from the RS core team here. I just wanted to point out that there’s a bit of a wording problem, which will cause misunderstandings if not corrected. Let me explain:

RemoteStorage is a protocol for per-user storage on the Web. It defines how both clients and servers have to behave to be compatible with it.

We develop and maintain a reference client library that makes it easy for developers to store data in users’ browsers offline, as well as sync it to remoteStorage-compatible servers. It is called remoteStorage.js, and it is but one client (albeit the most popular one).

However, remoteStorage.js already has experimental support for syncing to other backends, i.e. not remoteStorage backends. There are many reasons for this, but mostly to ease the transitions for both developers and users to an open protocol, by giving them the choice to use what they are familiar with for now, and migrate data later on, whenever they’re ready.

So, as such, there are no other/new remoteStorage backends. Either a server is remoteStorage-compatible, or it is not. In this case, what’s actually being done is adding a new storage backend to the remoteStorage.js library, enabling Maidsafe as an additional option for app developers and users (next to RS, Dropbox and Google Drive).

Ideally, we can agree on using remoteStorage.js (or rs.js for short) everywhere. I think it’s important that we make it clear that it’s about that one JavaScript library when talking about this specific topic and not mix it up with the general RS protocol. The protocol just does not have support for different backends/servers.

Now, with that out of the way, some personal opinions:

I think–and I know the current maintainers of rs.js agree with me–that it’s a great idea to turn remoteStorage.js into a more general-purpose, offline-first, unhosted storage library. And Maidsafe would be the first true opensource addition as a new backend.

I’m not keen on adding more proprietary options at all actually, but adding more opensource options can only benefit both developers and users, as well as the unhosted movement in general. So I’m extremely glad that this is happening, and we’ll fully support efforts from anyone toward that shared goal, now and in the future.

Thank you!


This is really (really) fantastic to hear. I think as @happybeing progresses this we will all take this much more seriously. A discussion about making SAFE rs compatible is certainly not off the cards at all. These first steps are great and perhaps it’s a very good idea to look further to see if we can get this progressed through the project proposals area to get more folk involved and paid to further this one.

Thanks very much for the input here. In house we are all rushing like maniacs at the moment but trying to reach out as well. I think this could be an excellent route to puruse.


Thanks for tidying up my clumsiness @raucao :slight_smile:

@dirvine I will continue for now, but having a SAFE RemoteStorage API inside SAFE Launcher sounds cool!

I’m poking around in the dark really (and having fun), but someone who knows what they’re doing an can work solidly on it could well do this quite quickly because it is just a REST API with a bit more functionality behind it than the current SAFE NFS API (creating/destroying directory paths automatically, eTags, versioning, and if-match / if-no-match options). This is all new to me so I’m very slow but someone familiar with this could blitz through it.


No worries.

“Versioning” meaning: ETags on files and directory listings, and properly responding to If-Match and If-None-Match requests. Not as in: “give me version X of this object”. Just as in: “I want to replace version X with version Y” → “Sorry Dave, I can’t let you do that, because I have version Z stored over here”.


Awesome. This is the kind of brainpower that the Safe team wants to align with. What a compliment and vote of confidence to @dirvine et al and great work @happybeing


@raucao I tweaked my post and how the language is now OK?