| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Micropub types are now more coherent and gathered in one place.
|
| | |
|
| |
|
|
|
|
|
|
| |
yes you can finally sign in
this is also supposed to show private posts intended for you!
maybe i can also reveal my email to those who sign in! :3
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This documents the onboarding request schema so somebody unwilling or
unable to run JavaScript (why would you subject yourself to this?) is
still able to use Kittybox.
Since JavaScript is used to provide form interactivity and complex
data structures in the onboarding flow, whoever cannot run JS will
have to manually compose the onboarding request, and this will help
them a little.
I just need to remember to update this if the schema ever changes.
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Added fundamental AutoAuth types. This library can now be used to
augment existing authorization and token endpoints with AutoAuth
capabilities.
See https://github.com/sknebel/AutoAuth/blob/master/AutoAuth.md for
the latest spec draft.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- 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 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Now everyone will know where to get my software if they see it.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
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.
|
