You are viewing a single comment's thread from:
RE: The Old Dog Discusses: Taking Steemit to The Next Level!
The very point would be "where to store the images". A good answer could be that ipfs seems to be the best companion for a blockchain: https://ipfs.io/
Is not the first time ipfs is used for similar things: openbazaar is making use of ipfs too, also for storing images of products, and it rocks https://openbazaar.org/
Great points and I'm certain that within the community we have the capacity to pull it off!
I have been wondering why we don't use BLOB base 64 encoded data for images embedded directly in the blockchain? I use a Google chrome extension called SingleFile to save while webpages as single HTML files and all images are included in this way.
This is a post about using a MySQL database for the images but it relates to this idea and was the quickest related link I could find on Google:
http://stackoverflow.com/questions/34111390/displaying-blob-image-from-mysql-database-into-dynamic-div-in-html
Being honest I am a bit skeptic about both :
Putting a Hex/base64 representation right into the blockchain would make the ledger to explode in size. Since a blockchain works because there are many copies of the public ledger, this would make the life impossible to anyone which wants to keep a copy of the ledger using a home computer. Sure, a 100TB ledger is still accessible today in acceptable times, if you have quite an infrastructure. But, this will lead to a centralization of ledgers, in the hands of a few people which has 100TB of space on a very fast storage. For reference, consider BitCoin only stores a few data about transactions, and is more than 100GB right now.
https://blockchain.info/it/charts/blocks-size
And each time you look to the past transactions, you need to parse all of them. If you go from some Kb per transaction to Megabytes per transaction, 100GB would become 100TB. And to parse 100TB to find what you want is not as easy as it is with 100GB.
The second idea, to use a SQL server, could work better , until you don't want resilience. Again, the main advantage of a clockchain is decentralization: which means, there are copies everywhere of the same ledger, and each item is the same within each copy. Using a local sql server would mean that ledgers have no such a copy of the data, or worst, they could put THEIR copy of the data (=image) in THEIR sql server. Until mysql is not going to be distributed and decentralized, it doesn't fits very well with a blockchain.
This is why I was thinking to ipfs: it allows you to store any content inside a P2P ledger, similar to the one you use with torrent, using a distributed cache of hashes. Each entry has a fixed size URL, so that, you could store the URL into the blockchain, and the content into IPFS. In such a case, the blockchain would keep into a predicable size, and the content would be distributed AND impossible to manipulate.
and... 23 days later! He responds:
(I have been using the Busy app on my phone and apparently I was not getting notifications about comment replies)
I truly appreciate your detailed and reasonable response and agree with everything you said. I really want to see this IPFS implemented because managing my images and the URLs to them is of great concern to me. If I take the time to post content I care about, content I actually want to be accessible forever, I do not want to have to continue keeping my images hosted in the same place with the same URLs forever too! What if the 3rd party image hosting changes the URL scheme or shuts down, what if I change hosting companies myself, what if I am no longer physically present?
Thank You for Being You,
@aaronsuncamacho