AssemblyPress.sol walkthrough -- Still a WIP but Functional on Goerli!

Sharing link to newly established standalone repo for AssemblyPress + link to loom video describing the general architecture + basic usage.

If you have techincal feedback/prs plz add those to the repo, but feel free to use this thread to speak more broadly about the architecture + usecases

Very excited that this has finally gotten to a working v0 !!! Also sharing some working notes I took from going through the deploy process that may be useful for experimenting:

  • AssemblyPress.sol
  • Publisher.sol
  • DefaultMetadataDecoder.sol
  • OnlyAdminAccessControl.sol
  • Token rendering correctly from AssemblyPress deploy
  • Successful txns
  • AssemblyPress.sol “createPublication” function inputs
    • Name: “Zine DAO”
    • Symbol: “ZINE”
    • Default admin: 0x153D2A196dc8f1F6b9Aa87241864B3e4d4FEc170
    • Edition size: 18446744073709551615 (use this for open editions)
    • royaltyBPS: 1000
    • Funds recipient: 0x153D2A196dc8f1F6b9Aa87241864B3e4d4FEc170
    • salesConfig:
      • [0, 0, 0, 0, 0, 0, “0x0000000000000000000000000000000000000000000000000000000000000000”]
    • contractURI: “test_ContractURI/”
    • accessControl: 0x47686F3CE340bcb8609a5D65016d99B1299835e8
      • USE THIS VALUE. Its the only access control module ive deployed so far. Allows u to set up a contract only you can createArtifacts from, when paired with the following init value in the next bulletpoint
    • accessControlInit: 0x000000000000000000000000153d2a196dc8f1f6b9aa87241864b3e4d4fec170
      • Use abi.hashex to generate this bytes encoded value, then add a 0x to the beginning of it. ENCODE THE ADDRESS YOU WANT TO HAVE MINTING ACCESS
  • Publisher.sol “publish” function example inputs
    • Eth value: 0
    • Zora drop: 0xD54D9FF50EfFd332e950bEa3ee10abD9bFFfBd7B
    • Mint recipient: 0x153D2A196dc8f1F6b9Aa87241864B3e4d4FEc170
    • artifactDetails (use abi.hashex to generate the bytes encoded string value u see as the second input in the tuple. Then append an 0x to the beginning of it)
      • [[“0xA263Ebc71fb96210a5d505720C9E4893F8789046”, “0x0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000004e697066733a2f2f6261667962656967733467326a37347234346f356c626665676476656e37656a6f7136356d6f73696c646b756e363372336374326a6a6c36656d6d2f303030303032332e6a7067000000000000000000000000000000000000”]]
        • Bytes encoded value of string “ipfs://bafybeigs4g2j74r44o5lbfegdven7ejoq65mosildkun63r3ct2jjl6emm/0000023.jpg”
  • Publisher.sol “edit” function example inputs
    • Eth value: 0
    • Zora drop: 0xD54D9FF50EfFd332e950bEa3ee10abD9bFFfBd7B
    • tokenIds: [1]
    • artifactDetails (use abi.hashex to generate the bytes encoded string value u see as the second input in the tuple. Then append an 0x to the beginning of it)
      • [[“0xA263Ebc71fb96210a5d505720C9E4893F8789046”, “0x00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000045697066733a2f2f626166796265696263363371666875706b7064723632746b696465656f363671777435796b79667963697875776a666e6d367977776c7462707a342f3234000000000000000000000000000000000000000000000000000000”]]
        • Bytes encoded value of string “ipfs://bafybeibc63qfhupkpdr62tkideeo66qwt5ykyfycixuwjfnm6ywwltbpz4/24”
2 Likes

@DBlodorn the time has come !!!

DS:LFKJGL:HJSDFNDSFL:KJSDFJL:K :exploding_head: :fog:

1 Like

Sharing some notes from a great convo I had with @salief + Iain (zora protocol dev) about some initial feedback on the AssemblyPress architecture. main takeaways:

  • implement ERC1967 upgradeable proxies (upgrade of which will be controlled by FF89DE multisig and then eventually PA ) that follow the implementation outlined in this recent contract Iain created
  • general thumbs up of our direction to go with end of the line tokenBytesDecoders, but a recommendation to change how/where we are storing token level metadataRenderer/metadataDetails information. recommended opt for the deployment of a dataContract that stores the bytes data using the create opcode (guess we are going to have the assembly impl found in this contract? lol) so that our mapping looks like address zoraDrop => uint256 tokenId => address dataContract rather than what we currently have which is the same thing but the entire artifactDetails struct is stored onchain in lieu the data contarct

other helpful links that came up in convo:

additional follow up qs I just asked Iain:

just wanted to double check with u (besides figuring out the create opcode assembly at some point) is just confirming that

  1. we are still storing the equivalent of the mapping of the artifactDetails, but now its just an address of the dataContract rather than the struct itself?

  2. this means well just need to make sure that the bytes value that is getting deployed will always be something like abi.encode(address, whatever you want), and add some middlewear contract that takes the value from “readFromBytcode”, cuts out the address from it to let you know what tokenDecoder to use, and then use that tokenDecoder to decipher the remaining bytecode?

1 Like

what is the reason for storing token level details on the dataContract? Is it to just offload the size of data stored on artifactDetails?

yes + also its is a gas optimization (thx Iain) to use the “create” opcode deploying a dataContract and then reading it from that addres (which we store) rather than using whatever opcode it is (idk) that u call if u are storing the whole artifactDetails struct in contract storage

1 Like

so the reason to use the create opcode deploying/reading a dataContract vs opcode to call/read the artifactDetails struct is because the create opcode is gas optimized?

*more gas efficient than wtv the opcode is used to write to storage. but yes

1 Like