| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
| |
A single giga-commit that took me weeks to produce. I know, this is
not exactly the best thing ever — but I wanted to experiment first
before "committing" to the implementation, so that I would produce the
best solution.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This neccesitates installing TypeScript to build Kittybox, but
thankfully Nix actually takes care of that. Build Kittybox with Nix
and you won't have problems.
Also now I can safely do stuff.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
| |
- 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)
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This is so minimal it can't be much less than this.
Use it with `docker load`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
require_token() uses a token endpoint URI and an HTTP client to query
the token endpoint and return a User object if the user was
authorized, or rejecting with IndieAuthError if not. It is recommended
to use recover() and catch the IndieAuthError at the application level
to show a "not authorized" error message to the user.
This function is more intended for API consumption, but is general
enough to permit using in other scenarios.
TODO: make a variant that returns Option<User> instead of rejecting
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
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!!!
|