### Replication Policies

In the section above, we mentioned a "seeding policy". In this section, we will

talk about two kinds of policies: [seeding policies](#seeding-policy) and

[follow policies](#follow-policy).

#### Seeding Policy

Seeding policy refers to a local configuration per Repository ID (RID) and

affects how repositories are replicated.

A seeding policy can be broken down into two components:

1. *Policy*: whether the node allows or blocks the repository from being

fetched and can either be set to `allow` and `block`. If a seeding policy is

set to `block`, then the repository is ignored, rather than fetched.

2. *Scope* can be one of two values: `all` or `followed`:

   * `all`: the references of *all* peer's namespaces within a repository are fetched.

   * `followed` : only the references from your [followed](#follow-policy) peers

     are fetched.

In both cases, the delegates of the repository are also fetched. These peers are

privileged since the state of the repository's identity and the default branch

are decided by these peers.

#### Follow Policy

A follow policy refers to a policy that affects a peer. Similarly to a seeding

policy, it can either be `allow` or `block`, but it does not require a scope.

As mentioned above, this affects the references that are being fetched within a

repository. When a seeding policy's scope is `followed`, the set of followed

peers, who are `allow` are retrieved.

Conversely, in all cases above, if a peer's policy is set to `block` their

references are never fetched.