JestemZero

@jestemzero

644 Following

329 Followers

C O M P Ξ Z pfp

I believe that FC is a decentralized illusion! Despite all my support and efforts to spread it. ⛔ All the mini-apps I’ve built — thoughtfully, passionately, with real utility — have quietly disappeared from the Farcaster MiniApp Store. No explanation. No transparency. Just gone. Because I am Persian. I receive zero in rewards — not even a single cent — despite months of contributions. My posts go unseen, unsupported, even when they're creative, constructive, or community-focused. Because I am Persian. I’ve been banned from any programs — quietly pushed out without any valid justification. I’ve been excluded from programming competitions and initiatives meant to foster innovation. Because I am Persian. And yet, I kept building. Not because I expected favors. Not because I wanted to chase clout. But because I am Persian — and being Persian means I create despite the odds.

59 replies

290 recasts

462 reactions

JestemZero pfp

1 reply

0 recast

1 reaction

JestemZero pfp

#ZeroContract Feature Highlight #6: ○ Ability to add infinite types of artwork Ever wish you could pack various types of art into a single token? Do you want to let collectors buy multiple versions, multiple aspect ratios, multiple assets all in one package? Bundle together images, audio, video, code nicely all as one piece of art? Most standards only let you add a handful of files, or just one link, and rarely work with on-chain assets. That’s limiting for creators who want to offer more. Introducing extraUri as a new way for artists to attach unlimited types and numbers of files to one token. Think of it as giving your art its own portfolio that can hold and display different files, in any format you want, and you can add as many as you like! I will try not being too technical here, but there is a lot of technical limitations we are pushing thru now with this new mechanism I think should become a future Tezos standard.

1 reply

3 recasts

4 reactions

JestemZero pfp

Thank you so much for reading thru this long thread if you have made it to the end. It means a lot to me because this has been a feature on my mind ever since I started building. 💙 End of the thread 🛑

0 reply

0 recast

0 reaction

JestemZero pfp

However, it is definitely my goal to expand this adoption as much as possible. And I have done all I can to make it as easy as possible. In order to ensure all indexers, marketplaces, websites, etc. have an easy way to understand the extraUri portfolio, TZIP-compliant offchain views have been incorporated into the contract. These are easily quarriable, at no cost, and provide all the information needed to view and display the portfolio assets. This will be discussed in a future #ZeroContract feature highlight soon. This was a big feature I wanted to build into the #ZeroContract and am super happy how it turned out. I plan to propose this as a new Tezos TZIP standard because, while originally built to help on-chain artists, it can be utilized with off-chain storage just as easily. We are all artists and on-chain advocate or not, we all deserve quality tools.

1 reply

0 recast

0 reaction

JestemZero pfp

Two really important factors I took into considering when building this mechanism is to keep it TZIP compliant and to ensure this will not break anything on marketplaces, wallet software, indexers, etc. The use of unique metadata keys is compliant and friendly all around. Keeping the portfolio index outside of the metadata simplifies our metadata and never needs to be seen by indexers and marketplaces if they do not care to include that information. End users can still see the artwork files and retrieve the assets they purchase even if the Name and Description aren't shared on the marketplace. And even when the filetypes stored in the extraUri metadata are a format not recognized by the marketplace, this will have zero negative affect because we preserve the integrity of the other artwork strings marketplaces already use (artifactUri, thumbnailUri, externalUri). Marketplaces can decide for themselves if and what they wish to display without artists worrying about their listings looking broken.

0 reply

0 recast

0 reaction

JestemZero pfp

