smithki
commented
3 years ago I'd like to be able to use Deno as my backend with Magic, but currently it doesn't seem to be possible. The main blockers I saw when I briefly tried it were a bunch of exceptions on import from ethereum libraries for node.
I'm open to a PR enabling Deno compatibility, but as you mention it may take some work to pull this off. It might require us to maintain these crypto functions internally, which is a trade-off I'm willing to consider. If the community is interested in helping us out here, we'd be grateful! 🙏
I'm wondering if it might be feasible to change this however? Maybe some of the crypto operations could be moved behind the Magic provided rest endpoints that the SDK already calls?
This is an interesting idea, but would be a little bit counter-productive to the long-term vision of our security model. We are working towards a decentralized system that centers less trust in one authoritative entity, even Magic itself. By putting more emphasis on a trustful connection to our API services, especially for something as low-level as cryptographic recovery functions, I see that as going backwards. 😓
This would also unblock integration in backend languages/environemnts that Magic hasn't provided SDKs for, of which there are still plenty other than deno.
You're definitely right, but we're not trying to do the "easy" thing. We are maintaining a growing list of backend SDKs through the efforts of our engineering team as well as contractors with domain-specific knowledge. In the case of Deno, we don't currently have a resident expert, but we might be interested in hiring one! This is where I'm hopeful that the community can show us the way! If it would be possible to maintain the Node and Deno-compatible code in one place, that would be just chef's kiss! 👨🍳👌
lewisl9029
michaelmerrill
✅ Prerequisites
@magic-sdk/admin)?✨ Feature Request
Deno is gaining a lot of traction these days thanks to its security model, web compatibility, etc.
I'd like to be able to use Deno as my backend with Magic, but currently it doesn't seem to be possible. The main blockers I saw when I briefly tried it were a bunch of exceptions on import from ethereum libraries for node.
I've been looking into a few other authn providers lately as well, including Auth0, SuperTokens, and WorkOS, none of which supported deno officially in the form of SDKs, but their SDKs are just thin wrappers around REST APIs that I could hit directly from deno using fetch to unblock myself.
The SDK for Magic however, is doing a bunch of crypto with ethereum libraries and thus not fully abstracted away behind the rest API.
I'm wondering if it might be feasible to change this however? Maybe some of the crypto operations could be moved behind the Magic provided rest endpoints that the SDK already calls? This would also unblock integration in backend languages/environemnts that Magic hasn't provided SDKs for, of which there are still plenty other than deno.