Corestore
stable
Corestore is a Hypercore factory that makes it easier to manage large collections of named Hypercores. It is designed to efficiently store and replicate multiple sets of interlinked Hypercore
(s), such as those used by Hyperdrive
, removing the responsibility of managing custom storage/replication code from these higher-level modules.
Installation
Install with npm:
API
const store = new Corestore(storage, [options])
const store = new Corestore(storage, [options])
Creates a new Corestore instance.
storage
can be either a random-access-storage module, a string, or a function that takes a path and returns a random-access-storage instance.
options
can include:
const core = store.get(key | { key, name, exclusive, [options] })
const core = store.get(key | { key, name, exclusive, [options] })
Loads a Hypercore, either by name (if the name
option is provided), or from the provided key (if the first argument is a Buffer or String with hex/z32 key, or if the key
option is set).
If that Hypercore has previously been loaded, subsequent calls to get
will return a new Hypercore session on the existing core.
If the exclusive
option is set and a writable session is opened, it will wait for all other exclusive writable to close before opening the Hypercore. In other words, any operation on the core will wait until it is exclusive.
All other options besides name
and key
and exclusive
will be forwarded to the Hypercore constructor.
The names provided are only relevant locally, in that they are used to deterministically generate key pairs. Whenever a core is loaded by name, that core will be writable. Names are not shared with remote peers.
const stream = store.replicate(options|stream)
const stream = store.replicate(options|stream)
Creates a replication stream that's capable of replicating all Hypercores that are managed by the Corestore, assuming the remote peer has the correct capabilities.
options
will be forwarded to Hypercore's replicate
function.
Corestore replicates in an 'all-to-all' fashion, meaning that when replication begins, it will attempt to replicate every Hypercore that's currently loaded and in memory. These attempts will fail if the remote side doesn't have a Hypercore's capability -- Corestore replication does not exchange Hypercore keys.
If the remote side dynamically adds a new Hypercore to the replication stream (by opening that core with a get
on their Corestore, for example), Corestore will load and replicate that core if possible.
Using Hyperswarm
one can replicate Corestores as follows:
As with Hypercore, users can also create new protocol streams by treating options
as the isInitiator
boolean and then replicate these streams over a transport layer of their choosing:
const store = store.namespace(name)
const store = store.namespace(name)
Creates a new namespaced Corestore. Namespacing is useful for sharing a single Corestore instance between many applications or components, as it prevents name collisions.
Namespaces can be chained:
Namespacing is particularly useful if an application needs to create many different data structures, such as Hyperdrive
s, that all share a common storage location:
const session = store.session([options])
const session = store.session([options])
Creates a new Corestore that shares resources with the original, like cache, cores, replication streams, and storage, while optionally resetting the namespace, overriding primaryKey
. Useful when an application needs to accept an optional Corestore, but needs to maintain a predictable key derivation.
options
are the same as the constructor options:
Last updated