Upgrading the registration factory

[thelastjosh]

tldr: we need to upgrade the registration factory contract at the canonical DAOstar address

Simple summary

The existing use-case for the registration factory is this:

1. Existing DAO without daoURI deploys and manages a registration contract with daoURI

We need to upgrade the registration factory contract to enable two additional use-cases:

2. Existing DAO with daoURI asks to get verified and added to the registry, [but how would we track further events emitted by the DAO? they need to have the same events]
3. A factory contract deploying DAOs with daoURI asks to get all additional DAOs tracked to the registry

This issue constitutes a specification of the upgraded registration factory.

Questions

1. Is the current factory contract upgradeable / governable?

Motivation

The new Aragon OSx, DAODAO, Kali, Superdao, etc. all have daoURI embedded in the DAO contract, so they are technically 4824-compatible. But this presents an indexing problem.

Aragon, in conversations, would prefer something like an ENS for DAOs, i.e. a centralized and possibly on-chain registry, something that people can easily verify. We need to write a quick spec of what this "ENS for DAOs" would need to do.

[MrUtsavG]

So, having gone through the summary for this enhancement and the registration contract and related code, my understanding is(correct me if I'm wrong):

Understanding of current implementation

In the current implementation, DAOs without a daoURI can

1. Generate one by filling out the registration form and then,
2. Manually make a contract call that summons a new registration instance and sets the initial DAO URI.
   • This call could be calling the summonRegistration function in the currently deployed EIP4824RegistrationSummoner contract at 0x37dF3fC47C1c3A2acaFd2Dad9c1C00090a8655Bc (Source code). This emits an event which is then stored in the subgraph.

Solution for use-case 1

My understanding is that the registry that we are talking about here is the daostar subgraph.

If this is correct, the task here to enable use-case 1 (Existing DAO with daoURI asks to get verified and added to the registry) would be:

• We could have the existing DAOs with pre-existing daoURIs just perform step 2 mentioned above and the emitted event would then add them to the registry. OR
• We could add a form in the daostar website that would take the DAO address and the daoURI and then execute this write transaction.

Am I going in the right direction with this?

[thelastjosh]

@MrUtsavG To summarize from the discussion yesterday, for DAOs with an existing daoURI embedded in their own contract (rather than in a registration contract), we have at least two options:

1. We add an interface to the DAO* factory contract through which a given DAO factory can submit an array of DAO addresses, each containing a public daoURI interface, for indexing. We can also force DAO factories to do this for every single DAO they create, to maximize freshness.
2. We add an interface to the DAO* factory contract through which a given DAO factory can submit a "stream of events" so that we can index all DAOs contained in that stream now and in the future.

[thelastjosh]

From discussion today with @ipatka : we discussed the need to add a standard event for updating daoURI. This already exists in the standard, but only within the registration contract, not as mandatory for all implementations of daoURI. The rationale is better indexing.

We also discussed an alternate path to daoURI adoption (following's Aragons request for an on-chain registry) would be to set a TXT record in ENS, assuming the DAO owns an ENS record. This would create some fragmentation and potential for contradictory daoURIs, so we may want to define a DAO's own daoURI as the canonical registration source, followed by a registration contract's daoURI, followed by a TXT record on an ENS owned & pointing to a DAO.

In general, we want to promote different pathways for a DAO to publish daoURI. It doesn't matter how they publish it, we just want to promote adoption of daoURI.

[thelastjosh]

@ipatka have we completed this task / deployed the updated registration factories?

[thelastjosh]

Josh will meet with @ipatka and Jake from DAODAO to deploy this super fast and make sure everything is working with the anticipated flow.

[thelastjosh]

Isaac will send Noah @ DAODAO the request + schema for the query that needs to go into the explorer.

[thelastjosh]

Closing since the only outstanding issue is getting the DAODAO queries / in documenting where the updated registration factories have been deployed. Will create a new issue for deploying NEW registration factories on other chains.