Rage Report: Summoner

Goals

• Build a summoner app that spins off new Baal DAOs for testing
• Learn how the new Baal Summons, if it is easily summoned in one TX, and how Baal TXs are performed

Thoughts Going in

• Much of the challenge would center around encoding.
• Guessing that the new front end stack would be a challenge, but not a blocker
• Nested call data was going to create issues with TX transparency

Learnings

Encoding:

Summary: The level of encoding is pretty wild, even for someone who is used to working with the Safe Minion. But it's pretty easy to get the hang of once you start. The real challenge is TX validation and transparency. This is something we should start brainstorming solutions for.

• Because we're also encoding arguments without function data, we're using two different methods of encoding (not a big deal but worth noting).
• We either need to do a good job of explaining to devs how to deal with encoding, or abstract it away seemlessly with one of our libraries.
• Once you get encoding working right, it's very straightforward. One exception being how these libraries handle errors (or how the don't handle errors at all).
• It's also pretty easy to write up utilities for encoding. We should apply our efforts of validating encoding args before the library kicks out non-readable errors.
• Because Baal uses this pattern for pretty much everything, it allows us to get in the rhythm of dealing with call data. I think having one way of doing things is a big +.
• TXs are opaque on Etherscan. We were anticipating this. But the biggest challenge will be dealing with transactions that seemingly execute fine, but don't perform as expected
  • This is because MM or etherscan can't validate to see where a deeply nested multi-TX can fail.
  • Users are used to seeing the red error messages in their provider. If other Baal TXs are like summon, they won't see that when they execute.
  • Also, some TXs may execute, while others may revert. It's not clear to me that the entire Multicall will revert if one of the sub-trasnactions does.

Execution Order

• Sam mentioned that Poster event fires first on summon, even though it is the last in the TX order
• If this is the case, not being able to determine with certainty which TX will be performed first will cause some pretty major challenges.
• It is possible that the order isn't necessarily execution order, but the order that the events are fired, but at least in my mind the events fire after the TX executes.
• This can also be a source of bugs or exploits. It's better we understand what's going on here before a bad actor does.

Front End

Summary: Typescript and some of the tooling is going to add some friction up front.

• We're a team of JS devs who are largely familiar with TS, but by no means experts.
• There is no such thing as a simple Dapp (in terms of code quantity). Which means much of my time was spent diving into node_modules for Types. This is before I learned about TS's typeof operator.
• Vite is super fast, but has some node problems. There were problems with accessing node's process.env or the 'Global' keyword. I tried defining a config with this variables in place (as mentioned in Github issues) like so:

import { defineConfig } from 'vite';
export default defineConfig({
  define: {
    'process.env': {},
    global: {},
  },
});

• For all Typescript's challenges there's certainly a light at the end of the tunnel. I found that I could code an hour or two without looking at the browser window or logging anything out. Most times the code would also run as intended as well.
• So far the NX monorepo works really well.
• There's nothing 'barebones' about a DAO dapp. Even with an extremely limited scope, I found myself copying or rewriting a lot of code. I think this is good while we're rethinking our processes at the moment, but we once we have our patterns in place, we need to ensure that spinning a blank rage app takes minute or two--without copying over any crappy patterns from the other app.

Smaller Libraries

I would have loved to have npm installed a form builder into the app instead of building a new one. In the future, it'll be the same with calling and fetching.

My thinking is that we should have many small libraries instead of big ones.

Future Rages

• Learn more about execution order in multiTX. See if there's a pattern we can understand.
• Learn the essential TS types for common libraries we use and get them somewhere where we can all use them.
• Or better yet, begin taking detailed notes on setting up a Rage App. We can automate this.
• Modular FormBuilder -- takes in a dev defined factory of inputs and a form Lego. Renders it out. This version could drastically simplify the existing formBuilder.