These are some questions about theme customization and how it can fit into the flow of a no-code/low code one-click-deploy method.
Based on the Figma:
When getting started with the Flexible DAO Interfaces template are people navigating to the Public Assembly DAO site? or a separate Flexible DAO Interfaces Demo Site?
When users click “copy our template” where does it take them? A separate deploy site from the demo site? Similar to how Neosound has a deploy site, - or - would it be better to have the process of preparing contracts and themes happen within one site?
I started to think about why there would potentially be a separate deploy site. My initial understanding is that it’s because there are multiple values that would need to be initialized if people want to use the onchain theming route.
Something I think we should take into consideration is that there’s only one ThemeRegistry that exists for flexible-dao-interfaces/PA. Is the goal to help DAO’s establish their own registries and promote the concept of an “onchain brand kit’? This would be cool because it can help promote consistency and data integrity amongst multiple products coming out of DAOs. (ex: After they have a DAO site, then can reuse their themeRegistry to build a DAO wallet application with the same design tokens.)
If there was a deploy site, my first thoughts on the steps towards a vercel deployment would be:
1. Users deploy a DAO site AdminAccess contract.
2. Then they deploy their own ThemeRegistry. (You need an access contract for this step)
3. Then, if they don’t already have a JSON with design tokens for their theme prepared, they use presets from the PA ThemeRegistry (can they?), - or - would it be better that they use the “Theme Editor” to set those values right way?
With preset themes (Light/Dark/Stylized) we can promote consistency, but an open-ended custom editor , similar to the one that was illustrated in the proposal can promote more individuality. The one concern with having a custom theme editor with sliders is that there are constraints with letting people decide whatever value they want, because not all values can work for the design template.
However, a slider can still work if there are predefined values and things like a ranges of fonts. I am having trouble understanding if this is a different thing than a single theming json file and I’m not sure this can be initialized onchain in the registry.
Also, If they make their own theme from an editor would they be able to export their new theme as a JSON file? Even if we aren’t doing onchain theming, exporting the theme json could be cool.
4. Next steps, if can export/prepare a JSON file with design tokens, then they would have to upload the JSON file to IPFS to receive a URI link. (Can this step be automated?)
After they have a themeURI link, it would need to be initialized to the deployed themeRegistry from step #2, this is a onchain transaction that results in the user being provided a dataContract address (0x27248fghs), and themeIndex. Update changes to an existing theme within a registry is also a transaction, so how difficult is this?
- What’s more useful for theme creators to remember: the themeURI, the dataContract address, or the themeIndex? I understand that all these point to the same json in the end.
5. After the new theme is initialized in the ThemeRegistry, would they deploy the template to Vercel with these environment variables:
1. chain ID, (Mainnet or Testnet)?
2. DAO address?,
3. DAO site admin access pass?,
4. DAO themeRegistry?,
5. Alchemy Provider?
Should users be a DAO member to be considered admin and control the theme of the DAO website? Is there anyway we can use the Nouns Protocol hooks to make this access process smoother? Can the template be deployed without DAO address initialized?
Can we consider that some people may not already have their DAO address before doing this step, if they don’t have a site they can’t deploy their nouns builder DAO.
How does the registry know what theme is the default to upload the site from?
Can I see how a front end application would fetch a themeURI from a registry to make into consumable CSS objects?
I am thinking about if there is supposed to be a custom hook for any IPFS themeURI link to be consumed into the template, was that something that was discussed already?
Other Questions
After you save changes to an existing the theme, is that a transaction to automatically add it to the registry? Can they update/chose which themeRegistry to save it to?
When adding people to the site admin contract why does it have to be an ABI of the admin instead of something like the regular address or ens name?
theming data has moved entirely onchain – as in the theming json is stored fully onchain, NOT on IPFS. we moved this direction to eliminte the need for an ipfs handler flow on the site
all initialization/editing of theme indices + associated will take place in the new version of the theme registry I just deployed a draft of to goerli. here is a video of how it works, its still pretty inefficient and need to add docs + gas optimizations but its doing the job for now
dao address (think this will be either the token address or the treasury address – but whatever one allows u to get all the other values)
themeIndex (which will be a plain number – like 1). we can have a working theme index live on goerli + mainnet so ppl can mess around with it on both
some type of rpc provider
potentially a chainId but imo would be better to just have separate tesnet vs mainnet sites that make that decision for you
regarding access access control:
right now have a really simple role based access strategy set up. i think this is a smart/safe approach to take initially (as opposed to erc721 gating), but I can also update the theme registry to make access control logic files swappable so ppl can evolve theres overtime.
if anyone has any qs let me know!! will be continuing to work on this over the next week or so until we need to go live with a final version
I think the meat of my questions are around how are the values being consumed after there are customizations on any new or existing theme.
Is it a set number of presets that are already in the registry, a range of predefined values that create generative presets that still have to be minted, or will the theme editor be open to people uploading their own values. and after that what preps that information to be initializedWithData
It feels like it’s going from json to bytes to json back to bytes before it’s even getting used and i’m losing the idea from the MVP vs the Bigger Picture or if we are hitting the goal on modularity in this design
I am thinking about if there is supposed to be a custom hook for anyone IPFS themeURI link to consume the themes by index in the registry, was that something that was discussed already?
I’m making a write on up this btw
EDIT: re theming, I think I got it, I’ve been able to see how the open ended sliders way works but the only thing predefined would be a lot of curated fonts, where can there just be a registry of fonts?
re modularity: For access control I saw that whoever initializes the theme can update it but how do you add more admins to one themeIndex, and would that even matter if when those changes are made there is another themeIndex that will need managers.
I want to propose that in that process of someone initializing a theme to the registry, instead of deploying their own registry they deploy one upgradable contract that extends themeRegistry with additional functionality to add managers
Also saying this bc I’m not sure how people would keep track of the current index unless they only work with one index until they decide to register a new one.
out rn will respond more later. There will just be one registry protocol which PA maintains as part of the integrative template we are providing. Ppl won’t need to deploy their own registry, just initialize their theme index (there’s a counter in the protocol ++themeIndex that makes sure everyone’s index is unique) which they will then be able to go back and edit values on
also imo we should be treating this as a v1 that will support the short term (goal of lasting for 3 month min?) needs of the interface template, recognizing there will be areas of growth/updates that may/will prob push us to re architect things in the future
just responded – ur flow looked mainly good to me! theres a bit of back and forth we are still going thru with the contract and whether or not we are rlly gonna put stuff onchain or not (leaning towards IPFS after call this am with @salief ) – will fill yall in as soon as we get clarity on this
Running a theme test on a sandbox @salief created, I was able to store this theme json that loosely follows the PA UI Style Library, and now it lives onchain