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
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.
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.
"heading":""//ttf file saved in ipfs using pinata or another service
"body":"", //ttf file saved in ipfs using pinata or another service
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
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