Skip to content

Context Graph File System

You do not have files you have memes.

Grammar for your data

Goals

I want something like PerKeep, PeerGos, and Mega.io that can do the following,

  • Runs natively in browsers
  • Has version control
  • Can be Peer to peer
  • Has fractional sync functionality
  • Has RBAC
  • Supports Encryption
  • Can work off remote cheap S3 storage

The key part of the CGFS vision is that you can run your entire life off an encrypted blog storage and pub sub system not requiring compute to be done on any servers.

PerKeep is an personal hash based blog storage system similar and older the IPFS. It can be mounted on Linux via fuse allowing you absolute version control over your files. Problems with Fuse are that it does not run in browser, it is hard to configure, and is no longer maintained, and does not have the capacity to share individual files.

PeerGos fulfills most of the requirements I have set out here except the first big one. Run natively in the browser. To self host PeerGos you must run their server daemon which is very difficult to setup.

Mega.io for me personally is nearly the perfect encrypted storage solution except for three things.

  1. Mega.io is a saas with a propriety backend therefore you can not self host, or operate peer to peer, though their clients are Open Source.
  2. Mega.io's client mega-cmd does not support remote mounting like NFS and samba therefore requiring syncing of files.
  3. Mega.io does have a open source webclient but it seems difficult to use.

What problem does CGFS Solve?

  • I want Obsidian available as a self contained PWA,with version control, RBAC for notes, and peer to peer publishing capabilities.

Features

  • Type validation is done using JSONSchema
  • Has a built in PKI to manage the keys for the IPNS names.
  • IPFS names are used for a variety of purposes.
    • Data can be shared and updated on the IPFS network
    • A separate private key can be used to sign the data to prove providence
    • The private key can be separately shared across devices and even people separating the concerns.
    • Rather than having indexes/collections/tables with their own namespace that can overlap and get confusing each app has their own collections and only when they explicitly reference one another can they be used across Dentropy Daemon applications.
  • Built in version control, each IPFS named collection index/collection/table has a has a version control log that is incremented
  • Data is not stored directly in indexes/collections/tables instead having data referenced via IPFS CID, all application CID's are stored in a separate index/collection/table
  • The only indexes/collections/tables that store raw data are
    • PKI
    • CID
    • Cached indexes/collections/tables generated from the IPNS indexes/collections/tables
  • Application need to be able to operate over a S3 storage provider.