f4a7597c74467f0ed0ca75fd42323d325825deb5
Projects/xq/Concepts.md
| ... | ... | @@ -1,71 +0,0 @@ |
| 1 | -# 🍫 Zartbitter |
|
| 2 | - |
|
| 3 | -> An easy to use artifact repository that allows you to have a centralized deployment of things, with version support |
|
| 4 | - |
|
| 5 | -## Concept |
|
| 6 | - |
|
| 7 | -- Provide artifacts (files) via static storage (filesystem) |
|
| 8 | - - Serve files via HTTP(S), Gemini, ... |
|
| 9 | - - Files are stored in reasonable paths in the file system, either via links or as physical files |
|
| 10 | - - Artifacts should be accessible in a nice and human-friendly way. |
|
| 11 | - - Example: `download.random-projects.net/files/kristall-windows-x86_64-1.3.1-alpha.zip` |
|
| 12 | -- Artifacts and their paths are managed by the system |
|
| 13 | - - User can create new artifacts, but versions are determined by the upload |
|
| 14 | - - System uses [SemVer 2.0](https://semver.org/) for artifacts |
|
| 15 | - - The newest artifact will be served without a version appendix, making it easy to provide stable download links for the latest version |
|
| 16 | - - Nightly/prerelease versions can also be shared as "the latest prerelease" |
|
| 17 | - - Each artifact will be accompanied by a set of common hashes (md5, sha1, sha256) |
|
| 18 | - - Artifacts are immutable, no changes after an upload |
|
| 19 | -- Upload of artifacts happens via API tokens |
|
| 20 | - - Each **upload token** can update exactly a single artifact |
|
| 21 | - - Each **upload token** has an associated **security token** that is used to authenticate the upload |
|
| 22 | - - **upload token** can be PUBLIC |
|
| 23 | - - **security token** must be SECRET |
|
| 24 | - - Upload via HTTPS only, accompanied by a hash of the file for integrity verification as well as the mime type for the artifact |
|
| 25 | - - If the file version is uploaded the first time, the hashes will be computed and stored |
|
| 26 | - - Second upload will have its hash checked and verified. On mismatch, will return a **HTTP 409 Conflict** |
|
| 27 | -- Artifacts can be accessed either publicly or can be hidden behind an **access token** |
|
| 28 | -- Artifact metadata can be queried (same rules apply as accessing the artifact itself) |
|
| 29 | - - artifact name (without version) |
|
| 30 | - - canonical name (with version) |
|
| 31 | - - version |
|
| 32 | - - description |
|
| 33 | - - date of upload |
|
| 34 | - - hashes/checksums |
|
| 35 | - - size |
|
| 36 | - - mime type |
|
| 37 | -- Minimal requirement for uploading/updating artifacts should be a relatively simple `curl` request, to make deployment from basically any platform trivial |
|
| 38 | -- Allow creation of artifact indices |
|
| 39 | - - This should be designed as a plugin |
|
| 40 | - - Artifacts can be put into an "index", which is just a group of artifacts |
|
| 41 | - - Each index has a specialized rendering surface, so tools like `npm`, `NuGet` or others can use the index to get a list of all available artifacts (mostly packages in that case) |
|
| 42 | - |
|
| 43 | -## Implementation |
|
| 44 | - |
|
| 45 | -- As this is a pretty high-level application, an implementation in `dotnet` or `go` might be the right choice. |
|
| 46 | -- Uploads should be interlocked against each other, so they don't accidently override themselves |
|
| 47 | -- Data should be stored hybrid in a regular database (sqlite, mysql, ...) and the file system (blobs) |
|
| 48 | -- Artifact declaration should be easy, but doesn't require a "nice" frontend |
|
| 49 | - - Artifact declaration can be done with a "bad" web frontend, a regular yaml-like config file + diff might be the right choice here (example see below) |
|
| 50 | - - Alternative would be a very basic web frontend, doesn't even need special styling. This would require some kind of authentication. |
|
| 51 | - - Alternative would be a "EDITOR" styled CLI frontend, where user can use their text editor to edit a single artifact |
|
| 52 | - |
|
| 53 | -### Example for yaml file |
|
| 54 | - |
|
| 55 | -```yaml |
|
| 56 | -- name: "kristall-windows-x86_64.zip" |
|
| 57 | - description: "Windows-x64 standalone installation of the Kristall Small Internet Browser" |
|
| 58 | - access tokens: |
|
| 59 | - - "MVMOo7bOFSUeQhOcC2Dlhp2GhwazBfYIjaO0Vx4Vn/d1" |
|
| 60 | - - "fHIQ38OvQ2rvDcsU91vBvknTscZDePPDPnP9/5JoGgm6" |
|
| 61 | - uploaders: |
|
| 62 | - - public: "adN2sVOZgFwZ0DjDxrZ1MkRTovCsHZIQ+YRrajNNLr7v" |
|
| 63 | - security: "AjgCbq2LY/pe2JMJZ9Y2MsQflK2XUVQaWHxOurda7iKU" |
|
| 64 | - - public: "qvS4EsjvihTGAFsJt95NQ7H2hT2vKHhvWOy68f8UB02i" |
|
| 65 | - security: "IBCW4/O8FFPHW8UFex0zap+MMjmJX9eaRnCoNC4ersjW" |
|
| 66 | -- name: "pkgs/zig/zig-opengl.tar.gz" |
|
| 67 | - description: "Zig package for the zig-opengl repository." |
|
| 68 | - uploaders: |
|
| 69 | - - public: "2og5PyOjdh4+rpS9C3fGjwfTwckiEaTT5d7A+wPAfCkG" |
|
| 70 | - security: "8Jb1FVHmrVWnGRDxq7m2DTJCoZ1/WQkfMIx1gytvXXXQ" |
|
| 71 | -``` |
|
| 72 | 0 | \ No newline at end of file |