FWIW,
https://memo.cash/ already exist. While it's created for BCH network, it should work on BTC without major change since it rely a lot on OP_RETURN.
Every BitStory message is a compact JSON object with at least:
--snip--
1. What is goal of including ECDSA signature? Isn't fact someone create a transaction is enough?
2. Why JSON over format that may have smaller size (such as MessagePack)?
Memo.cash is an interesting reference, but it encodes application-specific social actions directly on-chain rather than defining a generic, application-agnostic message layer.
Memo defines a fixed set of operations (post, like, follow, etc.) and implicitly ties authorship to the address that funds the transaction. This is a valid design choice, but it couples identity, payment, and application semantics.
BitStory takes a different approach. It defines a generic, signed messaging protocol with an explicit cryptographic identity layer. Messages are signed independently using recoverable secp256k1 signatures, and the author’s public key is recovered from the message itself.
This separation is intentional: paying for a transaction does not necessarily mean authoring its content. BitStory allows messages to be funded by any address, while identity remains stable and verifiable across reposts, mirrors, and independent indexers.
JSON is used deliberately, not for efficiency but for durability: it is human-readable, deterministic once canonicalized, easy to debug, and trivial to implement consistently across languages. For a protocol meant to be recovered decades later, readability and interoperability matter more than saving a few bytes.
BitStory targets Bitcoin mainnet. Publishing on the BTC main chain maximizes long-term durability, archival guarantees, and independent recoverability compared to application ecosystems built on smaller or more mutable chains.
The core difference lies in encoding application behavior versus defining a shared, signed, and durable messaging protocol.
