feat: Add farcaster extension

[ysm-dev]

📦 Pull Request

[Provide a general summary of the pull request here.]

✅ Fixed Issues

• [List any fixed issues here like: Fixes #XXXX]

🚨 Test instructions

[Describe any additional context required to test the PR/feature/bug fix.]

⚠️ Don't forget to add a semver label!

Please 🚨 ONLY ADD ONE 🚨 of the following labels, failing to do so may lead to adverse versioning of your changes when published:

• patch: Bug Fix?
• minor: New Feature?
• major: Breaking Change?
• skip-release: It's unnecessary to publish this change.

Special Note

Please avoid adding any of the Priority labels as they conflict with the labels above ☝️

📦 Published PR as canary version: Canary Versions

:sparkles: Test out this PR locally via: ```bash npm install @magic-ext/farcaster@0.0.2-canary.750.9601394972.0 # or yarn add @magic-ext/farcaster@0.0.2-canary.750.9601394972.0 ```

[hcote]

Is there a reason this logic can't be in the iframe? I think it's more maintainable that way where the sdk just sends an rpc method magic_auth_farcaster_login then the iframe handles the rest, then you don't have to pass events between the sdk and iframe.

[ysm-dev]

Is there a reason this logic can't be in the iframe? I think it's more maintainable that way where the sdk just sends an rpc method magic_auth_farcaster_login then the iframe handles the rest, then you don't have to pass events between the sdk and iframe.

@hcote

When I initially designed the implementation, I thought that in the case where the user set showUI to false, there is no UI to show on the mandrake side at all, so it could only be handled in magic-js.

And to get both socket channel open event and success event from handler to farcaster login relayer, I thought it was similar because I need to send events from mandrake side to iframe side anyway.

[hcote]

We can handle this still in mandrake when there's no UI shown (this is how we handle ui-less requests like getInfo.

I think it'd be a lot simpler to maintain to have the logic in mandrake, and future updates would not require new sdk versions, but if there's a good reason why it needs to be in magic-js I'm open to doing it in here

[Ethella]

We can handle this still in mandrake when there's no UI shown (this is how we handle ui-less requests like getInfo.

I think it'd be a lot simpler to maintain to have the logic in mandrake, and future updates would not require new sdk versions, but if there's a good reason why it needs to be in magic-js I'm open to doing it in here

I believe the reason is that Farcaster, as a type of social login, may block authentication requests submitted from iframes or webviews in the future as a security measure, similar to Google OAuth.

[hcote]

@ysm-dev The deepsource errors are from the uses of any - they should be replaced with non-any types

[Ethella]

Created @magic-ext/farcaster package for CI publishing

[Ethella]

Please address the deepsource, otherwise LGTM

[ysm-dev]

@Ethella @hcote fixed!

[svc-magic-git]

:rocket: PR was released in @magic-ext/farcaster@0.0.2 :rocket: