Open hanfel-dovned opened 7 months ago
@SuperCoolYun My uncertainty here means that #12 isn't very well specified yet. Would be good to keep these design questions in mind as you investigate how NEAR smart contract calls are done, and see if there are any general principles we can keep in mind for them.
For instance: what if we end up running a Python web server instead of a Node.js one? Are there any good Python libraries for interacting with the NEAR blockchain?
Lots of research to do here about the best way of architecting this.
Two more ideas here:
%make
library for chain operations.)An important note here is that using a web server here gives us much better security than just keeping the private keys for the issuing account in an Urbit ship.
So far, we've generated four options:
Permission the .near
account issuer smart contract to only respond to one set of keys. Store these keys in a Gall agent. Run this Gall agent on the NF galaxy, and have it act as a relay server that users request their .near
account through.
Pros: Gives us Urbit ID authentication for free via Ames, simple architecture
Cons: Requires us to store valuable keys on an unsecure Urbit ship, requires us to make smart contract calls within Hoon code (which is difficult, though maybe easier once Vaporware's code is open-sourced)
Permission the .near
account issuer smart contract to only respond to one set of keys. Store these keys on a web server. Run a Gall agent on the NF galaxy that uses this web server as a sidecar, and have this pair act as a relay server that users request their .near
account through.
Pros: Gives us Urbit ID authentication for free via Ames, lets us use pre-existing libraries for smart contract calls
Cons: More complex architecture that requires the NF to maintain both an Urbit ship and a web server (as well as the connection between them)
Permission the .near
account issuer smart contract to only respond to one set of keys. Store these keys on a web server. Have the NF run this web server and have it act as a relay that users request their .near
account through.
Pros: Very simple architecture
Cons: Requires us to authenticate Urbit ships on the web server itself (maybe lib-ames solves this?)
Have the smart contract itself authenticate Urbit ID. Pros: Simplest architecture, totally decentralized Cons: Most difficult option to write
Option 1 is probably off the table for security reasons. Option 2 makes me nervous due to the number of moving parts.
If Option 4 is possible, then it's the ideal due to its simplicity, but it's likely hard to pull off and there are lots of unknowns. Option 3 is essentially an easier version of Option 4.
Next step here is to study libames and think harder about the mechanics around off-Urbit @p
authentication.
As a note on Option 2: this is potentially difficult if we used %lick or bespoke http requests, but auth-server would likely reduce the number of moving parts. We'd still have to maintain both an Urbit node and a web server, but that isn't too bad as long as we can rely on auth-server.
See #11 and #12. Users of the NEAR app on Urbit will need to be able to claim a
.near
account that matches their Urbit ID. Because most Urbit planets are on the L2 roll-up, this can't be a permissionless on-chain operation, and will instead need to go through a server run by either the Urbit Foundation or NEAR Foundation. We'll likely have the NEAR Foundation run this server, so to lighten the maintenance load on them, we're considering not running this server on Urbit.A development benefit here is that it saves us from having to do RPC calls from within a Gall agent. A marketing benefit is that we get to illustrate the use of Auth Server.
However, Auth Server still requires a running Urbit ship:
Authentication of an Urbit ID likely requires Urbit somewhere in the loop to make use of Ames. At that point, does it then make most sense to have only the one Gall agent acting as a relay server on NEAR's ship, as opposed to an Auth Server Gall agent working in conjunction with a standard web server? Is there something we can do here with lib-ames?