Design .urbit claimer relay server architecture

[hanfel-dovned]

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:

1. A user tries to login to the site example.com by entering their ship ~sampel-palnet.
2. example.com sends an authorization request to their ship ~master running Auth Server.
3. Auth Server on ~master sends the request to the Auth Client app on ~sampel-palnet.
4. Auth on ~sampel-palnet gets the request and makes an HTTP request for http://example.com/.well-known/appspecific/org.urbit.auth.json and retrieves an attestation that ~master is an agent of example.com.
5. Auth Client verifies the signature in the attestation using the pubkey of ~master it got from Azimuth, then displays an authorization request for the user.
6. The user of ~sampel-palnet clicks "Approve" in Auth Client.
7. Auth Client on ~sampel-palnet sends an update to Auth Server on ~master saying the request was approved.
8. Auth Server notifies example.com that the request was authorized.
9. example.com logs the user in.

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?

[hanfel-dovned]

@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.

[hanfel-dovned]

Two more ideas here:

• We could essentially build a libames into the smart contract (#16) that verifies the user's Urbit ID in the same way that Ames does. I don't exactly know how this works, but I think it makes sense; even L2 ships must have their own private/public keypair for networking, right? If this is feasible, it seems like clearly the right solution, since it removes the need for a permissioned relay server entirely.
• We could write this as a Gall agent and deploy this Gall agent on multiple ships, so that there isn't a single NF or UF point of failure. (Potentially using Vaporware's soon-to-be open-sourced %make library for chain operations.)

[hanfel-dovned]

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.

[hanfel-dovned]

So far, we've generated four options:

1. 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)

2. 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)

3. 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?)

4. 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.

[hanfel-dovned]

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.