I propose that we migrate the
file data out of the database, put it in a local filesystem, and make the
stamp data highly available by adding a weberver to the fedode stack. This effectively makes every CP node a
file data mirror… further ensuring the longevity and availability of stamped files.
This file has been truncated.
Title: STAMP Filesystem
Author: Jeremy Johnson (J-Dog)
Mirror `stamp` `file` data to a local filesystem
Migrate `stamp` `file` data out of the counterparty database and provide a `stamp` `file` mirroring solution.
The popularity of blockchain `file` encoding protocols such as [`Inscriptions`](https://ordinals.com/inscriptions) and [`Bitcoin Stamps`](https://stampchain.io/) indicates users want to store `file` data on a highly-available and permanent medium.
Currently `stamp` `file` data is stored in the `description` field in both the `issuances` and `messages` database tables in [`counterparty-lib`](https://github.com/CounterpartyXCP/counterparty-lib). Storing this data in multiple tables is unnecessary, is bloating the database, and will have a long-term performance impact as we support stamping larger files, and multiple files in the same transaction.
Writing `stamp` `file` data to files on a local filesystem allows for removal of the data from database tables, which helps ensure that the database stays as small and fast as possible.
Might as well integrate an IPFS node, pin and store CIDs.
CIP27 - STAMP Filesystem
Status changed to
Alternate CIP for a File Mirror System is in the works