| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
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)
|
|
|
|
|
|
| |
This stubs the neccesary code with enough stuff that it will work and
be accepted by most compliant Micropub implementations. Later, this
can be extended when the neccesary amendments and refactors are done.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This prevents Micropub requests fired from web apps on other domains
from being blocked by overzealous browsers.
|
|
|
|
| |
You're welcome.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
APIs and preparation for onboarding
|
| |
|
| |
|
|
|
|
| |
endpoint
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This launches a background task to handle:
- Downloading reply contexts (requires an MF2 parser, doesn't work yet)
- Syndicating the post (currently no syndication targets are defined)
- Sending WebSub notifications if a hub is present (WIP)
- Sending webmentions (ok this one is fully implemented... I hope!)
This background task should not impact processing times and should
never conflict with futher updates of a post, since the database is
guaranteed to be fully atomic. Inside of the task, you can run long
asynchronous fetching and stuff, just don't block the whole thread.
|
| |
|
| |
|
| |
|
|
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!!!
|