On my last post, “BitTorrent based publishing“. I opened up the topic of peer-based distribution of media.
I set out what I thought would be a reasonable data format for packets of shared media. Posts, comments, video, pieces, etc.. There was, however, one slight oversight that could lead to a whole lot of needless headache.
That little ID field which would be not out of place in a database table definition.
This was not a table definition, though.
This became obvious when I started trying to work out how to include a hash for a JSON object in the same object.
A long story cut short, that is a truly terrible idea.
Slightly longer story, this could work but would be fiddly and a huge headache. Also, there was an easier way to do this – we use the ID as the URI therefore, everyone in the exchange knows the ID already.
Simple.
The newer, easier to use format
Thus, we have one little change. The ID being outside of the JSON (or whatever) data construct. Now the SHA-256 signature of the object is just the digest of the whole object.
Nice and easy.
Now I can go on to more interesting parts of this idea. Things like specifying a proposed API standard. Not to mention peer tracking and exchange.
I also had another thought regarding the source field. Author authenticity could be assured by using a public key and private key pair to create a signature to add to the source field. I’m sure there are many other interesting potential uses for this field too.
What do you think of this single conceptual change?
Let me know your thoughts in the comments.
