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.
This file has been truncated. 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