zbrox.com
1//! Common types for the jacquard implementation of atproto
2//!
3//! ## Just `.send()` it
4//!
5//! Jacquard has a couple of `.send()` methods. One is stateless. it's the output of a method that creates a request builder, implemented as an extension trait, `XrpcExt`, on any http client which implements a very simple HttpClient trait. You can use a bare `reqwest::Client` to make XRPC requests. You call `.xrpc(base_url)` and get an `XrpcCall` struct. `XrpcCall` is a builder, which allows you to pass authentication, atproto proxy settings, labeler headings, and set other options for the final request. There's also a similar trait `DpopExt` in the `jacquard-oauth` crate, which handles that form of authenticated request in a similar way. For basic stuff, this works great, and it's a useful building block for more complex logic, or when one size does **not** in fact fit all.
6//!
7//! ```ignore
8//! use jacquard_common::xrpc::XrpcExt;
9//! use jacquard_common::http_client::HttpClient;
10//! // ...
11//! let http = reqwest::Client::new();
12//! let base = url::Url::parse("https://public.api.bsky.app")?;
13//! let resp = http.xrpc(base).send(&request).await?;
14//! ```
15//! The other, `XrpcClient`, is stateful, and can be implemented on anything with a bit of internal state to store the base URI (the URL of the PDS being contacted) and the default options. It's the one you're most likely to interact with doing normal atproto API client stuff. The Agent struct in the initial example implements that trait, as does the session struct it wraps, and the `.send()` method used is that trait method.
16//!
17//! >`XrpcClient` implementers don't *have* to implement token auto-refresh and so on, but realistically they *should* implement at least a basic version. There is an `AgentSession` trait which does require full session/state management.
18//!
19//! Here is the entire text of `XrpcCall::send()`. [`build_http_request()`](https://tangled.org/@nonbinary.computer/jacquard/blob/main/crates/jacquard-common/src/xrpc.rs#L400) and [`process_response()`](https://tangled.org/@nonbinary.computer/jacquard/blob/main/crates/jacquard-common/src/xrpc.rs#L344) are public functions and can be used in other crates. The first does more or less what it says on the tin. The second does less than you might think. It mostly surfaces authentication errors at an earlier level so you don't have to fully parse the response to know if there was an error or not.
20//!
21//! ```ignore
22//! pub async fn send<R>(
23//! self,
24//! request: &R,
25//! ) -> XrpcResult<Response<<R as XrpcRequest>::Response>>
26//! where
27//! R: XrpcRequest,
28//! {
29//! let http_request = build_http_request(&self.base, request, &self.opts)
30//! .map_err(TransportError::from)?;
31//! let http_response = self
32//! .client
33//! .send_http(http_request)
34//! .await
35//! .map_err(|e| TransportError::Other(Box::new(e)))?;
36//! process_response(http_response)
37//! }
38//! ```
39//! >A core goal of Jacquard is to not only provide an easy interface to atproto, but to also make it very easy to build something that fits your needs, and making "helper" functions like those part of the API surface is a big part of that, as are "stateless" implementations like `XrpcExt` and `XrpcCall`.
40//!
41//! `.send()` works for any endpoint and any type that implements the required traits, regardless of what crate it's defined in. There's no `KnownRecords` enum which defines a complete set of known records, and no restriction of Service endpoints in the agent/client, or anything like that, nothing that privileges any set of lexicons or way of working with the library, as much as possible. There's one primary method and you can put pretty much anything relevant into it. Whatever atproto API you need to call, just `.send()` it. Okay there are a couple of additional helpers, but we're focusing on the core one, because pretty much everything else is just wrapping the above `send()` in one way or another, and they use the same pattern.
42//!
43//! ## Punchcard Instructions
44//!
45//! So how does this work? How does `send()` and its helper functions know what to do? The answer shouldn't be surprising to anyone familiar with Rust. It's traits! Specifically, the following traits, which have generated implementations for every lexicon type ingested by Jacquard's API code generation, but which honestly aren't hard to just implement yourself (more tedious than anything). XrpcResp is always implemented on a unit/marker struct with no fields. They provide all the request-specific instructions to the functions.
46//!
47//! ```ignore
48//! pub trait XrpcRequest: Serialize {
49//! const NSID: &'static str;
50//! /// XRPC method (query/GET or procedure/POST)
51//! const METHOD: XrpcMethod;
52//! type Response: XrpcResp;
53//! /// Encode the request body for procedures.
54//! fn encode_body(&self) -> Result<Vec<u8>, EncodeError> {
55//! Ok(serde_json::to_vec(self)?)
56//! }
57//! /// Decode the request body for procedures. (Used server-side)
58//! fn decode_body<'de>(body: &'de [u8]) -> Result<Box<Self>, DecodeError>
59//! where
60//! Self: Deserialize<'de>
61//! {
62//! let body: Self = serde_json::from_slice(body).map_err(|e| DecodeError::Json(e))?;
63//! Ok(Box::new(body))
64//! }
65//! }
66//! pub trait XrpcResp {
67//! const NSID: &'static str;
68//! /// Output encoding (MIME type)
69//! const ENCODING: &'static str;
70//! type Output<'de>: Deserialize<'de> + IntoStatic;
71//! type Err<'de>: Error + Deserialize<'de> + IntoStatic;
72//! }
73//! ```
74//! Here are the implementations for [`GetTimeline`](https://tangled.org/@nonbinary.computer/jacquard/blob/main/crates/jacquard-api/src/app_bsky/feed/get_timeline.rs). You'll also note that `send()` doesn't return the fully decoded response on success. It returns a Response struct which has a generic parameter that must implement the XrpcResp trait above. Here's its definition. It's essentially just a cheaply cloneable byte buffer and a type marker.
75//!
76//! ```ignore
77//! pub struct Response<R: XrpcResp> {
78//! buffer: Bytes,
79//! status: StatusCode,
80//! _marker: PhantomData<R>,
81//! }
82//!
83//! impl<R: XrpcResp> Response<R> {
84//! pub fn parse<'s>(
85//! &'s self
86//! ) -> Result<<Resp as XrpcResp>::Output<'s>, XrpcError<<Resp as XrpcResp>::Err<'s>>> {
87//! // Borrowed parsing into Output or Err
88//! }
89//! pub fn into_output(
90//! self
91//! ) -> Result<<Resp as XrpcResp>::Output<'static>, XrpcError<<Resp as XrpcResp>::Err<'static>>>
92//! where ...
93//! { /* Owned parsing into Output or Err */ }
94//! }
95//! ```
96//! You decode the response (or the endpoint-specific error) out of this, borrowing from the buffer or taking ownership so you can drop the buffer. There are two reasons for this. One is separation of concerns. By two-staging the parsing, it's easier to distinguish network and authentication problems from application-level errors. The second is lifetimes and borrowed deserialization.
97//!
98//! ## Working with Lifetimes and Zero-Copy Deserialization
99//!
100//! Jacquard is designed around zero-copy/borrowed deserialization: types like [`Post<'a>`](https://tangled.org/@nonbinary.computer/jacquard/blob/main/crates/jacquard-api/src/app_bsky/feed/post.rs) can borrow strings and other data directly from the response buffer instead of allocating owned copies. This is great for performance, but it creates some interesting challenges, especially in async contexts. So how do you specify the lifetime of the borrow?
101//!
102//! The naive approach would be to put a lifetime parameter on the trait itself:
103//!
104//!```ignore
105//!// This looks reasonable but creates problems in generic/async contexts
106//!trait NaiveXrpcRequest<'de> {
107//! type Output: Deserialize<'de>;
108//! // ...
109//!}
110//!```
111//!
112//! This looks reasonable until you try to use it in a generic context. If you have a function that works with *any* lifetime, you need a Higher-ranked trait bound:
113//!
114//!```ignore
115//!fn parse<R>(response: &[u8]) ... // return type
116//!where
117//! R: for<'any> XrpcRequest<'any>
118//!{ /* deserialize from response... */ }
119//!```
120//!
121//! The `for<'any>` bound says "this type must implement `XrpcRequest` for *every possible lifetime*", which, for `Deserialize`, is effectively the same as requiring `DeserializeOwned`. You've probably just thrown away your zero-copy optimization, and furthermore that trait bound just straight-up won't work on most of the types in Jacquard. The vast majority of them have either a custom Deserialize implementation which will borrow if it can, a `#[serde(borrow)]` attribute on one or more fields, or an equivalent lifetime bound attribute, associated with the Deserialize derive macro. You will get "Deserialize implementation not general enough" if you try. And no, you cannot have an additional deserialize implementation for the `'static` lifetime due to how serde works.
122//!
123//! If you instead try something like the below function signature and specify a specific lifetime, it will compile in isolation, but when you go to use it, the Rust compiler will not generally be able to figure out the lifetimes at the call site, and will complain about things being dropped while still borrowed, even if you convert the response to an owned/ `'static` lifetime version of the type.
124//!
125//!```ignore
126//!fn parse<'s, R: XrpcRequest<'s>>(response: &'s [u8]) ... // return type with the same lifetime
127//!{ /* deserialize from response... */ }
128//!```
129//!
130//! It gets worse with async. If you want to return borrowed data from an async method, where does the lifetime come from? The response buffer needs to outlive the borrow, but the buffer is consumed or potentially has to have an unbounded lifetime. You end up with confusing and frustrating errors because the compiler can't prove the buffer will stay alive or that you have taken ownership of the parts of it you care about. You *could* do some lifetime laundering with `unsafe`, but that road leads to potential soundness issues, and besides, you don't actually *need* to tell `rustc` to "trust me, bro", you can, with some cleverness, explain this to the compiler in a way that it can reason about perfectly well.
131//!
132//! ### Explaining where the buffer goes to `rustc`
133//!
134//! The fix is to use Generic Associated Types (GATs) on the trait's associated types, while keeping the trait itself lifetime-free:
135//!
136//!```ignore
137//!pub trait XrpcResp {
138//! const NSID: &'static str;
139//! /// Output encoding (MIME type)
140//! const ENCODING: &'static str;
141//! type Output<'de>: Deserialize<'de> + IntoStatic;
142//! type Err<'de>: Error + Deserialize<'de> + IntoStatic;
143//!}
144//!```
145//!
146//!Now you can write trait bounds without HRTBs, and with lifetime bounds that are actually possible for Jacquard's borrowed deserializing types to meet:
147//!
148//!```ignore
149//!fn parse<'s, R: XrpcResp>(response: &'s [u8]) /* return type with same lifetime */ {
150//! // Compiler can pick a concrete lifetime for R::Output<'_> or have it specified easily
151//!}
152//!```
153//!
154//!Methods that need lifetimes use method-level generic parameters:
155//!
156//!```ignore
157//!// This is part of a trait from jacquard itself, used to genericize updates to things like the Bluesky
158//!// preferences union, so that if you implement a similar lexicon type in your app, you don't have
159//!// to special-case it. Instead you can do a relatively simple trait implementation and then call
160//!// .update_vec() with a modifier function or .update_vec_item() with a single item you want to set.
161//
162//!pub trait VecUpdate {
163//! type GetRequest: XrpcRequest;
164//! type PutRequest: XrpcRequest;
165//! //... more stuff
166//
167//! //Method-level lifetime, GAT on response type
168//! fn extract_vec<'s>(
169//! output: <<Self::GetRequest as XrpcRequest>::Response as XrpcResp>::Output<'s>
170//! ) -> Vec<Self::Item>;
171//! //... more stuff
172//!}
173//!```
174//!
175//!The compiler can monomorphize for concrete lifetimes instead of trying to prove bounds hold for *all* lifetimes at once, or struggle to figure out when you're done with a buffer. `XrpcResp` being separate and lifetime-free lets async methods like `.send()` return a `Response` that owns the response buffer, and then the *caller* decides the lifetime strategy:
176//!
177//!```ignore
178//!// Zero-copy: borrow from the owned buffer
179//!let output: R::Output<'_> = response.parse()?;
180//
181//!// Owned: convert to 'static via IntoStatic
182//!let output: R::Output<'static> = response.into_output()?;
183//!```
184//!
185//! The async method doesn't need to know or care about lifetimes for the most part - it just returns the `Response`. The caller gets full control over whether to use borrowed or owned data. It can even decide after the fact that it doesn't want to parse out the API response type that it asked for. Instead it can call `.parse_data()` or `.parse_raw()` on the response to get loosely typed, validated data or minimally typed maximally accepting data values out.
186//!
187//! When you see types like `Response<R: XrpcResp>` or methods with lifetime parameters,
188//! this is the pattern at work. It looks a bit funky, but it's solving a specific problem
189//! in a way that doesn't require unsafe code or much actual work from you, if you're using it.
190//! It's also not too bad to write, once you're aware of the pattern and why it works. If you run
191//! into a lifetime/borrowing inference issue in jacquard, please contact the crate author. She'd
192//! be happy to debug, and if it's using a method from one of the jacquard crates and seems like
193//! it *should* just work, that is a bug in jacquard, and you should [file an issue](https://tangled.org/@nonbinary.computer/jacquard/).
194
195#![warn(missing_docs)]
196pub use bytes;
197pub use chrono;
198pub use cowstr::CowStr;
199pub use into_static::IntoStatic;
200pub use smol_str;
201pub use url;
202
203/// A copy-on-write immutable string type that uses [`smol_str::SmolStr`] for
204/// the "owned" variant.
205#[macro_use]
206pub mod cowstr;
207#[macro_use]
208/// Trait for taking ownership of most borrowed types in jacquard.
209pub mod into_static;
210pub mod error;
211/// HTTP client abstraction used by jacquard crates.
212pub mod http_client;
213pub mod macros;
214/// Service authentication JWT parsing and verification.
215#[cfg(feature = "service-auth")]
216pub mod service_auth;
217/// Generic session storage traits and utilities.
218pub mod session;
219/// Baseline fundamental AT Protocol data types.
220pub mod types;
221// XRPC protocol types and traits
222pub mod xrpc;
223
224pub use types::value::*;
225
226/// Authorization token types for XRPC requests.
227#[derive(Debug, Clone)]
228pub enum AuthorizationToken<'s> {
229 /// Bearer token (access JWT, refresh JWT to refresh the session)
230 Bearer(CowStr<'s>),
231 /// DPoP token (proof-of-possession) for OAuth
232 Dpop(CowStr<'s>),
233}
234
235impl<'s> IntoStatic for AuthorizationToken<'s> {
236 type Output = AuthorizationToken<'static>;
237 fn into_static(self) -> AuthorizationToken<'static> {
238 match self {
239 AuthorizationToken::Bearer(token) => AuthorizationToken::Bearer(token.into_static()),
240 AuthorizationToken::Dpop(token) => AuthorizationToken::Dpop(token.into_static()),
241 }
242 }
243}
244
245/// Serde helper for deserializing stuff when you want an owned version
246pub fn deserialize_owned<'de, T, D>(deserializer: D) -> Result<<T as IntoStatic>::Output, D::Error>
247where
248 T: serde::Deserialize<'de> + IntoStatic,
249 D: serde::Deserializer<'de>,
250{
251 let value = T::deserialize(deserializer)?;
252 Ok(value.into_static())
253}