[DISCUSSION ONLY] Myosin - Simpler input for airdrop template

[tomstuart123]

Intro:
I received some UI feedback from Myosin. As they are the only user of templates, I've put it off until now as they are only a sepolia user and we focused on the reskin... but now they are thinking about mainnet on base. So I want to prioritise.

Context:
Myosin have a Myo token. They also have a multiple treasury hierachy of Safes here. Kirill and I created a template for them to distribute MYO from every Safe in their hierarchy to custom addresses as members onboard.

See MYO template here - https://app.dev.decentdao.org/proposal-templates?dao=sep:0xdef90A94273a1A1A72B33D39129fa41E6C08Be3a

Feedback Request:
See below.

Firstly, they currently have to input the recipient addresses as one long array and then beneath it one long array of corresponding token amounts. This was called below a 'less than ideal experience'

Secondly, the high number of zeros make avoiding a mistake in the amount of tokens received hard. Preferably, we'd convert this into 18 zeros less than it is currently

Proposed Solution:

Preference --> I think the Hats<>Decent roles work here solves for this. The one problem is they use something other than hats to define membership (a competitor called station.express)

Back up --> If the latter proves to be a blocker, we could just do some custom work with templates for them.

[adamgall]

So currently, our templates, like regular proposal builder, are only set up to provide direct 1:1 mapping between user inputs and a smart contract.

That contract we target for the multisend, expects input like that, so that's how it's built.

We currently don't store any "extra information" about templates. That extra information might be, for example, some set of instructions to tell the UI to display input in a different format, and convert it into the needed format. That extra information might also be some way to identify that the target contract is an ERC20 address, so that we can automatically convert token decimals for them.

And because our webapp is "dumb" (it only know about what's onchain and on IPFS, specifically the exact types that a smart contract is expecting), we just don't have any way to easily make Blake's first piece of feedback (better input experience) a reality quickly.

Not to say it can't be done, just requires thought, discussion, tradeoff analysis, risk analysis, priority analysis.

[tomstuart123]

I get you. Thanks for clarifying. Sounds like a janky fix would be more work than its worth.

Hopefully I can get Blake to go for the Hats<>Decent roles implementation instead on the call next week.