With MetaHandles you can tag or bookmark your onchain content onchain. This solves the accessability problem: It allows you to access any given content with any self chosen word. If you know what you search, it will be always there.
Using the Bitcoin SV Blockchain as a cloud system for data is one of the most interesting developments in crypto these days. The more you think about it, the more it makes sense.
There is a lot of excitement in the BSV developer community. We see new projects and startups every week, and a lot is brewing in the backend. Enabling serverless servers gives BSV a unique usecase, which has just started to play out.

The accesability problem

However, in almost most cases, you, as a user, hit against an obstacle: You must know the transaction id (txid) to access the file. The txid is a very long hexadecimal string. For example:
58bcc6e401861fe36888f969ec8596987676e9248e3ce318b514ef9862ee5600
With this txid you find a very nice blog post of Zangelbert Bingledack: "Bitcoin Embodies Capitalism and Western Civilization, and Why it will Never be Banned". But you will not be able to memorize the txid. If you don‘t write it down or store in in your browser, you lose access. If you lose the paper or use another browser, you will lose access.
For example, on the "Hello Metanet" workshop in Berlin, we put the Hello Metanet website onchain, using the b:// protocol and etched. Shortly later some of us did no longer know the txid. So we were unable to access what we just build.
Let's call this the accessability problem.
Since the data revolution in February I am fighting with this problems. I bookmarked interesting onchain content, but my library quickly filled up. I tried to host a wiki with txids on my website, but it was abused from some casino advertisments, and I don't have the time to care about this. All solutions have been annoying to use.
Wherever you store the txid, on your own computer, or on a cloud server – it is possible to lose it and thus lose access to the content. What's the purpose of storing data immutable, for eternity and freely accessable - if access to it relies a medium which can be easily desctructed? Doesn‘t this reintroduce the reason why we need blockchain in the first place?

Solving Bitcoin problems by using Bitcoin?

The Hello Metanet workshop was amazing. We were a small group of people, it was a dense and electrifying atmosphere; everybody had his ideas what to do with the Metanet, and we all were eager to digg deaper and learn. There was the strong feeling that we are at the beginning of something huge; even some people of the Berlin BCH scene showed up and enjoyed the atmosphere.
On the evening my head rotated around the accessability problem. The current situation is unsatisfying. How can we make onchain content better accessable? Since a blockchain is always on, it could have the perfect possible accessability. But it hasn't.
I thought about the mantra of Ryan X. Charles: Every problem with Bitcoin can be solved with Bitcoin. If you collect the txid – as a bookmark or on paper – you are dependent on an external solution. You try to solve a Bitcoin problem without Bitcoin and reintroduce a new problem.
What if we put the access information itself on the blockchain? I got a funny feeling. My idea was this: Take a word (or a hash of it), like "mysemisecret_file.pdf", and add the id of the transaction containing the file. Than put both in an opreturn transaction, and fire it up. So you will have the link between a keyword and a txid on the blockchain itself.
Problem solved? To find the file later, you have to search the blockchain for the word (or the hash of it) with Planaria or any other Blockchain provider. With Planaria we could even have instances which only store such „handle“ transactions. So it would scale very well.
I sketched the idea, planned and let my head spin until deep at night. On the next morning PaulDB introduced into creating a simple onchain chat using Planaria and MoneyButton. I listened, read the admirable documentation of Planaria and BitDB and played with examples of it. I wanted to find out if such "metahandles" - that's how I called them - are possible.
In the afternoon, after I was so much into my little project, that I didn't even notice we were ordering Pizza, I knew they are.

Setting up Metahandle

The weeks after the workshop I couldn't resist to create Metahandle.net. I am not a developer, I am a writer, and my daily job is to write, not to code.
Over the years I learned a little bit of web coding, but actually, I am bad at it. I also find it painful to design a website and set the css, while not being familiar with frameworks. So all my websites look like straight from the internet 10 years ago.
But it works. The prototype is on the domain metahandle.net. Take it as a beta version. It does what it is made to do: It let you reference and find onchain content with any word you want. Just try it. It will make your live mucher easier, when you are interested in onchain data. If you are interested in using MetaHandle, use it now. Look at public handles, set your own. It just works.
If you activate „publicize handle“, your handle will be stored in our own database and showed up at the homepage. This helps Metahandle.net to create a collection of public handles, which makes access even easier. If you don't activate it, we don‘t know nothing about your handle.
Using MetaHandle allows you to just tag any onchain content with any word you like. You can use it to tag something (like Games or blog), use it as a password for your private collection or give the file an individual name. It‘s extremely flexible. It will help you to never again forget how to access fabulous onchain content like the blog of Zinglebert Bingledack.

Blockchain as a database

The metahandle website consists of one single file. It only uses one database column for public handles. The main database is the blockchain.
All data is onchain, the site is just a simple interface. The code of it is open source and can be found on github. A good developer can create a much better site in short time, and I wished someone did. The protocol is really very easy. I also wished some blockexplorer or Bottle catch on with the idea. I am not so interested in earning money with managing the site.
But at least I registered a BitCom address for MetaHandles 1NYJFDJbcSS2xGhGcxYnQWoh4DAjydjfYU. Anybody can use it. This BitCom address helps to identify a MetaHandle on the blockchain, and it will help to setup a scalable and customisable MetaHandle planaria node.
But let‘s get to the point: How does it work? What does it do for you?
When you create a Metahandle, you have to provide some values: An Handle, the ID of the transaction you want to bookmark, a title and a description. With this info a metahandle transaction is composed which the user can execute with moneybutton.

