Not exactly a Bitcoin fork, but the Factom project (factom.org) uses their own data structures and the Bitcoin blockchain to store information in an immutable way.

The user first creates a digital fingerprint of his data that gets into the Factom ledger/blockchain. Then, at regular intervals, the fingerprint of that ledger is published to the Bitcoin blockchain. This way, the amount and complexity of the data that can be much bigger than if that user puts the hash of his information directly on the Bitcoin blockchain, which is limited in size and expensive to publish to.

The project tries to give tools for proof of existence, proof of process and proof of audit.

But Factom does not store information actually. It storesonly signatures of documents.
– SklavitMay 8 '16 at 14:50

You are right. It only stores hashes, not the actual information. I'm not sure if any projects tries to store the actual information in the blockchain, but that would be really inefficient.
– Fernando GutierrezMay 8 '16 at 15:14

Why not efficient? It may be something like forum based on blockchaine.
– SklavitMay 8 '16 at 16:20

1

A blockchain is not efficient to store information because it generates thousands of copies of the information. In Bitcoin's case, transactions are small, but even with that many people argue that it doesn't make any sense to copy the payment for a coffee in thousands of copies of the blockchain that live in different computers.
– Fernando GutierrezMay 8 '16 at 17:00

Yes, there is no sense to save copies of coffee payment, but for some valuable information it may have sense.
– SklavitMay 8 '16 at 22:13

Blockchains are more complicated than other distributed storage applications, because they have to enforce a global ordered history. It's very important whether Transaction A or Transaction B came first.

This is a huge design constraint, and it makes it much harder to design scaling solutions. Any prior block could potentially affect the validity of a new block, so new clients must download every old block and check them.

It doesn't make any sense to keep this constraint if you're designing a distributed data storage system. If there's a missing piece of data for an old block, the storage system should ignore that and keep going.

As I understand, most of DBs like PostgreSQL also ensure strong ordering of all transactions.
– SklavitApr 5 '17 at 21:48

They don't enforce ordering between different databases. If I have a database tracking bird migrations, and you have a database tracking parts in a warehouse, there's no synchronization between them. If I start an operation before you start an operation, there's no guarantee that mine will finish before yours. In contrast, if my transaction gets into the blockchain before yours does, it will always run first, even on nodes that do initial block download years later. (Barring a re-org, anyway.)
– Nick ODellApr 6 '17 at 0:28