Core Data Design for Metanet Microblog Posts

post-data-core-design.md

Core Data Design for Metanet Microblog

Author: @cloudsay | Website: microblog.bitspv.com

This document outlines the core data design for Metanet Microblog, an open protocol for decentralized social media. It enables developers to build diverse applications on a shared, on-chain data layer where users retain full data ownership. This text details the protocol's design and the trade-offs involved, aiming to accelerate innovation on BSV.

1. Core Architecture: On-Chain Key-Value Store (KVStore)

• Technology: Core data is stored on the BSV blockchain using the GlobalKVStore component from @bsv/sdk.
• Data Model: A simple Key-Value model where the key is a unique string and the value is a JSON string.
• Benefits: Data is public, verifiable, allowing anyone to build applications on the protocol.

2. Data Isolation: Protocol IDs

• Mechanism: A unique PROTOCOL_ID is defined for each data type (posts, likes, etc.) to create separate namespaces.
• Implementation: The primary protocol IDs include:
  • [0, 'Microblog Posts v1']: For posts.
  • [0, 'Microblog Likes v1']: For likes.
  • [0, 'Microblog Reposts v1']: For reposts.
  • [0, 'Microblog Comments v1']: For comments.
  • [0, 'Microblog Tips v1']: For tips.
• Advantages:
  • Namespace: Effectively prevents key collisions between different data types.
  • Extensibility: New data types (e.g., bookmarks, polls) can be added in the future by simply defining a new PROTOCOL_ID without affecting existing data.
  • Query Efficiency: Allows for efficient, categorized data queries based on the PROTOCOL_ID.

3. Key Data Structures and Relational Design

a. Posts

• Key: post_{authorPublicKey}_{randomNonce}
  • authorPublicKey: Identifies the author.
  • randomNonce: Ensures key uniqueness, preventing collisions from rapid posts.
• Value Format (JSON):
  • Original Post: { "content": "...", "timestamp": 167... }
  • Repost: { "content": "...", "timestamp": 167..., "isRepost": true, "originalAuthorPublicKey": "...", "originalUuid": "..." }
    • isRepost: true is an explicit flag.
    • originalAuthorPublicKey and originalUuid link to the original post being reposted.

b. Relational Data: Likes and Comments

Relational data is managed through strategic use of Keys and Tags for efficient linking.

• Likes:

  • Key: like_{post.outpoint}_{likerPublicKey}
    • post.outpoint: Links the like to the original post.
    • likerPublicKey: Ensures a user can only like a post once.
  • Tag: ["post_id_{post.outpoint}"]
    • Purpose: Allows efficient querying of all likes for a specific post.

• Comments:

  • Key: Similar design to likes.
  • Tag: ["comment_on_{post.outpoint}"]
    • Purpose: Allows efficient querying of all comments for a post.

c. Repost Relations

• Tags: ["repost_of_{originalPost.key}", "reposted_by_{reposterPublicKey}"]
  • repost_of_{originalPost.key}: Links to the original post's key to find all its reposts.
  • reposted_by_{reposterPublicKey}: Identifies the reposter to find all their reposts.

d. Atomic Tips with a Single Transaction

To provide a seamless user experience for tipping, a fund transfer and metadata record are combined into a single atomic transaction, avoiding separate wallet confirmations.

• Implementation: A single transaction is constructed with two outputs:
  • Output 1 (Fund Transfer): A standard P2PKH output that sends satoshis to the author. It uses a PeerPay-style (BRC-29) key derivation to protect the recipient's privacy.
  • Output 2 (Metadata): A PushDrop output that creates a GlobalKVStore record for the tip, containing the key, value (amount, timestamp), and tags.
• Atomicity: This dual-output structure guarantees that the fund transfer and metadata record are inseparable—they either both succeed or both fail.
• Notification: The recipient is notified of the tip via an off-chain message through @bsv/message-box-client.

4. Conclusion

The Metanet Microblog protocol represents a starting point for decentralized social media, balancing performance with user sovereignty through on-chain data ownership and client-side flexibility. This is just one implementation, and we hope it inspires the community to innovate further. We encourage developers to build upon, or create competing protocols. The ultimate goal is a rich ecosystem of user-centric applications, and we look forward to seeing the superior solutions that emerge.