~ivilata/gwit-spec

f06be2febc2f0da2b2042b8631f8f3a2e2304691 — Ivan Vilata-i-Balaguer 6 months ago 1c112c6
Move intro paragraph on petnames closer to intro to site IDs.

Since petnames are used to avoid dealing with site IDs.
1 files changed, 2 insertions(+), 2 deletions(-)

M README.md
M README.md => README.md +2 -2
@@ 53,13 53,13 @@ A gwit site is just *a Git repository branch associated with a PGP public key* w

This means that the relation between site and site key is one-to-one: if an author wants to create another site, then a new site key MUST be created. Thus, using one's day-to-day PGP key as a site key is NOT RECOMMENDED. The mechanisms to relate a site (and its key) to a particular identity outside of gwit are out of the scope of this specification.

To get content from a site, one needs to access an existing copy of it. That copy MUST be a Git repository, and its location MUST be expressed as a URL allowed by Git for a remote. Though the URL is opaque to gwit (e.g. it may use whatever Git-supported protocol), the associated remote SHOULD be accessible without external credentials like passwords.

As gwit site identifiers are not meaningful nor memorable to humans, some support is provided to allow using **petnames** for sites. This specification uses the concepts of petname, edge name, and (self-)proposed name from the paper [Petnames: A humane approach to secure, decentralized naming][petnames].

[petnames]: https://spritely.institute/static/papers/petnames.html
    "Petnames: A humane approach to secure, decentralized naming (Spritely Institute)"

To get content from a site, one needs to access an existing copy of it. That copy MUST be a Git repository, and its location MUST be expressed as a URL allowed by Git for a remote. Though the URL is opaque to gwit (e.g. it may use whatever Git-supported protocol), the associated remote SHOULD be accessible without external credentials like passwords.

Since gwit is based on Git, a gwit site is made up of *static files and directories*. Except for a few files with site metadata (described below), the specification does not mandate any structure or file types.

**Note:** As an example of how to bind the author's day-to-day key to a particular site, the latter may include some statement, signed by the author's day-to-day key, claiming ownership of the site key by its fingerprint. Or following the [Ariadne Identity Specification][AIS], the day-to-day key may include an identity claim with a gwit URI pointing to a file in the site that contains an identity proof for the key.