V2 Authentication Migration

[theldb]

V2 Authentication Migration

[TheLDB]

@MistApproach

So currently for V1, authentication has been a huge issue due to the did-jwt implementation

However

It seems V2 is making this 100000x easier and way better based off this document

tldr; you generate a bearer token by signing a message and a few other steps, then request an authentication token

I created a small example of this here: https://github.com/TheLDB/fc-rust-bearer-example

AFAIK the /v2/auth endpoint isnt live/working yet, so theres no way to ensure it works, however it generates the same thing as the JS example in there so :D

any thoughts would be appreciated

[MistApproach]

First time seeing that Merkle API v2 document, thanks!

Excellent that you already wrote authentication prototype. Maybe we should create a new branch, v2-api? And start commiting to have something more or less complete for testing when v2 api goes live?

[TheLDB]

yeah good idea. having a rough model for when v2 apis go live is important

being the first library to support v2 apis would be super cool

[TheLDB]

First time seeing that Merkle API v2 document, thanks!

Excellent that you already wrote authentication prototype. Maybe we should create a new branch, v2-api? And start commiting to have something more or less complete for testing when v2 api goes live?

btw, i pushed some stuff to the v2-api branch, heres a rundown of whats there:

• Added functions to:
  • Create a new wallet (relocated from user -> auth)
  • Generate a bearer token
  • Get a session token
  • Added a test route for notifications, not live yet though so unclear if itll work
• Added a constants folder w/ API_ROUTE so we can change one thing and every root route changes just in case

Very happy that authentication is now working, though (see attached photo)

[MistApproach]

Very cool Landon!

Since V2 adds HTTP token headers we need to keep track of (apart from rate limits) think we should create abstraction (struct) that wraps reqwest calls. We could then keep both token and rate limit status inside this struct.
What do you think?

[MistApproach]

btw good job with extracting API base URL, was thinking of doing exactly that.

[TheLDB]

Very cool Landon!

Since V2 adds HTTP token headers we need to keep track of (apart from rate limits) think we should create abstraction (struct) that wraps reqwest calls. We could then keep both token and rate limit status inside this struct. What do you think?

I did create two custom structs (Bearer & Secret) that wrap the bearer token/payload, and the secret token with an expires at, respectively.

I'm open to any suggestions on how to improve this, just couldnt come up w/ much besides that.

To view the types:
https://github.com/TheLDB/farcaster-rs/tree/v2-api/src/types/auth
https://github.com/TheLDB/farcaster-rs/tree/v2-api/src/types/v2

[MistApproach]

Already familiar with this :) right now working on encapsulating authentication token using your code. PR soon!

[TheLDB]

Already familiar with this :) right now working on encapsulating authentication token using your code. PR soon!

just merged your PR.

since we pretty much have authentication nailed down at this point (maybe some future changes will be needed)

what should the next steps be? just slowly rebuilding calls/endpoints to call merkle endpoints vs the current ones?

if so, how should that look? was thinking of taking it section by section, archiving the old calls, writing new ones, then deleting the old ones after v2 has been tested

then, when v2 goes fully live, we can polish & publish super fast

[MistApproach]

since we pretty much have authentication nailed down at this point (maybe some future changes will be needed)

Hold on, there's one more big thing incoming :)
When speaking about higher level abstractions and encapsulation i meant more structured API from crate user point of view. Majority of my last PR is to prepare for new FarcasterAccount struct - abstraction of account used behind the scenes to obtain Merkle API authentication token, signing messages etc.
I think we need more structure as opposed to tons of unstructured, public functions implemented under Farcaster.
The way you would use FarcasterAccount is something like this:

let account = FarcasterAccount::from_mnemonic("highly secret mnemonic phrase ...");
let farcaster = Farcaster::new(ethereum_provider, account);

In addition to from_mnemonic() you can use from_private_key() - both implemented using your code. Serializing/deserializing to disk could also be implemented (security considerations though).
Behind the scenes FarcasterAccount uses auth code you wrote to prepare Bearer token and get/refresh Session token when needed.
It should fit nicely with a new "proxy" struct that could wrap all reqwest calls to add auth headers and keep track of rate limit headers etc.

what should the next steps be? just slowly rebuilding calls/endpoints to call merkle endpoints vs the current ones?

if so, how should that look? was thinking of taking it section by section, archiving the old calls, writing new ones, then deleting the old ones after v2 has been tested

The way i see it:

1. integrate types/v2
2. everything that breaks compilation (mostly get_*) - comment out for now (or even rm)
3. (optional) write reqwest proxy struct
4. start adjusting/replacing endpoint calls one by one (Casts, Notifications etc.)
5. when v2 goes live: v2-api -> main

[MistApproach]

Just pushed another PR that includes FarcasterAccount. Let me know what you think.