about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* media: media endpoint PoCVika2022-07-108-154/+350
| | | | | | | | | | Supported features: - Streaming upload - Content-addressed storage - Metadata - MIME type (taken from Content-Type) - Length (I could use stat() for this one tho) - filename (for Content-Disposition: attachment, WIP)
* .envrc: watch shell.nix for changesVika2022-07-071-0/+1
|
* .envrc: update nix-direnv install invocationVika2022-07-071-3/+6
|
* Add rustfmt to shell.nixVika2022-07-071-2/+2
|
* format using rustfmtVika2022-07-0712-202/+228
|
* treewide: rewrite using AxumVika2022-07-0718-2859/+2075
| | | | | | | | | | | | | | Axum has streaming bodies and allows to write simpler code. It also helps enforce stronger types and looks much more neat. This allows me to progress on the media endpoint and add streaming reads and writes to the MediaStore trait. Metrics are temporarily not implemented. Everything else was preserved, and the tests still pass, after adjusting for new calling conventions. TODO: create method routers for protocol endpoints
* flake.lock: UpdateVika2022-07-071-9/+9
| | | | | | | | | | | | | | Flake lock file updates: • Updated input 'flake-utils': 'github:numtide/flake-utils/f7e004a55b120c02ecb6219596820fcd32ca8772' (2021-06-16) → 'github:numtide/flake-utils/7e2a3b3dfd9af950a856d66b0a7d01e3c18aa249' (2022-07-04) • Updated input 'naersk': 'github:nmattia/naersk/f21309b38e1da0d61b881b6b6d41b81c1aed4e1d' (2022-05-03) → 'github:nmattia/naersk/cddffb5aa211f50c4b8750adbec0bbbdfb26bb9f' (2022-06-12) • Updated input 'nixpkgs': 'github:nixos/nixpkgs/dfd82985c273aac6eced03625f454b334daae2e8' (2022-05-20) → 'github:nixos/nixpkgs/71a4f0dc3d80ba76f437c888c1c3d59f1df98163' (2022-07-05)
* feat: group endpoints under `.kittybox`Vika2022-06-026-74/+57
| | | | | Actually got the idea from https://xeiaso.net/, who groups xer website's endpoints under the `.within` folder.
* direnv: move .envrc to kittybox-rsVika2022-05-281-0/+0
|
* frontend: fix onboarding sending the request to the wrong placeVika2022-05-261-2/+2
|
* flake.nix: move the devShell into its own fileVika2022-05-262-13/+20
|
* Remove redundant naersk-lib overrideVika2022-05-262-6/+5
|
* flake.nix: reorganizeVika2022-05-2441-281/+275
| | | | | | | | | | | | - Kittybox's source code is moved to a subfolder - This improves build caching by Nix since it doesn't take changes to other files into account - Package and test definitions were spun into separate files - This makes my flake.nix much easier to navigate - This also makes it somewhat possible to use without flakes (but it is still not easy, so use flakes!) - Some attributes were moved in compliance with Nix 2.8's changes to flake schema
* flake.nix: use rustc from nixpkgs every timeVika2022-05-242-60/+6
|
* flake.lock: UpdateVika2022-05-241-4/+4
| | | | | | | | Flake lock file updates: • Updated input 'nixpkgs': 'github:vikanezrimaya/nixpkgs/bf819aeeb2f0954506a748ff117962edc8cf732d' (2022-03-28) → 'github:nixos/nixpkgs/dfd82985c273aac6eced03625f454b334daae2e8' (2022-05-20)
* flake.nix: make a test for distributed KittyboxVika2022-05-242-4/+105
| | | | | | | | | | | I said some boastful words about Kittybox being able to horizontally scale and I wanted to prove them. This is the proof. This test creates an NFS file server, then spawns three VMs. Provisioning a website on one of them, it then queries the website on all of the three machines. This shows that a shared backing store can make Kittybox infinitely scale horizontally depending on how much traffic you're getting.
* gitignore: ignore token fileVika2022-05-231-0/+1
|
* templates: prepare for facepiles a bit betterVika2022-05-231-16/+29
| | | | | | | | This bit of code is still disabled for now though. I need to actually gather and render facepiles. Additionally, now details won't even show if there were no reactions to the post, which saves space.
* templates: render like and bookmark posts correctlyVika2022-05-232-1/+109
| | | | | | | | | | | | | They really use the same framework, so for now a unit test for like posts is sufficient. Of course, for proper coverage, one can introduce tests for bookmarks too, especially if one chooses to render them differently. The logic will be pretty much the same though. Replies might use the same logic, since those are also Webmention-oriented posts. (It looks like another way to classify MF2 documents is slowly forming in my brain. Maybe I should write about it on my blog.)
* templates: simplify logicVika2022-05-231-24/+29
| | | | | | | There were lots of unneccesary Option::unwrap() invocations that could be replaced with `if let` statements. This makes the code cleaner and less likely to panic in case a corrupted, incomplete or manually injected MF2-JSON document needs to be rendered.
* templates: add a banner for Kittybox in the footerVika2022-05-232-0/+10
| | | | Now everyone will know where to get my software if they see it.
* templates: add unit test for articlesVika2022-05-231-45/+116
| | | | | | It mostly checks the same old things as with notes, but does check for a name (and as it's explicitly provided, it does work with the buggy version of the `microformats` crate.
* templates: more MF2 generatorsVika2022-05-231-5/+62
| | | | | | | | | | New generators include: - Articles (h-entry with a name) - Replies (notes with an in-reply-to) - Likes (h-entries with a like-of) For replies and likes, there are variants with an h-cite (full reply context) or a link (partial reply context).
* templates: introduce unit testsVika2022-05-233-0/+165
| | | | | | | | | | | | | | | These unit tests generate a random MF2-JSON post, convert it to MF2-HTML using the template and then read it back using the `microformats` crate. The only problem is that it has a nasty bug with overstuffing implied properties. This is being worked on: https://gitlab.com/maxburon/microformats-parser/-/issues/7 For now the tests marked as ignored because they fail. But the function itself that generates them should remain here for documentation and potential code sharing with the `microformats` crate, potentially even migrating to a subcrate there.
* chore: code cleanup in main.rsVika2022-05-141-8/+6
|
* feat: webmention sending and reply context enrichmentVika2022-05-142-45/+161
| | | | | | | These features share some code since they both require fetching reply contexts, so it makes sense to implement them together. TODO cover webmention sending with integration tests
* flake.nix: fix maintainer entryVika2022-05-131-1/+1
|
* nixos-test: use proper content-type for onboardingVika2022-05-131-1/+1
| | | | | | It looks like previous versions did not check Content-Type and I was able to get away with it. Warp is much more strict in that regard (and it is good).
* README.md: initVika2022-05-131-0/+107
|
* flake.nix: push kittybox to checks so Hydra will show it separatelyVika2022-05-131-0/+1
|
* Cargo.toml: fix Nix builds in restricted modeVika2022-05-122-99/+80
|
* treewide: prepare for mf2 parsing and cleanup unused codeVika2022-05-126-193/+486
|
* database, frontend: code cleanup so clippy doesn't complainVika2022-05-103-22/+20
|
* FileStorage: only compile tests when neededVika2022-05-101-0/+1
|
* FileStorage: fixes and regression tests for read_feed_with_limitVika2022-05-104-49/+161
| | | | Now I will know if something breaks horribly again.
* FileStorage: fix the item in `after` being emitted as the firstVika2022-05-101-8/+11
| | | | | | Iterator::skip_while() returns the last item. Reimplement the combinator that I need using a loop over Iterator::by_ref() instead. This will terminate after the end is reached.
* FileStorage: code cleanupVika2022-05-101-14/+11
|
* FileStorage: fix the hang when "after" isn't listed in the feedVika2022-05-101-9/+8
| | | | Closes #4.
* media: move to separate subtreeVika2022-05-104-51/+48
| | | | | | | | This will ease future extraction of the media endpoint to a separate crate. This is highly desirable since it will allow Kittybox's media endpoint to be used separately in instances where a standalone media endpoint is desirable (e.g. custom solutions using my code to polyfill for desired functionality that is undesirable to implement by oneself)
* dev.sh: optional cargo-watch and systemfd supportVika2022-05-071-3/+11
|
* Don't enable tokio-console support in productionVika2022-05-071-0/+1
|
* flake.nix: fix build and clean upVika2022-05-071-6/+8
| | | | | | | | | - Somehow it looks like zlib is required, but wasn't passed - Log level in the test is set to (mostly) info - A needless comment is deleted - Single-step build is enabled. Since this is a multi-crate workspace now, naersk will not offer much in terms of incrementality (and I use `nix develop` anyway with a dev-shell)
* main.rs: clean up some dumb stuffVika2022-05-071-8/+6
| | | | | Match blocks and ifs are actually perfectly usable as expressions. I forgot about that when writing that code.
* Split into different cratesVika2022-05-0713-60/+117
| | | | | | | | | Templates and utility types are now separate crates to speed up compilation, linting and potential reuse/replacement. Potentially more crates could be split out/modularized, resulting in speedups, smaller binaries (whenever features are excluded) and even more reuse capabilities.
* flake.nix: use rustc from nixpkgs on release buildsVika2022-05-051-2/+1
|
* flake.lock: UpdateVika2022-05-051-7/+7
| | | | | | | | | | | | | | Flake lock file updates: • Updated input 'naersk': 'github:nmattia/naersk/8cc379478819e6a22ce7595a761fe1e17c8d7458' (2022-04-16) → 'github:nmattia/naersk/f21309b38e1da0d61b881b6b6d41b81c1aed4e1d' (2022-05-03) • Updated input 'nixpkgs': 'github:kisik21/nixpkgs/bf819aeeb2f0954506a748ff117962edc8cf732d' (2022-03-28) → 'github:vikanezrimaya/nixpkgs/bf819aeeb2f0954506a748ff117962edc8cf732d' (2022-03-28) • Updated input 'rust': 'github:oxalica/rust-overlay/26b570500cdd7a359526524e9abad341891122a6' (2022-04-17) → 'github:oxalica/rust-overlay/88991ffbd57e10b474ea768ec0b54c4f379c566c' (2022-05-04)
* Cargo.lock: updateVika2022-05-031-413/+535
|
* chore: code cleanupVika2022-05-013-66/+6
|
* FileStorage: fix writing settings on empty fileVika2022-05-011-8/+12
|
* FileStorage: lockless reads and atomic writesVika2022-05-012-221/+161
| | | | | | | | | | | | | | | | | | | - Reads don't lock anymore. At all. - Writes create a temporary file and use `rename(2)` to atomically replace it - since OpenOptions::create_new(true) is used, tempfile creation is atomic (and since tempfile names are per-post, a post can only be edited by one request at a time) - Since written files get atomically replaced, readers can't read a corrupted file Potential pitfalls: 1. This approach is not covered by unit tests (yet) 2. Stale tempfiles can prevent editing posts (can be solved by throwing out tempfiles that are older than, say, a day) 3. Crashed edits can leave stale tempfiles (honestly that sounds better than corrupting the whole database, doesn't sound like a bug to me at all!)
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-23 06:06:39 +0000