Years ago I wrote a post about encoding pictures directly on the blockchain. Text is cheap. Pictures and music have a cost. Video is massive. The conclusion I came to was that, while possible, encoding pictures directly on the blockchain is way too expensive. It was a bad idea. That's fine; they can't all be winners.
In the comments of that post, 
In any case, after doing some cursory research, I've found out that a vector image could be as little as 2KB to 5KB. There are probably some ways to restrict them all the way down to 1KB as well. Given a total max blocksize on Hive of 65KB, that's still kind of a lot, but it's a lot more doable if there's an actual product there and users creating content and getting paid for it.
Normally we think of pictures of a bit-map. A two dimensional grid of pixels. That's the standard. However, vector images are generated by lines of code, which makes them a lot smaller. Like when you're in Paint and you draw a line or a circle or whatever else. If the program knows you drew a line from point A to point B then it doesn't have to save every single pixel of that line; all it needs to know is how to draw the line, and then draw it.
The advantages of vector images is that they are infinitely scalable without any loss or gain of data (they also load really really fast). You can shrink it down and lose zero detail, or you can blow it up and it's still the same file size. All that changes in this case is a aspect ratio variable, and the picture is drawn from there using this variable.
Is it worth it? Probably not... But it's an interesting thought. What's the advantage of doing something like this on-chain instead of having it on some layer 2 or centralized server? Surely, something like this may be better suited to the SPEAK network when it arrives. Putting the data on layer one may just be a novelty that has little value compared to other solutions like IPFS. Still, it's worth exploring every possible option.
Same thing. A music file (MP3 and whatever else) is too big to put on chain. However, given an app that can interpret music, we could just turn the code of the music into NFTs directly on the layer one and use the app to play/interpret the music (which doesn't exist on chain). Again, is it worth it? Unclear, but maybe.
As one of the highest payed bloggers on this network... I get paid very little. I mean obviously if Hive was sitting at 2017 all time highs like Bitcoin I'd be doing just fine. Instead of making $100 posts I'd be making $700-$1600 per post (depending on if $3.50 is the ATH or $8 Steem). Obviously that would be an insane amount of money to be getting paid for a blog post. It all depends on the token price. We'll get back there eventually.
But like I said. We need MOAR jobs. Blogging is dumb. Too many bloggers; not enough value provided to the network. I mean just look around. Look at how many people are trying to jam a square peg into a round hole? If there were other options around here, many users definitely wouldn't be trying to write to earn an income. They'd be doing the other stuff (especially if it was more profitable). Making "art" or "music" is definitely something we should be looking into.
Yeah, I mean even I'm not sure if it should be on layer one. Obviously layer one is going to be more secure than any layer two, but how secure does it really need to be? These are the questions we need to ask when it comes to bandwidth, because bandwidth is precious and scaling up is hard.
This may not be the best idea, but it has just been clanging around in the back of my head for a while. Need to get it out of my head and onto the paper so I can stop thinking about it. I guess the generic strategy we need to be thinking of revolves around our limited bandwidth and how much we can do with it given the proper infrastructure.
Do NFTs that represent vector images and/or music notes have enough value to justify a layer-one existence? Unclear. Honestly we probably won't know until we try. That is the gift and curse of blockchain. Every door must be opened to see if there is a path forward.
