Where does data live on your filesystem?

The webnative filesystem, WNFS for short, consists out of public and private versioned data. Public data lives in /public/... and private data in /private/... respectively.

Application data :hammer_and_wrench:

We currently have one path that’s “fixed”, and that’s where your application data lives. When apps ask you to authenticate, the auth lobby will ask your permission for access to:


We consider this the path apps will want to store data that’s specific to that app. For example, we have an app that shows a random quote each time you open the app. The app keeps a list of all the ids of the quotes it’s seen. This list is something specific to this app, not really all that useful to other apps. The quotes on the other hand, that is something you might share with other apps.

Sharing is caring :heart:

We want to have a future where data travels easily between apps. Be it private or public, and with the user’s permission of course. If I make a playlist in one app, I want to reuse that in another app. To make this trivial, we’re adding the concept of “common paths” to webnative.

// It might look something like this,
// we haven't decided on the exact interface.
await filesystem.ls(
  webnative.privatePrefix +

This will list the folder /private/Audio/Music/Playlists
If you would like to make a playlist public, you could do:

const playlistPath = webnative.common.audio.music.playlists("Feel Good Songs.m3u")

await filesystem.mv(
  webnative.privatePrefix + playlistPath,
  webnative.publicPrefix + playlistPath

Apps can now detect your public playlist by listing the playlists for the public side.
We can have utility functions for this, but I wanted to illustrate what would happen on your filesystem.

Editor :pencil2: & Viewer apps :eyes:

Having shared app data enables us to done some neat stuff. One of these things is the concept of editor and viewer apps. An editor edits or creates data, for example, an app where you write a blog post in. When you decide to make that blog post public, you can see the publically available version through the viewer app. There other people can read your blog post. Viewer apps are tied to your username. So for example, you could read my published blog post on stevens-blog.fission.app.

To compare it to current architectures, you can think of the editor app as a Wordpress admin interface, and the viewer app as the frontend with your public blog post. It’s like making a custom template for your Wordpress server, but taking that to another level, it’s completely independent.

// We could have an API that looks something like this
const { app } = webnative.initialise(...)

userwantsthistoo_button.onclick = () => app.clone()

You might trigger this button through a section on your blog:

Like this template?
Use it for your content too.

Or there could be a page with all kinds of viewer apps where you could pick one.
We don’t know exactly yet, ideas are welcome!

There’s an app for that :iphone:

Apps are the main unit of things on Fission.
So it only makes sense they are available on the WNFS as well.

We’re thinking of putting them at:


Putting the already public published fission app in your WNFS (ie. the creator’s WNFS), we can enable some cool things, such as, sharing the data schemas.


This could be another thing we make easier through webnative. We’ll have to do some experimentation here.

What about app source code? :file_folder:

Your live app lives at some domain, but you may also have a nightly, or staging, or just an experiment at different domains. And, those are the published versions – not the version you edit and build.

We’re thinking about storing your app source, too.

// TODO: Making app source code available
// Defaulting to private source code, it would live at:
// Or you could make it public:

Simple edits with Drive’s new plaintext editor, or even a future Code Editor app means you could build, publish, and host, all from your browser with your Fission account and Web Native File System.

Feedback :relaxed:

Are these concepts easy to understand? Do they make sense, or is something missing? We would love to know what you think about this.


Love the idea of Editor vs Viewer apps as a way to empower people to swap out front ends and also to decouple the CMS from the public site.

From your description of how public and private are used, I wonder if there is a distinction to make between:

  • public as in accessible to anyone via a URL
  • shared or common between apps (such as the quotes data), but perhaps not accessible on the public Internet
  • private, which can only be accessed by a certain app unless explicit permission is provided
  • Also, I may have misunderstood the idea of /public/Apps/Published/APP_NAME.fission.app but I’m not sure if this is like a centralized listing of all Fission apps or a per-user listing of the apps that one has interacted with

Thanks! Yeah, we need to make sure the wording is correct here.

  • You’re correct for both public and private.
  • Common can be either public or private, the data is on a common path (ie. app 1 uploads photos to /private/Photos and app 2 displays photos from /private/Photos)
  • Shared is private data shared with another person (not talked about here). You can also share public data, but that’s accessible by the other person anyway (it’s public).
  • /public/Apps/Published/APP_NAME.fission.app is a compiled application (a build) on the owner’s filesystem (ie. the app from that domain, the directory name).
1 Like

It’s per user accessible to the app owner. But, since it is public, technically the actual files are available to everyone when they visit the website: that’s how the app runs.

We can play various tricks to make content available to users based on their permissions. This is making app hosting files available next to your user file system. By making it an app, you can map a custom domain and do various other things available to apps over time.

Wording and descriptions very much in flux. Our goal is to communicate some of the differences and opportunities with our system, and what that enables. Feedback and comments very much welcome!

1 Like

Now consider the possibility of creating apps that are hyper-interoperable by virtue of the fact that they all utilize a common meta framwork to describe their data. Very much like Solid does it, but instead of RDF using a truly web native meta-model. That’s what MindGraph adds to the mix integrated with FissionDrive. E.g. It is possible to dehydrate a MindGraph as a WebNative FS structure hence compatibility with Fission Native Apps could be guaranteed

1 Like