npm module for your development needs.
The 🍐-to-🍐 commons helps make it easier to manage projects, by breaking them down into small, manageable pieces (i.e., modules). For example, research projects! No longer manage data, code, theory, results, and discussions through one another, but manage them separately and chronologically. This helps you trace back how you got to a certain result easily.
Our priorities are to implement the base functionality in this package. This helps provide consistency across the applications that will be built on the 🍐-to-🍐 commons, and make developing them much more efficient.
The key step is to provide a direct implementation of the 🍐-to-🍐 commons specifications, so you no longer need to worry about making sure everything is up to spec. In order to make good decisions about this, the 🍐-to-🍐 commons working group meets weekly to discuss progress. We manage all our decisions openly.
For a historical overview, please see the roadmap history.
Prioritized features for next release
Set (networking) options
This reads and sets the options for the Hypergraph application in accordance with the interoperability specification.
Implements the functionality to clone a module from the network not on the local machine yet.
Implements the functionality to write modules to the
follows property of profiles. This takes a valid Dat key referring to a p2pcommons module; valid modules may be followed using unversioned (follow) and versioned (freeze follow) keys.
Verify content module
Implements the two-sided verification of content modules. Iff the versioned content module's
authors all refer back to the versioned content module, the content is determined as verified. This implements both the verification function and the storage into the database (in accordance with the interoperability specification).
Implements local deletion of modules. This does not delete the module from other peers, simply from the local environment. This relates to modules that are writable to the user and delete a published content module from the profile. In other words, there are two methods:
- Delete module from local db
- Delete a published module from profile (not local db)
Next 3-6 months
Export/import private keys
Implements the retrieval of the Dat private key from the system, and saving it to a file for transferring to another machine. Conversely, it also provides a function to import the saved file back, when on another machine. It should not permit the duplication of private keys, because this causes conflicts (one set of private keys only available on one machine if we can help it).
Trawl modules to N degrees of separation (i.e., depth)
Given a content or profile module, retrieve all the Dat links in the metadata; then follow those Dat links and retrieve all the Dat links in the metadata; and so on for N times. A specific implementation restricts this to content modules and the
parents property (this is a traceback of content). Introduces index datetime into the local database for each cached module (a module may be cached at the latest version under
~/.p2pcommons/<hash> or at various versions
Create portal for profile module in index
Portals allow people to view the feed of another person. This is possible because the feed is composed of a trawl starting at a profile module. These feeds need to be stored in separate tables in the database.
Produce graph data in nodes + vertices format
Based on the metadata for each module, create graph data that indicates the relations between the nodes by decomposing these into nodes and their connections. This will produce a tab separated file and a key list to match node numbers to the modules. Further details will follow on the exact structure (here is a drawing of the concept, here an example dataset)