-
Notifications
You must be signed in to change notification settings - Fork 2
Registries
Draft for a future registries overview
Refine + unify language about registries vs collection servers
An Underlay registry is a collection server with [a web interface, a way of dealing with users, other policies]
A registry is a catalog of packages/collections and interfaces that provide information about them.
To resolve collection names, the Underlay talks to a registry.
Registries must implement [the underlay registry spec] for reading collection information, and can also support interfaces for publishing collections, managing information about collections and users, and more.
Underlay tools are configured by default to use the public registry-index at registry.underlay.org. The first registry is R1.
A default registry is maintained at r1.underlay.org, including a common set of public collections.
[summary of r1.ul.org interfaces + policies] [summary of collections]
[summary of the code it runs] [link to repo + design doc]
[replicate the code + design of the default registry?] [indicate design to allow this]
Every collection has a unique URI managed by its parent registry, with a human-readable collection-name_ as the last path element of the URI, with no query or fragment components.
A URL path to a registry is given as the @base context for JSON-LD data, so that collections can be referenced within that context as "@id": "collection-name"
Metadata [associated with] collections is used to identify the requested version of a collection, and associated dependencies.
[how to inspect metadata about a [version of a] collection]
Common metadata fields include {name, versions, authors, maintainers, license, URIs, creation time, update times}
A collection can be published to a registry [describe] using a command line tool [link] or from a local collection server.
Most registries have an HTTP interface, and collections can also be published through the registry's own web site.
Successfully publishing a collection to a registry (registries implement policies which may impose filters or approval steps) will [pin the collection and metadata describing the collection] to the registry. If a registry has a distribution arrangement with others, this may add the collection to the relevant collaborative cluster.
Collections can be tagged by others (curators) with descriptions or keywords [or other relations?].
Changes to a collection or its metadata should update its version.
Collections should list a maintainer, signer, and sources where possible.
[managing collection information]
[managing collection maintainers]
[versioning]
[signing]
[deprecation]
[unpublishing and unpinning]
[inspecting metadata]
[reading a collection]
[installing/adding to your local collection server]
[Pinset orchestration: getting a quick local copy, joining a collaborative cluster]
The root of each collection server can be a root that others can add or update from
[creating an account; logging in]
[OAuth and alternatives]