As part of #118, and to enable consuming #commit events from the firehose, we need APIs for parsing and interacting with MSTs and repository CARs.

I want a logo image that can be used on https://docs.bsky.app/showcase?tags=protocol page, etc.

Now that Bluesky is becoming properly federated

• bluesky-social/atproto#1832

..are you planning to set up an atrium-based PDS? If so, consider my hand raised as a volunteer for testing ✋

My main interest is the intersection of ATproto and ActivityPub. There’s one Rust project in particular that is exploring this space in an interesting way:

• kitsune-soc/kitsune#418
• kitsune-soc/kitsune#366

I've written a quick example client to learn about the API. One feature I wanted for my client was to use interior mutability so that the client could refresh its tokens transparently to the consumer, even behind an immutable reference. As you can see, I used a mutex for this - but the fact that auth returns Option<&str> made that pretty difficult. It would also be difficult if you wanted to, for instance, retrieve a token from the environment dynamically in the auth method. My app runs against a branch in my fork that makes the simple change of returning Option<String> instead. You mentioned you were in the middle of refactoring this trait so I thought I'd make this suggestion now.

Thanks for all the work on this! It's been fun to use.

Hey,
love the work you did so far for atrium.
Do you plan on adding axum support for the xrpc-server or what are your plans with this crate?

Best regards
icepuma

Versions

• atrium-api: 0.21.0
• atrium-xrpc: 0.10.4
• atrium-xrpc-client: 0.5.2

How to reproduce

use atrium_api::client::AtpServiceClient;
use atrium_api::types::string::AtIdentifier;
use atrium_xrpc_client::reqwest::ReqwestClient;
use itertools::Itertools;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let client = AtpServiceClient::new(ReqwestClient::new("https://api.bsky.app"));
    let uris = client
        .service
        .app
        .bsky
        .feed
        .get_author_feed(atrium_api::app::bsky::feed::get_author_feed::Parameters {
            actor: AtIdentifier::Handle("atproto.com".parse()?),
            cursor: None,
            filter: None,
            limit: 30.try_into().ok(),
        })
        .await?
        .feed
        .iter()
        .map(|post| post.post.uri.clone())
        .unique()
        .collect_vec();
    client
        .service
        .app
        .bsky
        .feed
        .get_posts(atrium_api::app::bsky::feed::get_posts::Parameters {
            uris: uris.into_iter().take(22).collect(),
        })
        .await?;
    Ok(())
}

Output:

Error: XrpcResponse(XrpcError { status: 400, error: Some(Undefined(ErrorResponseBody { error: Some("InvalidRequest"), message: Some("Error: uris/0 must be a valid at-uri") })) })

If .take(22) is less than 21, no error occurs.

Hey,
you folks could use a set of crates to assemble the generated code in a more structured manner:

• Use https://crates.io/crates/quote to write the individual pieces of code
• Use https://crates.io/crates/syn and https://crates.io/crates/proc-macro2 to have structs for pieces of Idents for the struct names etc. and TokenStream
• Use https://crates.io/crates/prettyplease to pretty print the whole shebang

The basic idea:

1. Assemble lots of small TokenStreams to a large one
2. Convert TokenStream to &str using https://docs.rs/proc-macro2/1.0.56/proc_macro2/struct.TokenStream.html#method.to_string
3. Pipe the generated string through https://docs.rs/syn/2.0.15/syn/fn.parse_file.html to generate a https://docs.rs/syn/2.0.15/syn/struct.File.html
4. Pipe https://docs.rs/syn/2.0.15/syn/struct.File.html through https://docs.rs/prettyplease/0.2.4/prettyplease/fn.unparse.html to have a pretty printed String

Given this approach of having a TokenStream you get proper error messages, when something is not a legit AST token and you could add your own pretty printer, ...

If the idea is not clear enough, please ask :)

Discussed in #124 (comment)

atrium_xrpc_server::stream::frames::Frame::try_from returns Result<Self, Box<dyn std::error::Error>>. The problem is that dyn std::error::Error is not Send, which means that if the result of Frame::try_from is potentially used across an await, the entire future is not Send.

