| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
This is an operation that atomically adds or updates a webmention cite
attached to a post. This is used so a database backend can optimize
for it (for example, using a transaction or shifting the JSON
modification operation to the database)
|
| |
|
|
|
|
|
| |
This complements passing sockets as FDs and graceful shutdown to allow
for zero-downtime restarts.
|
|
|
|
|
| |
Untested, but will be useful when testing Webmentions in the
end-to-end test.
|
|
|
|
|
| |
Now the postgres schemas are completely independent of each
other. This took a while to figure out!
|
| |
|
|
|
|
|
|
|
| |
This allows using tree-structured concurrency to keep background tasks
in check and allow them to finish running before shutting down — a
necessary prerequisite for shutdown-on-idle. (A background task may
take a bit too long to complete, and we may need to wait for it.)
|
| |
|
|
|
|
|
|
| |
Total crash-safety. Yank the power cord all you want, your data is
going to be safe and sound. (Unless your drive controller lies to you
about flushing its caches)
|
|
|
|
|
|
| |
Apparently this requires a helper crate to make Hyper aware of UNIX
sockets. That's fine. That's not a priority for now — but the code is
practically there.
|
|
|
|
|
|
|
|
| |
I would also love to be able to listen on Unix stream sockets, but
that would require some additional support that can thankfully be just
introduced later.
(It also requires a second loop over the file descriptor array)
|
| |
|
|
|
|
|
|
|
|
|
| |
Axum got some breaking changes and gained some nice features —
however, features come later, breaking changes come first.
Perhaps it would be nice to actually construct a State with all of my
stuff, and then make functions generic over that. Could reduce the
amount of generic stuff I am producing... maybe.
|
| |
|
|
|
|
|
|
|
| |
The trait itself seems basic enough that it could be reused
elsewhere. Better to keep it in a separate crate.
`-util` is a dumping ground for various things anyway.
|
|
|
|
|
|
|
|
| |
This requires the background task to be cancellation-safe, as it is
dropped after receiving a cancellation event.
Perhaps in the future there will be a supervisor version that may
forward the cancellation to the task itself.
|
|
|
|
|
|
| |
This also involves a crude "async drop" implementation that fires a
future incrementing an attempt if a Job has been dropped without
marking it as done.
|
| |
|
| |
|
|
|
|
|
| |
It's generic enough to be used for anything, but for now it's only
gonna be used for webmentions.
|
| |
|
| |
|
|
|
|
|
| |
This allows to use the helper on production websites that do security
checks on redirect URIs, as the URI is now properly declared.
|
|
|
|
|
|
|
| |
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 gives me much more readable traces. JSON logging is still
superior in production, where logs are stored in systemd-journald and
preferably need to be self-contained lines.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one manages to avoid extraneous allocations as much as possible,
by deconstructing the update into pieces and using a mutable reference
taken directly from the hashmap in which the posts are stored.
Now if only this hashmap were to be serialized on Drop, we could even
have persistence in the database and therefore gain another backend
that requires no dependencies to run, just like FileStorage, but
avoids extraneous file access (or maybe shunts it into the
background?)
|
|
|
|
|
| |
This was the job of the database before. Now the frontend should do it
before passing the post to the templates.
|
|
|
|
|
|
|
|
|
|
|
|
| |
`filter_post` is now out of here and moved into the frontend. This
kind of non-intrusive filtering can be done on the frontend, and the
database need not concern itself with this.
It can still be done as an optimisation... probably? but the frontend
is going to sanitize things like location in the post by itself now,
so it is not required anymore (and might be harmful, if frontend
starts indicating that there are some hidden fields by replacing them
with placeholders that ask one to log in to view information).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Flake lock file updates:
• Updated input 'flake-utils':
'github:numtide/flake-utils/a1720a10a6cfe8234c0e93907ffe81be440f4cef' (2023-05-31)
→ 'github:numtide/flake-utils/dbabf0ca0c0c4bce6ea5eaf65af5cb694d2082c7' (2023-06-25)
• Updated input 'naersk':
'github:nix-community/naersk/88cd22380154a2c36799fe8098888f0f59861a15' (2023-03-23)
→ 'github:nix-community/naersk/abca1fb7a6cfdd355231fc220c3d0302dbb4369a' (2023-07-05)
• Updated input 'nixpkgs':
'github:nixos/nixpkgs/a64b73e07d4aa65cfcbda29ecf78eaf9e72e44bd' (2023-06-08)
→ 'github:nixos/nixpkgs/0fbe93c5a7cac99f90b60bdf5f149383daaa615f' (2023-07-02)
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
We insert published time into all objects anyway, and expect feeds to
be ordered by publishing time. We should let databases rely on that
assumption when returning feeds.
|
|
|
|
|
| |
Some database backends may have optimized ways of tracking feed
contents. Others might just use the "children" property directly.
|
|
|
|
|
| |
This allows disregarding http/https comparisons and simplifies some
database designs.
|
|
|
|
|
| |
read_feed_with_cursor allows using an arbitrary string as a cursor,
unlike read_feed_with_limit, which uses last post's UID as a cursor.
|
|
|
|
|
| |
This allows avoiding an unnecessary allocation whenever the error
message is static.
|
|
|
|
|
|
| |
This allows proper separation of backend initialization and Kittybox
construction code. Some boilerplate is still present, but there's much
less of it now thanks to functions being generic.
|
| |
|
| |
|
|
|
|
| |
should've been a LazyLock tho
|
|
|
|
|
|
| |
- cleaner format!()
- syndication links
- broke up a long line
|
| |
|
|
|
|
|
|
|
|
| |
Fixes accessibility issue and allows non-sighted users to learn how
your profile picture looks.
Generating alt-text with AI might be a nice idea, except I don't know
how to integrate this yet.
|
|
|
|
| |
Optional at first. Onboarding UI not yet exposed.
|