In other words, token functionality plus passport issuance and visualization.
We will also add the ability to enter and view agreements in the Nation3 jurisdiction, and a separate frontend for jurors to perform their duties in Nation3 Court.
We might also want to add a token-gated section of the app where citizens can change their profile picture, alias, add contact info and even answer questions about themselves that other citizens might be interested in. They could also view others citizens’ profiles, their $veNATION stake, their passport number, etc. (Just pinged Stani to see if we can just build this on Lens)
With all this info, I’d propose the following structure for the Citizen app:
Lock tokens and Liquidity rewards remain unchanged. Claim airdrop gets removed (we will need a governance proposal to stop past airdrops).
Profile: That would replace the Welcome, citizen item in the navbar. It would build on the current sub-app, with new functionality to add more meta-data about the citizen’s profile.
Directory: This would be a directory of all citizens, with the ability to browse profiles.
Governance: This would be what’s on the governance portal now, allowing citizens to follow proposals at a glance and create new ones.
Agreements: This would allow citizens to create and enter agreements in the Nation3 jurisdiction.
In terms of technical structure, we could a monorepo, with clear ownership over which guild/contributor owns each sub-app. It would also allow for more agile teams to fully own different pieces of infrastructure.
Multiple connections are annoying, but it’s a small UX trade-off for cleaner code and more agile teams.
Integrating with lens is a very good idea. It’s right on mission and should not be too difficult. There API is very intuitive and web2 like (in a good way). The only caveat is minting new handles is not open to the public but they do have allowances for specific communities. But I’m sure you can pull some strings
I mostly agree with your proposal of re-structuring the app sections.
Not sure about the codebase split yet, I don’t see enough resources / workflows difference between the sub-apps to justify the split right now.
Instead of performing do a massive refactor upfront, I propose doing it in phases so we can understand better what works best. First, refactor the current nation3/app codebase to visually reorg the sections as you proposed, including also new sections for the nation3/gov-app and nation3/court interfaces in the navbar. With that setup in place, we can evaluate what it’s worth to split to independent sub-apps and how; common monorepo for multiple sub-apps or individual repos for each.
As per our conversations, it sounds like code-wise a monorepo should be the easiest way to move forward, and the app could live under app.nation3.org without different subdomains for everything.
The proposed setup would be to have a monorepo with all the ui packages (one per sub-app) and a common root source code that would only import the components from each package to a common page structure.
No need to duplicate layouts, manage multiple logins or anything related while keeping each library of components splitted by scope and code owners but integrated in the same CI pipeline.