To reproduce this, modify the firehose example to spawn the firehose running method instead of running it directly with #[tokio::main]. I tested this at commit 7d99ccd.

It would be helpful if the error type was Send + Sync + 'static, to also make it compatible with the anyhow crate. But that can be handled by rewriting the error as a string, whereas the future not being Send is more problematic for usage.

Hello I started running atrium-cli; and came accross this error:

  (base) 22:27:12 ➜  rbsky git:(main) ✗ cargo install atrium-cli
  (base) 22:24:05 ➜  rbsky git:(main) ✗ atrium-cli --version
  atrium-cli 0.1.5

  (base) 22:25:55 ➜  rbsky git:(main) ✗ atrium-cli get-timeline
  Error: serde_json error: missing field `sig` at line 1 column 3311
  
  Caused by:
      missing field `sig` at line 1 column 3311

I designed ATrium to allow developers to choose an async http client, and in atrium-xrpc-client I added an implementation that uses surf as one of its options.
However, this uses old rustls and appears to be in an unmaintained state.
http-rs/surf#352

I would like to remove the xrpc client implementation using surf and the related dependencies.

The http crate version was upgraded to v1 in the recent reqwest v0.12.0 release.
https://github.com/seanmonstar/reqwest/blob/master/CHANGELOG.md#v0120

I'm considering upgrading http to v1 on atrium-xrpc along with this, but isahc, which can be used with atrium-xrpc-client, still depends on 0.2, and it seems it will be a few more months before isahc upgrades to v1.0, as discussed in this issue
sagebind/isahc#432

• Maintain the current configuration unchanged until isahc supports http v1.0.
• Temporarily remove the feature that depends on the isahc client until an updated isahc version becomes available.
• Consider alternative approaches.

This note serves as a reminder of the current situation and the decisions that need consideration.

I've been exploring the rust atproto ecosystem lately and your implementation seems to be the main one still actively being developed. How much of atproto would you say you've covered so far, and what's still missing?

ref: bluesky-social/atproto#2387

tid and record-key formats were added by bluesky-social/atproto#2377

The official TypeScript SDK provides methods to help developers interact with labels and moderation.
We would like to provide equivalent functionality in ATrium.

• https://docs.bsky.app/docs/advanced-guides/moderation#official-sdk
• https://github.com/bluesky-social/atproto/pull/2286/files#diff-3273322cf2f11a8b70880ad5206641552036c51fceaf2373cfcdbf0a3d17d787

If we try to use ATrium in an environment such as Cloudflare Workers (not sure if there is such a use case), it will be built with --target wasm32-....

However, the current atrium-api cannot be built with that target. Perhaps we encount the following error.

future created by async block is not `Send`.

This is because async_trait converts async functions to require dyn Future + Send, which seems to cause the build to fail on the wasm32 target.
It seems that we can write #[async_trait(?Send)] to work around this limitation.
https://docs.rs/async-trait/latest/async_trait/#non-threadsafe-futures

Many projects seem to use target_arch = "wasm32" to switch whether to add ?Send or not.
ATrium seems to be able to solve this problem in the same way.
https://github.com/search?q=%22%2C+async_trait%28%3FSend%29%29%5D%22+language%3ARust&type=code

By the way, if we can change MSRV to 1.75 in the future, we won't need to use async_trait, but we will probably use trait_variant::make then.
https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html#async-fn-in-public-traits

ref: #15 (comment)

Hi,

It'd be nice to make an atrium-xrpc feature flag that would trickle down to the reqwest rusttls feature flag

When dealing with Inputs or Params that have many fields, it becomes tedious to set all the values. Using libraries such as derive_builder or typed-builder, we can easily add Builders to all structs, which might make the code more concise for developers using the atrium-api.

Should we consider introducing this as an additional feature first?

Regarding atrium-api/src/com/atproto/sync/subscribe_repos.rs

It would be great to see some sort of example on how to use this. From brief reading of the code, it seems to not be implemented yet, as I cannot find anything regarding reading streams, events or anything like that. Is that correct?