| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
This was the job of the database before. Now the frontend should do it
before passing the post to the templates.
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
Optional at first. Onboarding UI not yet exposed.
|
| |
|
|
| |
This allows much for a cleaner and idiomatic settings interface.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It makes more sense to keep CSS near the templates, and the
client-side JavaScript code too, since it depends on the DOM structure
to work. Additionally, the overhead of `include_dir!()` is almost
completely mitigated by the fact that this is a separate crate that
isn't recompiled often.
The linking stage, however, is still expected to take a little bit
long. But I doubt it'd be longer than what it was before, since it's
the same exact files that get linked into the app.
|
| |
|
|
|
|
| |
I don't know how worthwhile that was, given that LibreJS developers
themselves don't care to properly declare licenses on the Bazaar
frontend they use to host the extension's source code on the Web π€‘
|
| |
|
|
|
| |
This is a naive implementation that doesn't have some security
checks. It's ok tho, should work fine... can refine it later
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
JavaScript is a hellpit i want out of it please help me
|
| |
|
|
|
|
| |
There is a possibility of refactoring some of the companion code to
act as a generic embedded asset framework and put it in the `util`
crate.
|
| |
|
|
|
|
|
|
|
|
| |
Working:
- Tokens and codes
- Authenticating with a password
Not working:
- Setting the password (need to patch onboarding)
- WebAuthn (the JavaScript is too complicated)
|
| |
|
|
|
| |
Kittybox now uses tracing instead of log. Why would I keep an
unneccesary dependency in my Cargo.lock?
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the living, breathing proof that Kittybox can be split into
independent components without sacrificing any functionality. Just
make sure all neccesary backing storage components are available to
the modules that need them.
Also the Micropub client was split into several files, because it's
about to get much bigger and more full-featured.
Yes, I am going to write it in vanilla JavaScript. I don't trust
anything from NPM to run on my computer. Not anymore. Not after the
node-ipc malware fiasco. And I am definitely not going to spin up a VM
or a Docker container (who uses Docker containers as a security
measure?) to hack on my own code.
Cargo can at least be sandboxed inside Nix, where it can't do much
harm. NPM basically requires unrestricted network access to download
dependencies, and it runs arbitrary code upon **downloading**
them. Cargo and rust-analyzer, on the other hand, can be configured to
not trust the source code and its dependencies (for example, Cargo
doesn't execute code on fetching dependencies - only on building, and
rust-analyzer's proc-macro expansion support can be sacrificed for
more security).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This frees up the name for the future in-house IndieAuth
implementation and also clarifies the purpose of this module.
Its future is uncertain - most probably when the token endpoint gets
finished, it will transform into a way to query that token
endpoint. But then, the media endpoint also depends on it, so I might
have to copy that implementation (that queries an external token
endpoint) and make it generic enough so I could both query an external
endpoint or use internal data.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Axum has streaming bodies and allows to write simpler code. It also
helps enforce stronger types and looks much more neat.
This allows me to progress on the media endpoint and add streaming
reads and writes to the MediaStore trait.
Metrics are temporarily not implemented. Everything else was
preserved, and the tests still pass, after adjusting for new calling
conventions.
TODO: create method routers for protocol endpoints
|
| |
|
|
|
| |
Actually got the idea from https://xeiaso.net/, who groups xer
website's endpoints under the `.within` folder.
|
| | |
|
|
|
- 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
|