Data Structure of a MetaHandle

The MetaHandle transaction contains an op_return string with the following content:
<BitCom Address> <Hash(handle)> <versionNumber> <txid> <S4> ...<Sn>
The BitCom-Address is the 1NYJFDJbcSS2xGhGcxYnQWoh4DAjydjfYU. As the owner of the key to this address, I described the BitCom protocol for metahandles in a few transactions. This helps to identifiy MetaHandles, and at some point in the future it might help to allow Bottle and other onchain services to automatically use Metahandles.
The next field in the op_return output is a hash of the handle. I used SHA256, but you could also use scrypt or some other algorithm. This would just require to file another version number (we‘ll see soon). In my implementation the purpose of the hash is not to make the handle truly secret - it should just prevent searchability and give a mild amount of privacy.
The versionNumber explains how to decrypt the handle. It could specify the hash algorithm used to hash the handle, but mostly determines how to interprete the fields after it. The versionNumber has six digits, like 010101. You can look it up on BitCom. The first two digits determine the type of the handle, the second two the subtype, and the last the version. I will explain this at the example of the first two version numbers.
The txid is the link to the content. It can be encrypted, using the handle itself as a password, but I did not put this on default. Having the txid in cleartext will allow to create cross references, so an encryption of the txid would make the handle less valuable.
S4-Sn: These are textfields describing the content or providing credentials to decrypt them. For example, one is the title of the file, the next the description, and the last the salt needed to decrypt them. But as long as it is registered by a version number, it can have whatever fields are needed.

Basic Handles

At this time I only implemented two versions of the handles: 010102 and 010202.
010102 Basic Handle
This is the basic handle 01, subtype 01, version 02. It had an older version before, which I put away. Upgrading the handles can be backward compatible, depending solely on the interface.
The basic handle tags a transaction with any word or password and adds a title and a description, which are both encrypted with the handle. Like the Hash, the encryption is not meant to make it absolutely secretive, it is rather made to give a bit privacy and prevent searchability.
This is the construction:
Address Hash(Handle) 010102 txid E(title) E(description) salt
These are the positions s0 to s6 in the opreturn string. Title (s4) and description (s5) are encrypted, using the handle as a password and the salt (s6) to decrypt it.
Encryption is not necessarily super secret. If you use a very strong password to access your collection, you might be „secure enough“ for the foreseeable future. But that‘s not the point of it, as said below. Hash and encryption are here so that you have to know what you search, before you find something.
This handle can be used in a variety of ways. It can be an account, where a username curates his favorite onchain content. It can be the name of a service, maybe with addons or dates; it can have filenames like „c://ich/mysemisecretfile007.png“; it can be simple tags, like Games, library or blog; and in can be a strong password to store a collection of private handles. I guess there are more.
This version of the basic handle is not made to be collission resistent. This is not bad, this is good. A handle can be public, like „Games“. It should be allowed to be fill‘d up with more referenced transactions. We can easily filter double txid in the search result and prevent users from re-handeling a txid, if that ever becomes a problem.
010202
This variant of the basic MetaHandle is meant to be a bit more private:
Address Hash(Handle) 010202 E(txid) E(title) E(description) salt
As you see, the transaction id is encrypted too. This has the purpose to prevent your private handle being spammed. Someone could copy the whole handle and replace the txid with another one, all without knowing the handle. This could mislead a user to end on the wrong page.
We could filter this out by only showing the first handle with a certain title. With 010202 we go another route and encrypt the txid too. It‘s a competing model, which allows more privacy. But it also has the disadvantage that it disenables cross-references.
Cross-references can be very interesting. They might allow to see how many handles a transaction id has. This could be understood as a graph of accessability of a data. Such and other cross-references should not be cut off, if not necessary. So I disabled txid encryption by default. You can activate it with a click.
Both handles are far from perfect. I‘m not an experienced coder, and I see a lot of things to do. Add a salt for each text field, hash the handle with a more hardware resistent algorithm like scrypt. Maybe this can become versionNumber 010103.

Just the beginning

While building MetaHandles, I realized that they are not just useful for simple bookmarks or tags.
MetaHandles can solve a lot of problems with onchain data. They are basically just ANY reference to ANY transaction with ANY information. Instead of being in an order of transactions, MetaHandles jump directly to any transaction and adds information and accessability.
You could attach technical metadata to any file: announcing an update, making it prunable, specify screen and device information, adjusting to new BitCom protocols or Bottle developments. Another idea are more secure brainwallets or adding value (BSV) to data by locking it. Upvotes, Downvotes, Warnings, Comments on txids. And so on. You can imagine MetaHandles like cellular organizing elements in the data graph of a blockchain.
I don‘t know yet how many of those problems are already adressed by other concepts and implementations, like d:// or some of all the awesome things the BSV development community creates. It‘s too much to follow it all. Since it might be pointless, I don‘t go deeper at future plans for handles. Anybody who wants to help me make it better is highly welcome.
My whole intention of creating MetaHandles was to get an easy access to onchain files. I think this already is a good thing. It solves the accessability problem for onchain data. Have fun using it! And excuse, if my server is a bit slow. I never tested it on scale.
*picture: "Door Handle" by Dushan Hanuska via flickr.com. Licence: Creative Commons

 

$2.50
25.0¢

Reviews
2 of 2 reviewers say it's worth paying for

0 of 2 reviewers say it's not worth paying for