I propose that we migrate the stamp 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 stamp file data mirror… further ensuring the longevity and availability of stamped files.
CIP: 27
Title: STAMP Filesystem
Author: Jeremy Johnson (J-Dog)
Discussions-To: https://forums.counterparty.io/t/cip27-stamp-filesystem/6565
Status: Draft
Type: Standards
Created: 2023-04-20
# Abstract
Mirror `stamp` `file` data to a local filesystem
# Motivation
Migrate `stamp` `file` data out of the counterparty database and provide a `stamp` `file` mirroring solution.
# Rationale
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.
show original
sull
April 23, 2023, 5:26pm
#2
Might as well integrate an IPFS node, pin and store CIDs.
CIP27 - STAMP Filesystem Status changed to Withdrawn
Alternate CIP for a File Mirror System is in the works
