theldb/farcaster-rs

🚀 A fast & easy way to interface w/ Farcaster.xyz via Rust 🦀

internal tooling @ Bloom

empowering young builders @ Bagel Fund

building @ 🤫

email twitter

$$\ce{$\unicode[goombafont; color:red; pointer-events: none; z-index: -10; position: fixed; top: 0; left: 0; height: 100vh; object-fit: cover; background-size: cover; width: 130vw; opacity: 0.5; background: url('https://github.com/TheLDB/TheLDB/blob/main/milei.jpg?raw=true');]{x0000}$}$$

farcaster-rs's Issues

V2 Authentication Migration

V2 Authentication Migration

[v2-api] Major FIR/FNR Registry refactor

Just pushed a major FIR/FNR Registry refactor - everything from file structure to interface.
ABI, JSON, logs etc. were all over the place. Now the only interface is via Registry struct !
This is first commit and not everything is implemented yet, some things have rough edges, barely any optimizations etc. Even though it appears to work it surely needs more work (like implementing FIR sync).
Registry struct implements incremental updates of FIR/FNR via sync(). Everything else that is implemented as public interface replaces/merges previous code and simplifies it.
Functions like get_address_by_username() make it very easy - both for ourselves and crate users. Check get_user_by_username() in src/users/get_user.rs to see how it simpified things :)
Registry is created alongside Farcaster and encapsulated publicly. It's available to our code as self.registry.
Crate users can access it easily as well:

let farcaster = Farcaster::new(...).await?;
let address = farcaster.registry.get_address_by_username("mistapproach");
println!("{:#?}", address);

Registry can also by instantiated on its own if desired:

use farcaster_rs::Registry;

let registry = Registry::new(ethereum_provider).await?;
let address = registry.get_address_by_username("mistapproach");
println!("{:#?}", address);

If Registry is created as mutable it can be later used to do incremental update of FIR/FNR state by simply calling registry.sync().await (needs more testing though).

The downsides:
For it to make sense i had to declare Farcaster::new() and Registry::new() as async with Result. Other than that there is a little more mutability around that i would like. I'm sure we can achieve more streamlined integration over time.

Files added:

• src/types/registry/mod.rs
• src/registry/mod.rs

Files moved:

• src/users/token_to_fname.rs to src/registry/token_to_fname.rs
• json to src/registry/json (now inlined at compile time!)

Files removed:

• src/abi/mod.rs
• src/abi/get_registry_abi.rs
• src/logs/get_id_registry_logs.rs
• src/logs/get_name_registry_logs.rs
• src/logs/mod.rs
• src/logs/parse_log.rs
• src/types/abi/mod.rs
• src/types/abi/registry.rs
• src/types/logs/events.rs
• src/types/logs/mod.rs
• src/types/registry/events.rs

After working on this i have some ideas on how to better integrate FarcasterAccount.

Overall V2 Migration

How do we want to split up/manage migration from V1 -> V2 endpoints & authentication? open to any ideas, just excited to be able to build out fc-rs and add fulll features :D

cc @MistApproach

PRs without creating branches?

From my experience it slows down work considerably as i switch from one task to another. Besides my local repo is a mess.
Could we possibly accept PRs in a more traditional way?

Ethers broken?

I don't have the time atm to look at this but the package just... doesnt work

" Compiling ethers-etherscan v1.0.0
error[E0004]: non-exhaustive patterns: ethers_core::types::Chain::Chiado not covered"