diff --git a/proposals/images/harbor-satellite/use-case-1.png b/proposals/images/harbor-satellite/use-case-1.png
new file mode 100644
index 00000000..ea857584
Binary files /dev/null and b/proposals/images/harbor-satellite/use-case-1.png differ
diff --git a/proposals/images/harbor-satellite/use-case-2.png b/proposals/images/harbor-satellite/use-case-2.png
new file mode 100644
index 00000000..f4555aef
Binary files /dev/null and b/proposals/images/harbor-satellite/use-case-2.png differ
diff --git a/proposals/images/harbor-satellite/use-case-3.png b/proposals/images/harbor-satellite/use-case-3.png
new file mode 100644
index 00000000..03c06300
Binary files /dev/null and b/proposals/images/harbor-satellite/use-case-3.png differ
diff --git a/proposals/new/harbor-satellite-proposal.md b/proposals/new/harbor-satellite-proposal.md
index 3b84ef4f..655c6ded 100644
--- a/proposals/new/harbor-satellite-proposal.md
+++ b/proposals/new/harbor-satellite-proposal.md
@@ -1,8 +1,6 @@
# Proposal: `Harbor Satellite`
-Authors: Vadim Bauer / [Vad1mo](https://github.com/Vad1mo), Csaba Almasi, Philip Laine, Roald Brunell / [OneFlyingBanana](https://github.com/OneFlyingBanana), (David Huseby, ...?)
-
-
+Authors: Vadim Bauer / [Vad1mo](https://github.com/Vad1mo), Csaba Almasi, Philip Laine, David Huseby / [dhuseby](https://github.com/dhuseby), Roald Brunell / [OneFlyingBanana](https://github.com/OneFlyingBanana)
## Abstract
@@ -31,7 +29,7 @@ Deploying a complete Harbor instance on edge devices in poor/no coverage areas c
- Harbor wasn't designed to run on edge devices.(e.g. Multiple processes, no unattended mode)
- Harbor could behave unexpectedly in poor/no connectivity environments.
- Managing hundreds or thousands of container registries is not operationally feasible with Harbor
-- (What is the difference to a registry mirror?)
+- Harbor would be too similar to a simple registry mirror
Harbor Satellite aims to be resilient, lightweight and will be able to keep functioning independently from Harbor instances.
@@ -41,17 +39,51 @@ Compatibility with all container registries or edge devices can't be guaranteed.
## Implementation
-Harbor Satellite will run in a single container and will be divided in the following components :
+### Overall Architecture
+
+Harbor Satellite, at its most basic, will run in a single container and will be divided in the following 2 components :
- **Satellite Core** : pulling/pushing images from/to Harbor (using go-libp2p?) and pulling/pushing images from/to the local registry (using Skopeo and/or Crane?).
- **Registry Proxy** : storing required OCI artifacts locally (using zotregistry or docker registry?).
-
+
-Harbor Satellite Diagram
+Basic Harbor Satellite Diagram
-## Open issues (if applicable)
+### Specific Use Cases
+
+Harbor Satellite may be implemented following 1 or several of 3 different architectures depending on its use cases :
+
+1. **Replicating from a remote registry to a local registry.**
+In this basic use case, the stateless satellite component will handle pulling images from a remote registry and then pushing them to the local OCI compliant registry. This local registry will then be accessible to other local edge devices who can pull required images directly from it.
+_(A direct access from edge device to the remote registry is still possible when network conditions permit it)._
+The satellite component may also handle updating container runtime configurations and fetching image lists from Ground Control, a part of Harbor.
+The stateful local regsitry will also need to handle storing and managing data on local volumes.
+
+
+Use case #1
+
+2. **Replicating from a remote regsitry to a local Spegel Registry**
+The stateless satellite component send pull instructions to Spegel instances running with each node of a Kubernetes cluster. The node will then directly pull images from a remote registry and share it with other local nodes, removing the need for each of them to individually pull an image from a remote registry.
+
+
+Use case #2
-Harbor Satellite aims to manage, coordinate and schedule containers using a Kubernetes cluster.
+3. **Proxying from a remote regsitry over the local registry**
+The stateless satellite component will be in charge of configuring the local OCI compliant registry, which will be running in proxy mode only. This local registry will then handle pulling necessary images from the remote registry and serving them up for use by local edge devices.
-Harbor Satellite also aims to use and benefit from Spegel, a registry mirror designed to optimize the pulling of container images within a Kubernetes cluster.
+
+Use case #3
+
+### Consumer Configuration
+
+In each of these use cases, we need to ensure that consumers will be able to access the registry and pull images from it. To solve this issue, we propose 4 solutions :
+
+1. By using **containerd** or **CRI-O** and configuring a mirror within them.
+2. By setting up an **HTTP Proxy** to manage and optimize pull requests to the registry.
+3. By **directly referencing** the registry.
+4. By **directly referencing** the registry and using Kubernetes' mutating webhooks to point to the correct registry.
+
+## Open issues (if applicable)
+
+T.B.D.