Closed amanwithwings closed 1 year ago
Agree more. I suggest removing the existing framework selection and configuring a framework selection for each URI field population.
Currently, we use Boardroom's API to generate membersURI FOR THE SNAPSHOT FRAMEWORK—that is, when someone selects "Snapshot" in the register interface, and puts in an ENS name (which is Snapshot's way of identifying a Snapshot space), it returns a non-functional membersURI. We then need to manually set the endpoint (in our backend) to point to the Boardroom API. This is hardcoded in our backend for different DAOs.
Agree more. I suggest removing the existing framework selection and configuring a framework selection for each URI field population.
I would just tell people that we are using Boardroom within the Snapshot framework. Maybe within a little information icon in the frontend. The goal is to keep the register interface as simple as possible.
Agree more. I suggest removing the existing framework selection and configuring a framework selection for each URI field population.
I would just tell people that we are using Boardroom within the Snapshot framework. Maybe within a little information icon in the frontend. The goal is to keep the register interface as simple as possible.
Good solution, @Rashmi-278 can you make it in the frontend?
Closed on behalf @Rashmi-278
Even though we currently use Boardroom's API to generate membersURIs, it is being done manually, on a case-by-case basis. We need to find a way to automate this and add it to the register service: https://daostar.org/register. The ideal solution would be to accept a DAO's ENS and automatically populate proposalsURI with data from Snapshot and membersURI with data from Boardroom (assuming it uses them).
At present, we assume that the same Framework will return data on proposals as well as members. This may need to be split - separate frameworks for separate URIs.