What should I work on next?

Now that I'm close to mainnet deployment with my project / contribution for Optimism Fractal, I'm starting consider what to work on next. This is a question about what's more burning for this fractal, so I'm interested in your input.

I'll present some of the options I see and then you can vote for them or make other suggestions.

1. Full(-er) GUI for ORDAO

ORDAO (optimistic respect-based DAO) is how I'm calling my candidate for version 2 app of Optimism Fractal that I talked about yesterday.

The firsts tests that I talked about yesterday will only have a form to submit breakout-room results like our current app. However with ORDAO you also need an interface to interact with proposals (vote for them, execute them, etc). Currently I have another app called ORConsole (see the next section) to do all that, but it's more of a command-line interface rather than a GUI. Of course, this is not suitable for an average (or first-time) user.

2. Presentation of ORConsole

ORConsole is a documentation / console app for interacting with ORDAO. It's already working and it's the main tool right now which I use to interact with ORDAO right now. It exposes all the functionality that will take time to develop in the GUI frontend. You can think of ORConsole as a web-app for the fractal where all the functionalities are available early in a command-line fashion.

Most importantly it provides documentation for the programming API to interact with Ordao which will make it easier for anyone to build a GUI for ORDAO (or at least some of its features).

So it would make sense to focus on presenting and explaining ORConsole first before starting building GUI myself, because then it might be easier to get help with the GUI part.

I wouldn't mind if someone else would take up the GUI part fully as I think I have enough to maintain already.

I know some people in the community are building full apps for fractals so it might make sense to integrate ORDAO functionalities into them at which point separate GUI for all ORDAO functionalities becomes less necessary.

That's why even though full GUI for ORDAO functions is a critical component, I'm considering not even starting it myself. But it's then worth investing more time presenting ORConsole better.

3. More testing on public testnets using ORConsole

I already deployed and tested couple of versions to OP Sepolia public testnet. Now they are obsolete because I found couple of issues which I already fixed - will redeploy next week (but if you really want a rough preview here is testnet orconsole and orec contract and respect1155 contract (note the token metadata and image - stuff that was missing in previous token contract)).

I want to do more testing of different test-cases on the public testnet, preferably with more people involved. I don't think that should delay mainnet deployment, because deployment is cheap enough on Optimism - will redeploy another candidate on Optimism if any issues are found. So I'm planning on testing on the mainnet with standard Orec configuration that is likely to be used in production, while side-by-side running more aggressive configuration (passing of proposals in couple of minutes) on the testnets, so that different test scenarios could be tried there.

This action item works well with the previous: we could hold a meeting (or a series of meetings) where I present ORConsole, show how to use it and then we run different test scenarios together.

4. Deployment of ORDAO for EdenFractal (simplest, quickest path)

If there's a need to play Respect game in EdenFractal or if we want to test ORDAO in EdenFractal meetings, I could deploy ORDAO for EdenFractal as well.

However there's a slight complication for EdenFractal as ORDAO uses old Respect distribution and there's none for EdenFractal on EVM. A simplest solution would be for a set of members from EdenFractal community to provide their accounts on Base (or whatever network we want to deploy) and I would create a Respect distribution for ORDAO to use. It could be everyone having the same amount of Respect or based our Respect scores in OF or previous version of EF. This would be just for bootstrapping until we get new EdenFractal distribution on another chain.

I'm not a huge fan of this path as EdenFractal has an old Respect distribution and this path would not use it well. But if we want to have a new deployment EdenFractal ASAP, this would be such path.

5. Respect Oracle or research for its alternatives (cleaner deployment of EF and for easier testing on the testnets)

I don't believe the need to transfer Respect from one network to another is unique to EdenFractal. I think it will arise again and again for different fractals if they exist long enough. So there's an opportunity here to build something that would make these kind of transitions easy. For example we could build a service that allows Respect holders on one chain to claim the same amount of Respect on another chain. I would call it Respect Oracle.

There's another reason I started thinking about Respect Oracle. It could make testing of Ordao much smoother (section 3). To test it with multiple testers, each tester would have to have Respect token and some ETH on the testnet. Currently someone would have to distribute those manually. If I would have Respect Oracle it could make involving new testers much easier (especially if these testers have any Respect in some mainnet fractal). And I might need this kind of testing over-and-over again.

But this would be another project. Not a huge one for me, since I could re-use some code and infrastructure I used for ORDAO but it's something that would likely take more than couple of weeks to get the first version. Also it might be wiser to do some research first - maybe there are some tools we could use here so that we don't need to develop something new. Maybe there are some oracle services that could do large part of a job, although in EdenFractal's case it makes me doubtful, because we need EOS <-> Base communication.

6. Improvements for OREC

I found some potential improvements for OREC (main smart contract for ORDAO) that I really would like to make:

6.1. Ability to specify proposal order in proposals;

Sometimes it might be critical to execute transactions in specific order. But currently if you create and pass multiple proposals at around the same time, there's nothing preventing these proposals from being executed in any random order that callers of execute function determine.

It would be cool to enable proposers to specify dependencies of a proposal - other proposals that have to be executed first.

6.2. Ability to specify time window for execution;

Sometimes it might be critical that certain transaction is executed at specific time window. Currently a time when proposal can be executed is determined by when it is passed and that is determined by when it is proposed. This is very unwieldy way to managing timing of execution of proposals, plus there is no way of specifying end time of an execution window.

6.3. Automatic expiration of proposals which are passed but not executed;

Currently you would have to pass another proposal to cancel.

6.4. Support for "delegatecall" proposals

Without going into technical details about what "delegatecall" is (EVM feature), this would allow extending OREC functionality without upgrading Orec contract.

It would actually enable future extensions that could implement improvements mentioned earlier without upgrading Orec (you would just need to deploy new contracts that implement these new functionalities of Orec as extensions). If OREC becomes successfully used by a fractal then it will become the core of fractal's contracts and so changing it will become harder (and it should - community should be careful in changing its core contracts). Therefore extending Orec instead of modifying it becomes very useful.

I already wrote some these improvements for Orec, but off-chain code now needs to be updated and everything tested. Since these are bigger changes and require some more time I decided to not include them in the current deployments.

---

So this is where I'm at currently regarding next steps. I probably won't start working on any of these tasks until at least after next week, so there's no rush, but it's worth starting to think about. I thought it might be good idea to poll community if it has any inputs regarding priorities.