| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
When testing things, I don't test TLS verification, that's what
reqwest unit tests should exist for. I test my things, and some of my
things assume some form of TLS. I don't need it to be valid TLS, I
need it to be TLS so I can use the `https://` links in dev.
|
|
|
|
|
|
|
| |
I think I managed to not lose any functionality from my dependencies.
sqlparser remains unupgraded, but that's mostly because it is only
used in one example and it's not worth it to upgrade right now.
|
| |
|
|
|
|
|
|
|
|
| |
Since Kittybox router composition is entirely generic, we can move it
into the library.
I feel like I could also split database types into their own crates,
too.
|
| |
|
|
|
|
|
| |
This somehow allowed me to shrink the construction phase of Kittybox
by a huge amount of code.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
| |
Match blocks and ifs are actually perfectly usable as expressions. I
forgot about that when writing that code.
|
| |
|
|
|
|
| |
It's an advanced HTTP client that can do more than vanilla Hyper does.
|
|
|
|
|
|
| |
Now Kittybox can gracefully shutdown on SIGTERM. Nice!
TODO: consider shutting down on multiple signals
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Warp allows requests to be applied as "filters", allowing to flexibly
split up logic and have it work in a functional style, similar to
pipes.
Tokio is just an alternative runtime. I thought that maybe switching
runtimes and refactoring the code might allow me to fish out that
pesky bug with the whole application hanging after a certain amount of
requests...
|
| |
|
|
|
|
|
|
|
| |
This will allow readers to view private posts intended just for them.
Additionally fixed bugs in patterns due to which webmentions might not
have been sent.
|
| |
|
| |
|
|
|
|
|
|
| |
Now the Redis dependencies are optional and only required if you want
to test the backend or actually use it in production. The app displays
a hint if you try to launch with an unsupported backend.
|
| |
|
|
|
|
|
|
|
|
| |
The internal token is a shared secret that can update and delete any
posts stored in the database. It is intended for use in webmention
endpoints to update posts with latest webmentions.
Please keep it safe.
|
| |
|
|
|
|
|
|
|
|
|
| |
The new tools are:
- kittybox-bulk-import, a bare-bones Micropub client that reads a JSON
list of posts and then sends them one by one to the Micropub endpoint
- pyindieblog-export, my personal tool which directly connects to
Pyindieblog's redis instance and extracts data from it in JSON format
suitable for use with kittybox-bulk-import.
|
| |
|
|
|
|
| |
APIs and preparation for onboarding
|
| |
|
|
Working features:
- Sending posts from the database
- Reading posts from the database
- Responding with MF2-JSON (only in debug mode!)
- Not locking the database when not needed
- All database actions are atomic (except for a small race where UIDs
can clash, but that's not gonna happen often)
TODOs:
- Send webmentions
- Send syndication requests
- Send WebSub notifications
- Make tombstones for deleted posts (update adding dt-deleted)
- Rich reply contexts (possibly on the frontend part?)
- Frontend?
- Fix UID race
Code maintenance TODOs:
- Split the database module
- Finish implementing the in-memory test database
- Make RedisDatabase unit tests launch their own Redis instances (see
redis-rs/tests/support/mod.rs for more info)
- Write more unit-tests!!!
|