When we create a new label, a new metadata element is created called extrauri_label which stores the actual artwork corresponding to the portfolio information. Just like the Name and Description, this artwork string is editable. It can even be removed if desired. And with the additional feature of infinite file sizes (see the next installment of #ZeroContract features) the freedom artists have is unbounded. The entire mechanism is very simple to use and fairly simple in execution even if it looks a bit complicated. But there are really good reasons for this.

2 replies

0 recast

0 reaction

JestemZero pfp

When utilizing the extraUri feature, we provide a unique identifying label so the portfolio always knows where to go for that specific artwork. Accompanying that label is the unique asset's Name and Description so our collectors, marketplaces, and all-around art enthusiasts understand with what we have filled our portfolio. This information could not be part of the metadata (see packing/unpacking note above) so we handle it in a more robust yet simple fashion. This index of information in the portfolio is infinitely extensible, editable, and incredibly useful. It also keeps our metadata super clean and legible.

1 reply

0 recast

0 reaction

JestemZero pfp

In the simplest breakdown, extraUri is a metadata element, like any other, that stores the on-chain artwork data. On its face it looks like all of the other URI elements such as artifactUri, thumbnailUri, imageUri, etc. But with extraUri we need more than just a storage field. We need the ability to modify, rename, provide details, add, and remove as many pieces of art as we need. In order to accomplish this ability, the metadata element is coupled with a high level tezos-storage element which is responsible for controlling the quantity and information we incorporate. [Technical explanations omitted for pleasantness, but I'm open for questions.] This tezos-storage element acts as a portfolio we can increase, updated and edit. As often as we like. For as many different types of artwork files we want. All stored on-chain.

1 reply

0 recast

0 reaction

JestemZero pfp

A hurdle is nothing more than something to jump over. Or, in the worst-case scenario, something to push right over. Through many iterations, many attempts, many do-overs, I developed a novel mechanism that not only knocks over those hurdles but clears them from the track forever. Why is this a big deal? Because artists deserve options. Artists deserve tools. Artists deserve freedom to explore and experiment. And there are countless uses for bundling multiple files in one artwork token. This new extraUri mechanism gives us this. What is it? How does it work? Will it break marketplace listings? Keep reading to find out.

1 reply

0 recast

0 reaction

JestemZero pfp

Original inspired by the Doppelgänger contract from Transient Labs and @amadon.eth, I was always impressed by the Tezos metadata standards that had a built-in way to allow for multiple files or filetypes within a single artwork. With both the formats[] and assets[] arrays, an artist has the ability to incorporate numerous formats, sizes and options for their art. However, it turns out these are inaccessible to on-chain artists and really truly function only with off-chain storage. (I will skip the packing/unpacking/transaction size discussion here, but feel free to ask me if you are interested.) Tezos also has an externalUri metadata element, but this only allows for a singular additional file to store. So what is an on-chain artist to do you might ask? Build it themselves, of course!

1 reply

0 recast

1 reaction

JestemZero pfp

#ZeroContract Feature Highlight #6: ○ Ability to add infinite types of artwork Ever wish you could pack various types of art into a single token? Do you want to let collectors buy multiple versions, multiple aspect ratios, multiple assets all in one package? Bundle together images, audio, video, code nicely all as one piece of art? Most standards only let you add a handful of files, or just one link, and rarely work with on-chain assets. That’s limiting for creators who want to offer more. Introducing extraUri as a new way for artists to attach unlimited types and numbers of files to one token. Think of it as giving your art its own portfolio that can hold and display different files, in any format you want, and you can add as many as you like! I will try not being too technical here, but there is a lot of technical limitations we are pushing thru now with this new mechanism I think should become a future Tezos standard.

1 reply

3 recasts

4 reactions

JestemZero pfp

0 reply

0 recast

0 reaction

JestemZero pfp

While it would have very few applications or users, the idea of creating an anarchy contract is pretty enticing . . .

1 reply

0 recast

1 reaction

JestemZero pfp

Much like before, this is an execution decision. It would be possible to let the artists destroy it, or any owner actually, at any time but that would be mayhem! Destroy removes the entire ledger entry. The artwork is not allowed to be own, sold, etc. So if there are 10 editions, the artist owns 5 and wants to Destroy them, it would actually destroy all 10. So this is just a failsafe so an artist does not act in bad faither, or just make a mistake, and Destroy something other people own. Which would be like changing the artwork image without the collector's knowledge, but multiple times worse. The artists can always burn their editions, just not Destroy the artwork completely. Maybe I will look at incorporating a partial Destroy in a future version. Where an artist reduces supply (destroying their 5 editions).

1 reply

0 recast

1 reaction

JestemZero pfp

Yes. This is not new. I didn't create the mechanism it is just not widely understood.

1 reply

0 recast

1 reaction

JestemZero pfp

With the ZeroContract we do not have an integrated Burn mechanism anymore. Since this is just a send operation we rely on the transfer function. We do now, however, have a new Destroy mechanism. I have ensured that only the original minter can destroy a token. And they can do that if and only if they own all of the editions. The Destroy function becomes locked and inaccessible when any other address owns an edition. This also includes the Burn address. If one token is sent to the burn address, the artwork could never be destroyed. But it is an action that can be taken at any time. If an artist wants to destroy some art, they have the option of trying to buy back all of the editions. Once the artists owns them all a gain, Destroy is unlocked.

1 reply

0 recast

4 reactions

JestemZero pfp

Zero Contract Feature Highlight #5: ○ True Destroy of art versus Burn There is a large distinction here and I feel we need to change our language. The most common "burn" that people understand is sending a token to a burn address. This is used all the time. And it is the only way a collector has to get rid of a token. But in reality, this is just a token transfer to another wallet. This results in the artwork technically still in circulation just owned by a dead, unmanaged wallet. Destroy, in contrast, removes the token from circulation. The blockchain ledger takes it out of the entries. For provenance, we do keep the metadata information, but the token is now more a historical reference and nobody can ever own it again.

2 replies

2 recasts

8 reactions

JestemZero pfp

Of the five collections below, the ZeroContract Artist Studio is the most recent. I made this collection specifically to be a Parent "umbrella" for associated collections. You can see it has two children projects "Zero Contracters" and "ZeroContract Artist Studio | Abundance". This feature is very much about organization and not necessarily provenance (unlike Bitcoin Ordinals relationships). It is a means to logically connect artwork collections together in a meaningful and useful way.

0 reply

0 recast

0 reaction

JestemZero pfp

ZeroContract Feature Highlight #4: ○ Family relationship between collections The Parent/Child relationship has been in the ZeroContract from nearly the beginning, but it is still the least adopted feature. This is in part that on the ZeroView I built displays this information. No marketplace or wallet has adopted this, so even if used, there is only one place to view it. That said, to me this is incredibly useful, and I feel will grow in adoption over time. For any collection, the artist is able to create soft links with other collections. Creating a hierarchy between collections, no matter when they are created. I think I am the only person who has used this, but you can see the example below:

1 reply

1 recast

2 reactions