New remotestorage.js backend: Safestore.js for SAFE Network

This topic is for discussion of my ongoing implementation of a backend for SAFE Network.

SAFE Network is a user owned / decentralised internet that includes file storage among many other features, but operates independent of protocols such as DNS, SSL etc. It is in pre-alpha testing - for status check the SAFE Network forum.

So far I’ve had preliminary discussions here, on other rs forum topics, with regard to:

From here on most of my questions will relate directly to the rs backend I’m creating so I plan to keep discussion here where possible.

Later: A SAFEpress CMS - Web App

For interest, I’m not only interested in allowing rs compatible apps to work with SAFE Network.

When that is in place I want to create CMS type application for SAFE Network, and hope I’ll be able to build this on top of the remoteStorage backend. That project is ambitiously titled SAFEpress - a WordPress like CMS for SAFE Network, but I’ll be happy with something much simpler than that to start with. For more on that, see and for SAFEpress specific discussion we have a SAFEpress Google Group. For the time being that is largely a place where I share progress updates, but I hope others will join me there to help build a SAFE Network CMS.

1 Like

@raucao I’m looking at the authorize code and want to check out with you. I borrowed the Dropbox backend and see that it uses some of the core authorise.js functionality, but think that is not useful for SAFE. So I’m planning to ignore it and encapsulate the authorisation within safestore.js.

Is that sensible, or am I on the wrong track there?

Sounds reasonable if SAFE Launcher isn’t using OAuth 2.

No, its very different. User provides credentials to the launcher which gives launcher access to their data on the network. Apps request access - launcher prompts the the user to “Allow, or Deny” the App access for one session or until revoked. I don’t know OAuth but I doubt the two have anything in common.

Can anyone summarise the status of the dropbox.js and googledrive.js backends? I’m aware they are prototype, are they incomplete or not tested adequately or…? If they are incomplete or have known deficiencies, can anyone itemise these?

Lacking a full understanding of what to implement I’m using them as a template spec for safestore.js backend but am not sure how far this will/won’t get me or what holes I’m digging for myself :wink:

Right now I’m wondering about restarting, but using the googledrive.js as my template rather than dropbox.js which I used so far, but I’m wondering if I was steered towards dropbox.js because it is more complete perhaps?

They are experimental. That means they are not fully tested and supported at the moment. Partly because the widget isn’t ready for them, and partly because they have some bugs and issues that still need to be solved. You can search the GitHub issues for the respective tags:

(Not all of those need to be closed for removing the experimental flag.)

Thanks. The issues seem to be all bugs, so does that mean they are believed to be feature complete and to implement the same backend behaviour?

I ask because skimming (ie not fully understanding what the code does :slight_smile:) leads me to wonder - for example - whether they both implement the ifMatch IfNoneMatch features in full. I confess I find it hard to understand exactly how that works or what the behaviour of the code is / is meant to be, so I’m just asking for guidance before embarking on a new chunk of code.

And was there a reason you seemed to point me towards dropbox.js rather than googledrive.js?

Every custom back-end will behave a little bit different and might need adjustments in behaviour. For example for Dropbox we don’t use /public for the public item URLs, but whatever Dropbox gives us instead.

The important thing at the end of the day is that the BaseClient functions all work in general.

Not particularly. I just felt like the Dropbox back-end was worked on more than the Google Drive one. But for all I know the Google Drive one might just as well be a better template for SAFEnet. Or the WireClient itself.

@happybeing how far did you get with this?