App Scaffold

[Oba-One]

Done State

• Setup base clientside code for app
• Incorporate the Allo Yeeter starter kit for setup
• Create component files and page routes
• Simplify UI for Yeeter (separate from Create Round)
• Connect allocate function with form

Technical Requirements

• Use Nextjs for React Framework
• All styling done with TailwindCSS
• Follow the component structure outlined by the dev guild.

Resources

• Nextjs
• Allo Starter Kit
• TailwindCSS
• Dev Guild Engineering Design Patterns
• Dev Guild Engineering Tech Stack

[JulianKingman]

@Oba-One Some shower-thoughts:
As I get into how the allo-2-sdk and works, I'm noticing there are certain well-defined ways of doing things, which feels like doing things the "allo" way. For example, having the Strategy interface hook into certain parts of the Allo Kit form (creating rounds, rounds contain parts of the form generated by the allo-2-sdk).

What we're kind of doing is pulling various things apart and simplifying them, but it actually makes things more complicated to do it this way. For example, rather than having the Yeeter strategy return the same format as other strategies, we have to either take it out of the allo-2-sdk, which may go against what is ultimately desired for Yeeter (my possibly-wrong assumption was always that this is something they'd want to integrate into their broader suite of tools), or make it work in a way that other allo-2-sdk functions don't exactly work.

If I worked at GitCoin and was designing this from scratch, I would design it in the "allo" way:

• Integrate rounds
• In the Create Round form, register participants using the allo "register" function
• Deploy the strategy with the participants in the constructor
• Have a separate pool for each round
• Have a separate form for disbursing the funds, using the allo "disburse" function

But, I recognize that's not the assignment, and would make this more complicated. I'm just a bit confused, as I look at all this formal structure, as to why we're not using it.

[JulianKingman]

Secondly, regarding disbursement amounts, I'd like to confirm what the underlying goal is for Yeeter with regards to payment amounts. I see a few different possibilities:

1. Enter an amount, disburse that amount evenly among all participants
2. Enter an amount, for each participant enter a percentage
3. Enter an amount for each participant

It seems we're going for #2, but it seems like the least useful/intuitive option to me, which is why I'm interested in the motivation for the feature in the first place. Percentages will be a bit finicky, because they have to add up to 100% perfectly, and it's not straightforward to reason about how much is being sent to each recipient. What do you see as the objective with distributing?

[Oba-One]

I see where you’re coming from. I think the question that will answer this is do they intend to add the Yeeter strategy to the SDK. If yes what you’re doing makes total sense and stay in that direction. If no then I believe it introduces more complexity in maintaining overtime as we can just use the Abi directly in the client for calls. I would also add that the most mature build off the Allo protocol Grant Ships does not conform to Allo paradigms fully and the overarching goal with Allo from my current understanding and operating this Allo round is to increase GMV (Gross merchandise value) otherwise amount of funds flowing thru Allo. I’ll ask Henry about the SDK and we can go from there. Thanks for all the work so far, love your approach and engagement

…

On Wed, Oct 9, 2024 at 6:45 PM, JulianKingman ***@***.***(mailto:On Wed, Oct 9, 2024 at 6:45 PM, JulianKingman <<a href=)> wrote: ***@***.***(https://github.com/Oba-One) Some shower-thoughts: As I get into how the allo-2-sdk and works, I'm noticing there are certain well-defined ways of doing things, which feels like doing things the "allo" way. For example, having the Strategy interface hook into certain parts of the Allo Kit form (creating rounds, rounds contain parts of the form generated by the allo-2-sdk). What we're kind of doing is pulling various things apart and simplifying them, but it actually makes things more complicated to do it this way. For example, rather than having the Yeeter strategy return the same format as other strategies, we have to either take it out of the allo-2-sdk, which may go against what is ultimately desired for Yeeter (my possibly-wrong assumption was always that this is something they'd want to integrate into their broader suite of tools), or make it work in a way that other allo-2-sdk functions don't exactly work. If I worked at GitCoin and was designing this from scratch, I would design it in the "allo" way: - Integrate rounds - In the Create Round form, register participants using the allo "register" function - Deploy the strategy with the participants in the constructor - Have a separate pool for each round - Have a separate form for disbursing the funds, using the allo "disburse" function But, I recognize that's not the assignment, and would make this more complicated. I'm just a bit confused, as I look at all this formal structure, as to why we're not using it. — Reply to this email directly, [view it on GitHub](#3 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AIPQ5FJJMC6OFN3RCKAK57LZ2XL4BAVCNFSM6AAAAABPERKQFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBTG4ZTAOJXGE). You are receiving this because you were mentioned.Message ID: ***@***.***>

[Oba-One]

To me here simpler is better. I like option 1 to start then we can add the option in the future to set amount per address. I like how Gitcoin does it for donations with the set amount once then ability to edit per project. Basically suggesting the same thing

…

On Wed, Oct 9, 2024 at 6:56 PM, JulianKingman ***@***.***(mailto:On Wed, Oct 9, 2024 at 6:56 PM, JulianKingman <<a href=)> wrote: Secondly, regarding disbursement amounts, I'd like to confirm what the underlying goal is for Yeeter with regards to payment amounts. I see a few different possibilities: - Enter an amount, disburse that amount evenly among all participants - Enter an amount, for each participant enter a percentage - Enter an amount for each participant It seems we're going for [#2](#2), but it seems like the least useful/intuitive option to me, which is why I'm interested in the motivation for the feature in the first place. Percentages will be a bit finicky, because they have to add up to 100% perfectly, and it's not straightforward to reason about how much is being sent to each recipient. What do you see as the objective with distributing? — Reply to this email directly, [view it on GitHub](#3 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AIPQ5FMDRH6TA5Z3A7JBIG3Z2XNDLAVCNFSM6AAAAABPERKQFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBTG42DAMZVHE). You are receiving this because you were mentioned.Message ID: ***@***.***>

[JulianKingman]

Update:

The minimal preliminary UI is set up, and the yeeter strategy factory deployment is working, but the pool deployment is getting stuck at the signing step. I worked with @Utilitycoder on this for several hours, at first it seemed that there was a gas calculation issue, but when I manually set the gas price, it would get stuck in "pending" indefinitely. When Lawal examined it, he found it was failing when checking the profile permissions, but... this doesn't really make sense.
To explain, the Allo contract (actually the Registry contract) checks that the wallet calling the create pool function has permissions to use the profile that's being used in the create pool transaction, and if it fails, it rejects the transaction. The reason this is a strange failure is because if I directly test the profile ID and the wallet address with the Registry contract, it completes successfully.
I'll look into this further, try to manually perform each step to see if I can get it to succeed. I'll post the above in the telegram group as well, in case Henry has any off-the-cuff insights.

[JulianKingman]

Pool creation is working, final step: yeet!