Using `Parameters` causes it not to deserialize the `limit` parameter correctly,
leading to 400 errors if it is specified at all.
`ParametersData` is the one we need.
Building with default GCC included in `cross` at the moment (9.4.0) fails
on compiling `aws-lc-sys` with the following message:
Your compiler (cc) is not supported due to a memcmp related bug reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189.We strongly recommend against using this compiler.
GCC 10.5 seems to include a bugfix for this, but 9.4 does not.
Building with GCC 10.5 works.
This includes a bunch of small changes to adapt to how atrium-api has changed
over time. They're not functional or interesting, just some type-level
adjustments that are needed.
Some more complicated logic was changed in how profile details are parsed,
since atrium's way of doing things is weird and hard to understand so I just
manually grab stuff from the object map instead of relying on atrium's types.
This is similar to how CBOR parsing is done.
Boring maintenance stuff.
I have much to learn about async Rust, but the gist of it is that running try_join
on a bunch of futures makes it run them in one task which is not at all what I want
because all the components here are separate from each other. Apparently to make it
spawn separate tasks, you need to use tokio::spawn. You live and learn.
Ideally of course these should be separate processes entirely, but for now I'm
far too lazy to deal with that
This is useful to fixup broken profiles.
Ideally, of course, we should be retrying a few times and then giving up,
but that seems kinda too much for a little hobby project.
Also, metrics would be nice, but, you know
- For new axum, use the new way to start the server. No other changes seem necessary.
- For new atrium, update the way agent is initialized. Also now we cannot get the
session out of the agent, so resolve our own handle to the did with an extra request.
This is a shame, but eh. That's what you get when using unstable libraries
`atrium-api` now includes an `AtpAgent` which takes care of creating
and refreshing sessions automatically, so we no longer need our
custom xrpc client and session management logic.
This is nice.
This is the right thing to do at this moment as per Bluesky blog post[1]
asking developers to switch to the new URL which supports federation
properly.
[1]: https://atproto.com/blog/bgs-and-did-doc
The host has changed recently and the cursors are, apparently, incompatible with each
other, so we need to migrate to the new one, and this seems like the easiest way to
do it:
1. Store the host as part of the subscription state
2. Roll out the version that uses that new column as part of all queries
3. Switch to the new host
4. Roll out the version with the new host
- The new instance will start processing messages with a 0 cursor and so start anew
- The old instance will die off
- Put internal stuff (cbor, ipld deserialization, xprc client) into internals module
- Move various record types into separate modules under entities
- Also move session into entities as well
- Simplify CBOR conversion stuff by liberal usage of TryFrom
This will all make it a little easier to implement additional things, like filtering out replies
This basically required implementing authentication from ground up
because atrium-api is horribly deficient when it comes to it,
providing basically no real way to manage it, and what is provided
is actually broken anyway requiring additional hacks to get around
Ah well. This has been the story of using anything in Rust that's
related to Bluesky. Everything is broken.
- Remove the build Dockerfile, it's not useful on cheap VMs because you can't really build anything on them
- Update the serving address to be 0.0.0.0 so that it's actually exposed externally (127.0.0.1 isn't)
- Also update the port to be 3030 for no reason at all
- Add a Cross.toml config file for cross-compilation since my machine isn't exactly Linux that the resulting binary needs to run on
Aleksei Voronov