Which is More Valuable: A UID or Hash?

in Proof of Brain3 years ago

I am developing a program called the Infinite Doodle. I will put the posts about the programming on Proof of Brain and Archon. I will put the images on Creative Coin

But first the news: It appears that my application to NFT showroom was declined. In some ways I see that as a relief. I am far more interested in the process of creating art than in finished pieces. The NFT world seems has an exclusive focus on finished pieces.

I can highlight this issue with the question:

Which is more valuable: A Unique ID or a Hash?

The NFT market is built around the idea that there is some sort of intrinsic value to a hash. I suspect that this is due to a belief that a hash is somehow free of centralized authorities.

Most unique IDs are based on sequence counters and the sequence counter must be issued by a centralized authority. For example, my unique ID for HIVE is 912,570. A central authority called "SteemIt Inc" issued this number a few years back.

IDs issued by a central authority create a dependency on that authority. SteemIt Inc was captured by Justin Sun. The community responded to the capture by creating a hard fork that preserved the unique ids and created a new blockchain called HIVE. So, I know have the same UID on at least two blockchains.

It would be nice to create a system that is completely independent of central authorities. But I am not sure if that is possible. A hash creates an imposing looking number which can be used as an ID. To establish uniqueness one must still have a central authority to resolve disputes.

Imagine that two people created a hash from The Gettysburg Address. Both people would have an impressively long number. Assuming their versions of the speech were identical, then their hashes would be identical as well.

Even when one is using hashes, the hashes must exist within a domain. For the domain to function, it must have some sort of authority to resolve conflicts.

So, hashes are only as good as the authority that maintains the hashes. The ToS page for NFTShowroom notes that one of the risks of buying NFTs is that if the central web site fails, the NFTs might lose their value.

This is the same of all art registries and similar authorities.

IMHO, we should let little risks like that stop us.

Now, I've been interested in creating art registries since the dawn of the Internet. NFTShowroom and Lensy are attempts to establish such registries in the HIVE community. I wish the projects success, but see the hash as a gimmick. Is it the best gimmick?

A compelling argument for the hash is that the hash of a file will never change. An art patron can acquired an artwork with a hash. Assuming that the file is never corrupted by a disk error, the hash of the file will always be the same.

An result of the fact that the base file can't change is the idea that the piece of art itself can never change.

Well, in my opinion, never changing is kind of boring.

The inability to change is static. I think that art should have the ability to change.

We can see a great example of why we need change in the logo I created for the OMA.

I spent a half hour the other day and dashed out the OMA logo pictured below.

oma.png

I am not all that fond of the image pictured above, but I don't want to spend time at the moment improving it. I will leave it as is for the moment.

I hope the image changes over time.

Basing the system on UIDs instead of hashes means that I could change the image. I can point to UID to another file, but I could not point the hash to another file.

A system based on UIDs has the potential to be dynamic.

I will incorporate hashes to verify each iteration of the change.

With this structure something fun will happen. People will be able to create pieces which are intended to be changed. The system will record all of the changes over time.

Artist A might publish a piece and sells it to Artist B who mangles it in an attempt at change. Artist C could roll back the changes and make actuall improvements and so one.

This is the basic structure of the infinite doodle.

Each image in the infinite doodle will occupy a numbered cell. Each image will have a unique name. The owner of a cell will have the ability to make select changes to the cell. The system will record the timestamp and hash for each change.

Each image will be uniquely identified by a sequence, the location in the grid and a unique name. I will record changes to the image in a transaction file. This means that each image is dynamic.

I am actually relieved that NFTShowroom declined my application. If I were to publish any of the cells as an NFT; I would have to give up on the inherent dynamic nature of the infinite doodle.

This brings up a nasty problem.

The application for NFTShowroom stated that I could not create projects with duplicate the functionality of NFTShowroom.

So, I thought it would be wise to write down the history of the Infinite Doodle to emphasize that it existed well before NFTShowRoom. Just in case someone from NFT showroom accuses me of plagiarism.

History of the Project

I wrote my first art registry in a programming language called Revelation. I moved it to Advanced Revelation. I tried moving it to OpenInsight, but had problems.

I then moved it to ORACLE. I could not afford to put the ORACLE version online.

I wanted to focus on outsider art. I registered the domain rgreetings.com and developed a version of the registry in PHP and MySQL (I also wrote a version as a Java Servlet). The idea was that people could buy outsider art and trade the art as greeting cards.

I emphasized greeting cards because outsider artists are often frustrated that people are unwilling to display their art. The greeting card makes the art sharable. The rgreetings project incorporated the idea tha an art piece might change with time.

I created an art registry called JuggleArt in the early 2000s. I used this registry to market photos. I created an exchange for trading equities in the mid 2000s called the OSTRX. I was still using PHP and MySQL. I wanted JuggleArt to be the demostration project for the exchange. I decided to the basic structure for JuggleArt IMA. Last year I renamed IMA to OMA.

The original rgreetings project had some connected images. I decided last year to focus solely on connected images in a grid last year.

All of my projects failed to gain traction.

Technically, the cells in the grid are non-fungible tokens. I did not know that word until this year. I contend that a UID is as non-fungible as hash. I welcome opinions. Do you think a system based on Hashes is inherently superior to one based on UIDs?


Posted via proofofbrain.io