There are two main uses for the user-facing NEAR Urbit app:
Claiming your .urbit NEAR account
Browsing user-made gateways
To achieve this, we'll have two Gall agents: a user-facing client and a UF/NF-run relay server.
The relay server will authenticate users' Urbit IDs and facilitate the on-chain .urbit account creation, as well as act as a relay/repo/marketplace for discoverable user-submitted gateways. (This won't need a frontend, since it'll just be running automatically.)
The user-facing client app will store the .urbit account credentials and allow the user to browse installable and locally-installed gateways.
EDIT: As discussed in the edit to #12, the relay server for claiming .urbit accounts will likely not be a Gall agent. (This raises another question: should there be a centralized repo for gateways, or would it be more Urbity and decentralized to do this via %gossip and direct linking?)
This issue will be for the Urbit side of this architecture.
There are two main uses for the user-facing NEAR Urbit app:
To achieve this, we'll have two Gall agents: a user-facing client and a UF/NF-run relay server.
The relay server will authenticate users' Urbit IDs and facilitate the on-chain .urbit account creation, as well as act as a relay/repo/marketplace for discoverable user-submitted gateways. (This won't need a frontend, since it'll just be running automatically.)
The user-facing client app will store the .urbit account credentials and allow the user to browse installable and locally-installed gateways.
EDIT: As discussed in the edit to #12, the relay server for claiming .urbit accounts will likely not be a Gall agent. (This raises another question: should there be a centralized repo for gateways, or would it be more Urbity and decentralized to do this via
%gossip
and direct linking?)This issue will be for the Urbit side of this architecture.