New Rust re-write

[Stridsvagn69420]

This will introduce the Rust re-write with v1.2.0, the managaement tools and obviously the hot new stuff as well as a re-write of the Wiki and better docs.

• Closes #20 both in terms of codebase and also in terms of documentation.
• Resolves #17 and the easier management of metadata files and registered owners.

Checklist

• [x] Root crate documentation
• [x] Impl for Artist
• [x] Constructor for Artist
• [x] Impl for Album
• [x] Constructor for Album
• [x] Impl for Config
• [x] Wrappers/utils for Config
• [x] Impl for Hostinfo
• [x] Wrappers/utils for Hostinfo
• [x] Impl for Metadata
• [x] Constructor/utils for Metadata
• [x] Impl for Owner
• [x] Constructor for Owner

And then obviously the server stuff:

• [x] Meta headers (license, source code, Server Version)
• [x] Meta redirects (e.g. source code)
• [x] CORS everywhere
• [x] Hostinfo generator
• [x] Hostinfo and file serving routes with optional Basic Auth (directory listing will be simple <a href="filename.mp3">filename.mp3</a> stacks)

---

In the end, both cyrkensia and cyrkensia-cfg binaries should be finished in order to merge this PR!

• [ ] cyrkensia - the Cyrkensia server
• [ ] cyrkensia-cfg - tool for managing Cyrkensia-related files and folders

[Stridsvagn69420]

Only the Server Routes and Root Docs needed now!

[Stridsvagn69420]

...for the raw library of course, not the binaries. But still, pretty neat!

[Stridsvagn69420]

Use actix-web shared state for the routes. Probably use a trait for it if possible.

Basically what's missing:

• [x] Shared state via Actix-Web (Hostinfo, Config, hostinfo timestamp, Htpasswd HashMap)
• [x] CORS everywhere (via middleware)
• [x] Password authentication (in file serving, via shared state)
• [x] The damn file serving routes
• [x] (NEW) Multiple root paths in config

[Stridsvagn69420]

The Password Authentication thingy will be done in the 3rd point on the checklist.

[Stridsvagn69420]

For file serving: remember to include the SHA-256 hash of the file in the headers. Maybe only on HEAD requests, I'll have to see.

[Stridsvagn69420]

Use this for .htpasswd auth https://crates.io/crates/htpasswd-verify and maybe also allow multiple Auth files The entries will be stored in a HashMap or BTreeMap. HashMap is the one I'm more familiar with and a BTreeMap might be slower with a lot of user accounts. I'll have to see.

[Stridsvagn69420]

Actually, use a HashSet for this.

[Stridsvagn69420]

Basically, load the htpasswd file line by line and use htpasswd_verify::load() for every line, then add the result to a HashSet that will be stored in the CyrkensiaState.

[Stridsvagn69420]

And then for the look up: just iterate over it, probably linear.

Maybe a HashMap will be better, but I'll implement the HashSet variant first.

[Stridsvagn69420]

Actually, perhaps completely dismiss the Htpasswd thingy and just do a username-password store in JSON (the password being SHA-256 hashed of course) that will be used as a HashMap.

Here's the crate: https://crates.io/crates/sha256

[Stridsvagn69420]

Only the file index and then actual file serving is missing. Thankfully these will be just two route functions, one for index, one for files. Plus there are the index response (basically just formatting) and a 401 error response, similar to the sever_500() response.

Also, the file serving route should always include the size in the header, but also the SHA-256 and BLAKE3 hashes when there's a HEAD request (authentication has to be successful for this; if it isn't, always return the 401 response).

[Stridsvagn69420]

Using BLAKE3 is a good idea ...for checksums though. I'll switch the password hashing to argon2 asap. BLAKE3 will still be used to create the file checksums, and SHA-256 will be removed.

[Stridsvagn69420]

Apart from bundling everything together as an executable and testing everything, only the file serving with the HEAD meta and optional HTTP Basic Auth is missing!

[Stridsvagn69420]

Aw shit, I made an "it's 2 AM and I'm sick and tired"-oopsies

• [x] It should read from the config's roots and check where that folder is.

[Stridsvagn69420]

It's only the actual fileserving-basicauth-headmeta route thingy now.

[Stridsvagn69420]

I should probably also remake the wiki before this gets merged...

[Stridsvagn69420]

Header stuff for the file serving:

• ETag and Digest headers will contain BLAKE3 hash
• Last-Modified header will use file metadata for time
• Implement If-Modified-Since header behavior (client can send request with date to check if new data has to be downloaded) And HEAD request will only be exclusive to the fact that you can get the file size and the other metadata without actually dealing with megabytes or even gigabytes of wasted data. Plus, I want the HTTP codes to align with that's actually happening. So 200 for everything normal and 304 for when there's nothing new.

I have the feeling Actix-Web already does a lot of things for you, but I want to be sure and implement it my way, plus only something like the Actix-Web-Static-Fileserver thingy can really do things like hashing, ETag and Last-Modified, plus there's the user authentication (without auth, it won't send any information). I originally also wanted to cache all of these things, but BLAKE3 is blazingly fast and the other caching mechanics get near the level of what NGINX and Apache can kindly do for you.

[Stridsvagn69420]

Random stuff, but make the digest and partial content thing a middleware (has to be combined because digest depends on content).

[Stridsvagn69420]

Honestly, I might just make a new Rust rewrite. I wrote it down on the Nucleus server, so time to post it here too.

---

was messing around with GTA's Self Radio, FFmpeg, audio codecs and tags in audii files, and I might make a rust-new-version of my WIP rust-version of Cyrkensia

you see, aside from having to redo most things because mixing basic file serving, sending metadata and password protecting everything together being complicated, I might do the storing part different

1. I'll probably use SQL and will give the option to use SQLite or RDBMS. There will still be a config file in Json, but it's very simple. The database will have tables for: -maintainers and server admins -user database (Auth can be toggled in settings) -soundtrack table (lots of metadata and the filesystem info, maybe also hashes for integrity and stuff)
2. I'll keep the current updating system for the soundtrack table btw, but the idea is that instead of having 300 MB of hostinfo.json, there will be a REST api endpoint for getting the file metadata and in general to know what the server even offers and 3. (I forgot this because slewpy) there should be a little tool that updates the files' tags baaed on the database

I have a more elaborate version on this now. So, I'm gonna make it based on the current architecture, BUT the hostinfo won't be so fucking huge anymore. It merely lists the audio files, maybe even just the groups (what I called albums), and of course the server meta. And then there's another endpoint, the songinfo, that allows the client to read more data about a file. And this part just reads the available data from the database (probably SQL then). The database can be manually filled, but if you already have metadata on your file, another tool tries to write it to the database on command. Idk if I will include caching, probably yes if I figure out how.

So things will get debloated and the architecture will get better too. I just have to find time when I can actually do it, school and stuff you know.

[Stridsvagn69420]

Auth and Content hashing meta thingy will most likely be a middleware btw.

[Stridsvagn69420]

Gonna rewrite the entire thing again...