Skip to content

CGFS - Lite Paper

CGFS - Lite Paper - Roadmap

Recompile the internet with context, meaning, and awareness

What problem does CGFS solve?

CGFS Design Heuristics

  • JSON in JSON out
  • Everything is stored as a CID
  • All keys are zbase32 encoded to work with bucket names
    • No worrying about mediocre Unicode support within implementations
  • Everything is referenced using some sort of DID/CID/URL
  • LevelDB, Sorted Key Value store is the assumed base data storage solution
    • Sub-levels can be managed via separate S3 buckets
  • All your data is accessible via a Dataframe
  • One CID per Nostr Event
    • Think of this as Torrenting
  • EVERYTHING IS A SIGNED MESSAGE
  • We want to avoid recursive Sublevels
  • Edges go between pointers not CID's
  • All data associated with a "DID" or user is going to be signed by the equivalent of a individual TLS cert via an authority that can be updates by a different cert down the line, collections can be associated with individual "Certs" or individual indexes can be associated with individuals certs
  • For POC purposes we support recursively signed nostr keys because that is simplest, later we can support TLS, Ethereum, and other signing mechanisms
  • Memex Basics
#TODO CGFS Provenance Options

#TODO Permission Namespaces

  • Namespaces are all managed using event queues
  • All events are signed nostr messages
  • There is RBAC articulating which public keys/ DIDs can modify what

Sections

CGFS Questions

CGFS Bootstrapping

  • We create a RxDB collection for the private keys, name TBD
  • We create a RxDB collection of the root collection
  • We generate a private key a list of key pairs for each CGFS Schema - Core collection
    • Store the private keys in the private keys collection
    • For each private key get the base58btc encoded Multiformats public key and create a collection, unless you have information to insert don't insert anything
    • Store each CORE collections metadata within the ROOT collection