Sharing a new registry I wrote today which lets users initialize a themeIndex which a data structure that is able to be decoded into a string themeURI of their choice. utilizies a reallllly intersting way of storing data – which is actually by deploying a Bytcode contract which stores pure encoded bytes – storing that address, and then referencing that addres for the data it stores when needed. this implementation was given to me from Iain (zora protocol dev) who forked it from a recent artblocks project
The "ThemeAdminAccessControl’ contract is a fork of some previous access control module I wrote, allowing for access schemas to be set for a uint256 themeIndex value, rather than for an address of a zoraDrop contract
acessControl: address of the current only deployed access module
accessControlInit: abi.encoded value of the address you want to give admin rights to (ex: your own wallet). use abi.hashex to get htis value, and then add an “0x” to the beginning
themeURI: the string you want to reprsent ur themeURI, probably an ipfs string
so I was going through the artiva docs and they have this repo called baseline where they start abstracting theme data in typescript, is this in the right direction of building on top of them? GitHub - artiva-protocol/baseline’’
Can you rephrase your question? I would unconfidently say that what we’re doing is in line with how Artiva is trying to make their styling more flexible but I honestly haven’t taken too much time to look at what is going on over there.
Kind of like what part of this process doesn’t exist yet. Do you have a json file of theming data that potentially could be made into bytecode so I can test this contract out or do we have to make it now?
Would I create that from a single css file or would I probably want to start working from a theme that is already abstracted into components (within the artiva protocol) and build my theme from there. (Is this an enormous lift?)
Artiva also uses a different methodology of moving things into hooks and packages so should we start from the way we use stuff like rainbowkit and all of those other cool NFT hooks that need to be scaled into the theme.
I have a reference for what a URI looks like stored in a contract from the PA GitHub but not sure if I can use that either.
Does this clear anything up? I can’t speak to the Artiva stuff, but I can say that the theme is literally the theme, and not really related to any of the componentry/hooks/packages.
How the frontend is reading from that json, I’m actually not too sure of… but I wouldn’t imagine that it’d be too crazy to wire up.
Thank you that is exactly what I was asking for, I didn’t know what contract address they were asking for.
I put the result of what you did into a JSON formatter.
{
"colors":{
"background":"#ff89de",
"text":"#00000",
"primary":"#FFFFFF",
"secondary":"#FFFFFF"
},
"fonts":{
"heading":""//ttf file saved in ipfs using pinata or another service
"body":"", //ttf file saved in ipfs using pinata or another service
"caption":".ttf"
},
"font_sizes":{
"heading":"62px",
"body":"21px",
"caption":"8px"
},
"modifiers":{
"border_radius":"24.625px",
"shadow_spread":"8px",
"shadow_opacity":"0.46",
"shadow_color":"8,8,8"
},
"font_weights":{
}
}
Theme is theme but is a potential goal to eventually make theme packages and hooks to link back to the stuff onchain so people that work on frontend can just use those things?
Bigger picture we’re just trying to present as many consumption options of some core theming tokens. These will become css variables that any front end can further leverage. That json object is it.
this is fire and exactly what we’ll need to do the base64 encoded stuff! thx for setting up the foundation. i guess now maybe just stay in contact with design team as they figure out what they want so we can continually adjust this schema?
the themeRegistry draft is done – at least to the point where we can reference a basic structure in the proposal – and thinking we can lock in final implementation as the build happens and we see what our needs are?
explains it perfectly. to take it further (maybe a seprate graphic?) – we can show that anyone can intialize their own themeIndex, and then that you can edit existing themeIndex entries if you have access control to that given entry. accesControl modules are stored in a separate mapping here, and work as its own init + registry system that gets set up on themeIndex initialization
Have you seen ethfs yet @0xTranqui. Uses the same contract data storage architecture and I think it could fit with what you guys are doing / work as a starting point for something new.
Been noticing the need for some kind of theme registry as well. Going to dive into the contracts / videos above soon and send some feedback
Of particular note, u rlly gotta look at the BytecodeStorage.sol file. Iain from zora forked it from a recent artblocks project and it’s amazing. Tldr saves gas by storing the address of a data contract (pure byte code) rather than large chunks of bytes / non encoded structs
The main place we are using it is in AssemblyPress.sol, but also messing around with using it for general storage purposes !
I think ethfs is built with sstore2 that does a similar thing.
Haven’t dug too deep into either contract yet but it’s cool to see this type of storage getting more formalized. I remember hearing about cyber brokers doing this to store all their svg data onchain and I think dhof recently did it with roses too
On a similar but kinda unrelated note do you guys have anything for onchain tagging yet. Think that’s another primitive that I’ve been needing with Artiva. I’m doing a really basic version of it by adding tagging metadata to platform metadata but a global tagging registry is something I could see adding value to this curation ecosystem
