This is correct. Imageboards would not work well as their own blockchain.
That doesn't mean that PoW is a bad idea to implement into an Imageboard as a spam-preventative measure.
There was a proposal like this I found on BitMessage that mentioned using PoW as Identity. Copying below if anyone is interested.
In the current year, most Chans are isolated and are not intended to interoperate with each other. Thus, the content being posted on one chan is easily censored and is not mirrored on any other Chan. The closest thing to a Decentralized Chan that we have is BitMessage. This, however, requires the user to install software and is also subject to spam attacks where an attacker with sufficient resources can flood a channel with irrelevent or even illegal content.
DecentraNet would aim to mitigate a few problems:
1. User-friendliness (through web-facing nodes)
2. Spam Attacks (through Pow as Identity)
3. Censorship (through distributed storage)
## Proof-Of-Work As Identity
Currently, BitMessage uses PoW in order to lower spam levels on the network. This is done on a per-post basis which means that in the event of a spam attack, it is almost impossible to block or identify the spammer. Provided the PoW is sufficient, the message is deemed valid.
DecentraNet would not rely on a PoW per message as the basis for mitigating spam, but would rely on PoW per Identity. This means that for each Identity created, there would be a large PoW involved. Messages posted would then have to be tied to an Identity, making it easier to filter out identities that users deem to be posting non-informative content. The Proof Of Work here would be determined by each node relaying the content (but would probably be quit large).
Obviously, this PoW is too much for the average user. However, it is not intended that all, or even most, users will run a node. Instead, we will rely on some nodes providing a web front-end that submits posts from the node's identity on behalf of the user. From a user point of view, the frontend would operate the same as Chans do today.
## Frontend Node
As an example, imagine we had the site decentralchan.org. Decentralchan.org looks the same as most Chan sites today. It also features a Captcha to mitigate spamming.
DecentralChan.org has taken the time (and processing) to generate an identity that allows it to post on the DecentralChan Network. When a post is made, DecentralChan.org proxies it through their identity and posts it onto the DecentraNet. The message posted will be in JSON format to allow for extensibility (fields like Tripcode, Name, Email, etc).
All other identities that post on DecentraNet will also show on DecentralChan.org - provided DecentralChan has not Blacklisted their identities. This allows optional censorship for the Node Operator. If an Identity is frequently posting illegal or insensible content, then that node can choose not to store or propagate its content.
A Node can also specify a data threshold on a particular identity so that if that identity posts too much within a set time period, all further posts are ignored.
Because the propsed format is JSON, the client can choose how they wish to attach files or view files. To keep data usage low on the network, it is recommended that IPFS is used for file attachments and the IPFS hash of the file given instead. This would prevent duplication on the network.
If this approach is taken, it is recommended that the Front-End Nodes host an IPFS Gateway that allows uploading and downloading. Other Front-End Nodes can then mirror this content.
## Others That Wish To Run A Node
Anyone is free to run a node and collect all data posted to the Network. In this way, it is intended that this network would be incredibly difficult to censor in all cases.
However, to post on the Network, a user MUST generate a valid identity.
## Possible Use Cases
This framework could be extended to the following Use Cases:
- Twitter-Like services (through Twitter-like nodes. Node could post on behalf of user or users with sensitive information could generate their own identity, mitigating the trust issue.)
- Leaks-Like service (each media agency could monitor and mirror a "leaks" channel.)
- Offline Instant Messaging (a message cache-type channel - useful for services like Tox to replace independent Master-Nodes implementation. A user could choose a Front-End node to interface with for Offline Messaging - or could again generate their own identity if trust is an issue)
This is all just a proposal. All thoughts and contributions welcome.
Message me on BitMessage if you have any suggestions/contributions: BM-2cVoCYnYy8k5xrpRNS97YJKG4NB554F8Bq