Architecture Overview

EFS Architecture Overview

EFS at its core is a hierarchical structure of folders and data implemented on top of a property graph. Users access data through a static HTML, CSS, JS Web App hosted on IPFS that connects to the blockchain via a user's wallet, RPC endpoint, or a light client.

Property Graph

EFS utilizes a property graph model which allows for the storage of data in a graph structure with nodes representing entities, and edges representing the relationships between these entities. Each node and edge can have associated properties that store data in key-value pairs.

Nodes

• Represent an idea or community
• Controls its property values and types
• Has associated properties/files/data in the form of key-value pairs

Edges

• Represent relationships between nodes
• Can have properties that describe the nature of the relationship
• Edges can be either single statuses like James -> "Follows" -> Vitalik or an array of events such as instances of James -> "Met IRL".ETHDenver -> Vitalik

Types

EFS has a type system which allow developers to share and interoperate with data

Node types

A node has a type which determines that properties it must have values for and which developers can depend on

Example types:

• Base - All types extend from Base
  • .name, .description which are i18n'ed strings
  • Timestamps for created, edited
  • Nonce
  • Versions
• Node extends Base - Basic unit of EFS
  • Contains properties and edges
• Directory extends Node - A "thing"/idea/DAO
• Edge extends Node - Has extra references to the outgoing and incoming nodes of a relationship

Protocols

Applications interact with nodes via protocols. Fundamental EFS components such as the files list, subdirectories, relationships are also protocols.

Protocols:

• Represent edges on the graph
• are on the /p/ || /protocols/* list
• Define requests the user can take. Example for HTTP protocol: GET, POST, PUT, DELETE, etc.
• Requests:
  • Are subdirectory in /p/<id> folder
  • Contain ERC-165 interface definitions for a smart contract to perform the requested action
  • Take in arbitrary parameters
  • Must return content-type + content
  • Default requests all protocols must implement? are CRUD - Create, Read, Update, Delete
• Are immutable but can append new versions
• Will be on system controlled list (that user can override if necessary via editions). There will be a governance process to add new protocols.
• Have a node type with defined properties clients can rely on

Important protocols:

• Properties
  • Request: List
    • This is the list of "files" in a "directory"
    • Are mapped directly to simple node.property queries via Cypher or GQL. Key = Simple value (usually string)
• Subdirectories
  • Request: List
    • These are child nodes which this node owns/administers/is superset of
    • Child nodes control their own data but configuration reads start at child and bubble up to parent nodes until a value is found

Editions

The chain is a single data resource that is shared by billions of people. Editions allow one namespace to be shared amongst all users. Each user can publish their view of the information in EFS. Each node may have an edition specified by a user.

Editions:

• Provide a certain address's perspective on data
• Allow the user to upgrade and customize parts of the system
• Allow DAOs to provide a version of the entire system or certain directories or files

EFS Client Overview

The default shell for EFS is a static web app hosted on IPFS.

UI for paths

Path is up top like URL bar, a new section underneath for each protocol the user views for this path
Example UI using the file list and subdirectory protocols:

=                   Path Row                      =
= File list                   | Subdirectory list =

Settings such as filters etc are in hamburger menu to left of path row