Documentation

• 1: Architecture
• 1.1: Architecture Diagrams
• 1.2: Smart Contracts
• 1.2.1: Evidence Record Smart Contract
• 1.2.2: Pricing Model: Estimated Cost Impact Assessment
• 1.2.3: Pricing Model: Journalist Income Simulation (1 Year)
• 1.2.4: Smart Contract Pricing Model
• 1.2.5: Relevance Metric: Lippmann Influence (l)
• 1.2.6: Relevance Metric: Universal Dialogue Quality Assessment (UDQA)
• 1.2.7: Relevance Metric: Supply/Scarcity (s)
• 1.2.8: Simulation: Freelance Videographer (State Legislature)
• 2: API Documentation
• 2.1: Domain & Email Reference
• 3: User Guide
• 3.1: Journalist Feedback Survey
• 3.2: Creating Test Ledger Entries for PoC

1 - Architecture

YouSeddit Architecture

Youseddit is built on a multi-layered architecture designed to ensure content authenticity, secure blockchain integration, and a trustworthy marketplace for journalistic content.

System Overview

The platform consists of four main layers:

1. User-Facing Layer

• Email integration for processing conversation turns
• Web application for content management and marketplace access
• Wallet integration for receiving payments

2. Authentication Layer

• PGP/GPG validation for source verification
• C2PA implementation for content provenance verification
• Cryptographic hash verification for content integrity

3. Blockchain Layer

• Evidence Record smart contracts (or similar) for recording each conversation turn’s cryptographic proof on the ledger.
• Off-chain encrypted storage (IPFS) for original email content, linked from ledger entries.
• On-ledger linking mechanism (or C2PA-based linking) to form the verifiable conversation chain, crucially linking responses (quotes) back to their initiating questions for context.
• Smart contracts for licensing and publication authorization
• Payment and royalty distribution mechanisms

4. Marketplace Layer

• Content discovery system
• Licensing options (exclusive/non-exclusive, time-limited, etc.)
• Reputation and rating system

Core Workflows

Youseddit supports two primary content flows:

1. Conversation Chain Workflow: Processes secure email exchanges turn-by-turn (initiator/response) via PGP/GnuPG, validates signatures, encrypts individual email content (including both question and answer) for IPFS storage, records each turn on the distributed ledger with a cryptographic link to the previous turn via smart contracts or similar mechanisms, generates C2PA attestations for each turn containing backward links to preserve the question-answer context, and provides verification paths allowing full context tracing.

2. Media Quote Workflow: Enables direct quote capture, including speech-to-text functionality, with C2PA metadata and blockchain storage

Each workflow maintains strict verification standards and privacy controls.

1.1 - Architecture Diagrams

Architecture Diagrams

The following diagrams illustrate the core workflows and components of the YouSeddit platform.

Verifiable Conversation Chain System

graph LR
    subgraph "Capture & Processing"
        InterviewSource["Interviewer & Interviewee"] --> CaptureApp["Capture App (Audio/Video)"]
        CaptureApp --> STT["Speech-to-Text & Diarization"]
        STT --> SnippetProcessing["Transcript Snippet Processing\n(Identify Speaker/Turns)"]
        SnippetProcessing --> SnippetHash["Calculate Snippet Hashes"]
        SnippetProcessing --> IPFSStorage["Store Snippet Content (IPFS)"]
    end

    subgraph "Attestation & Ledger Recording"
        SnippetHash --> C2PASnippet["Generate C2PA Attestation per Snippet\n(Speaker, Turn Type, Prev Hash Link, Snippet Hash, IPFS Link)"]
        IPFSStorage --> C2PASnippet
        C2PASnippet --> LedgerStorage["Store Snippet Hash & C2PA Attestation on Ledger"]
    end

    subgraph "Licensing & Verification"
        LedgerStorage --> SmartContract["Smart Contract\n(Snippet Licensing & Valuation - Sum Responses)"]
        MediaOutlet["Media Outlet"] -->|"License Snippet(s)"| SmartContract
        ThirdParty1["3rd Party Media Outlet #1"] -->|"License Snippet(s)"| SmartContract
        ThirdParty2["3rd Party Media Outlet #2"] -->|"License Snippet(s)"| SmartContract
        SmartContract --> VerificationAPI["Verification API (Snippet Level)"]
        VerificationAPI --> Validation["Content Credential Validation (Snippet Level)"]
        Validation --> VerificationURL["Public Verification URL (Snippet/Chain)"]
    end

    style STT fill:#bfb,stroke:#333,stroke-width:2px
    style SnippetProcessing fill:#bfb,stroke:#333,stroke-width:2px
    style C2PASnippet fill:#ff9,stroke:#333,stroke-width:2px
    style LedgerStorage fill:#ff9,stroke:#333,stroke-width:2px
    style SmartContract fill:#f9f,stroke:#333,stroke-width:2px
    style VerificationAPI fill:#bbf,stroke:#333,stroke-width:2px

This diagram illustrates the workflow for capturing and verifying interview content using a snippet-based approach:

1. Capture & Processing: Interview audio/video is captured and processed using Speech-to-Text with diarization to identify speakers. The transcript is then segmented into speaker-attributed snippets (turns).
2. Snippet Hashing & Off-Chain Storage: A unique cryptographic hash (snippetHash) is calculated for each snippet’s content. The raw snippet content (transcript segment) is stored off-chain in IPFS.
3. Ledger Recording (Evidence Record): An “Evidence Record” smart contract function is called for each snippet. This records the cryptographic proof (snippetHash) on the ledger along with metadata:
   • A reference (e.g., IPFS CID) to the off-chain snippet content.
   • The type of snippet: “initiator” (e.g., question) or “response” (e.g., answer/quote).
   • Crucially: If the snippet is a “response”, the ledger entry includes a link to the ledger entry of the corresponding “initiator” snippet, forming the verifiable chain. Initiator snippets may optionally link to responses.
4. Licensing & Valuation: Smart contracts manage licensing, potentially at the snippet level. Valuation can be based on rules, like summing the value of licensed “response” snippets linked to a specific “initiator”.
5. Verification: APIs and tools allow validation by:
   • Retrieving snippet content from IPFS using the link in the ledger entry.
   • Verifying the content matches the snippetHash stored on the ledger.
   • Tracing the conversation context by following the initiator/response links recorded on the ledger.
   • Optionally, C2PA attestations can complement this by providing additional metadata about the capture process, linked within the ledger record or IPFS content.

Conversation Chain Workflow: Off-Chain Encrypted Storage with On-Ledger Chaining

This workflow provides a GDPR-compliant system for recording email conversations turn-by-turn onto a distributed ledger, creating a verifiable chain using on-ledger linking and off-chain storage:

graph TD
    subgraph "Process Email Turn N (Repeats)"
        %% Define nodes explicitly first
        YSN[Youseddit System]
        PrevHashInputN[Previous Email Snippet Hash]
        EmailTurnN[Email Turn N]
        HeadersN[Extract Headers N]
        %% Use quotes and <br> for newline and parentheses
        ProvScoreN["Calculate Provenance Score N<br>(Sign/Encrypt, Headers)"]
        EmailHashN["Calculate Email Snippet Hash N<br>(Full Raw Source)"]
        EncryptEmailN["Encrypt Full Email N (Optional)"]
        IPFSStoreN["Store Encrypted Email N (IPFS)"]
        IPCIDN["Generate IPFS CID N"]

        %% Define edges using IDs
        PrevHashInputN --> YSN
        EmailTurnN --> YSN
        YSN --> HeadersN
        YSN -->|Analyze| ProvScoreN
        EmailTurnN --> EmailHashN
        EmailTurnN --> EncryptEmailN
        EncryptEmailN --> IPFSStoreN
        IPFSStoreN --> IPCIDN
    end

    subgraph "On-Ledger Recording (Email Turn N - Repeats)"
        %% Define nodes explicitly first, use quotes if text has special chars or needs formatting
        SCCallN["SC Call Record Email Turn N"]
        LedgerTxN["Ledger Tx N"]
        LedgerRecordN["Ledger Record N"]
        LR_HashN["Email Snippet Hash N"]
        LR_CIDN["IPFS CID N (Optional)"]
        LR_PrevHashN["Link Prev Email Hash"]
        LR_ProvScoreN["Provenance Score N"]
        LR_HeadersN["Key Header Info N"]
        LR_OwnerN["Ownership N"]
        LR_TimeN["Timestamp N"]
        C2PAEmailN["Generate C2PA Attestation N"]

        %% Define edges using IDs
        EmailHashN --> SCCallN
        IPCIDN --> SCCallN
        PrevHashInputN --> SCCallN
        ProvScoreN --> SCCallN
        HeadersN --> SCCallN
        SCCallN --> LedgerTxN
        LedgerTxN --> LedgerRecordN
        LedgerRecordN -->|Contains| LR_HashN
        LedgerRecordN -->|Contains| LR_CIDN
        LedgerRecordN -->|Contains| LR_PrevHashN
        LedgerRecordN -->|Contains| LR_ProvScoreN
        LedgerRecordN -->|Contains| LR_HeadersN
        LedgerRecordN -->|Contains| LR_OwnerN
        LedgerRecordN -->|Contains| LR_TimeN
        LedgerTxN --> C2PAEmailN
    end

    subgraph "Process Final Confirmation (Turn F)"
        %% Define nodes explicitly first, use quotes if text has special chars or needs formatting
        YSF[Youseddit System]
        PrevHashInputF["Last Email Snippet Hash (N)"]
        ConfirmationCode["Confirmation Code Snippet Received"]
        ConfHash["Calculate Confirmation Snippet Hash F"]
        ProvScoreF["Update Overall Provenance Score"]

        %% Define edges using IDs
        PrevHashInputF --> YSF
        ConfirmationCode --> YSF
        YSF --> ConfHash
        YSF -->|Update Score| ProvScoreF
    end

    subgraph "On-Ledger Recording (Confirmation Turn F)"
        %% Define nodes explicitly first, use quotes if text has special chars or needs formatting
        SCCallF["SC Call Record Confirmation F"]
        LedgerTxF["Ledger Tx F (Conclusion)"]
        LedgerRecordF["Ledger Record F"]
        LR_ConfHash["Confirmation Snippet Hash"]
        LR_PrevHashF["Link Last Email Hash"]
        LR_Type["Type: Confirmation"]
        C2PAConfF["Generate C2PA Attestation F"]

        %% Define edges using IDs
        ConfHash --> SCCallF
        PrevHashInputF --> SCCallF
        SCCallF --> LedgerTxF
        LedgerTxF --> LedgerRecordF
        LedgerRecordF -->|Contains| LR_ConfHash
        LedgerRecordF -->|Contains| LR_PrevHashF
        LedgerRecordF -->|Contains| LR_Type
        LedgerTxF --> C2PAConfF
    end

    subgraph "Verification & Usage"
        %% Define nodes explicitly first, use quotes if text has special chars or needs formatting
        Owner[Owner]
        Verifier[Verifier/Reader]
        MediaOutlet["Media Outlet"]
        SmartContractEmail["Smart Contract (Email Snippet Based)"]

        %% Define edges using IDs
        Owner -->|Manage Status| LedgerRecordN
        Owner -->|Manage Status| LedgerRecordF
        Verifier -->|Reads| C2PAEmailN
        Verifier -->|Reads| C2PAConfF
        Verifier -->|Follows Chain Links| LedgerRecordN
        Verifier -->|Follows Chain Links| LedgerRecordF
        Verifier -->|Follows IPFS Link| IPFSStoreN
        Verifier -->|Verify Hashes/Scores| LedgerRecordN
        Verifier -->|Verify Hashes/Scores| LedgerRecordF
        %% Removed parentheses from the edge label below
        MediaOutlet -->|License Email Snippets| SmartContractEmail
        LedgerRecordN --> SmartContractEmail
        LedgerRecordF --> SmartContractEmail
        ProvScoreF --> SmartContractEmail
    end

    %% Link between subgraphs
    EmailHashN --> PrevHashInputF

    %% Styling remains the same
    style YSN fill:#bfb,stroke:#333,stroke-width:2px
    style YSF fill:#bfb,stroke:#333,stroke-width:2px
    style ProvScoreN fill:#e6e6fa,stroke:#333,stroke-width:2px
    style ProvScoreF fill:#d8bfd8,stroke:#333,stroke-width:2px
    style IPFSStoreN fill:#fbf,stroke:#333,stroke-width:2px
    style LedgerTxN fill:#ff9,stroke:#333,stroke-width:2px
    style LedgerRecordN fill:#ff9,stroke:#333,stroke-width:2px
    style LedgerTxF fill:#ffe4b5,stroke:#333,stroke-width:2px
    style LedgerRecordF fill:#ffe4b5,stroke:#333,stroke-width:2px
    style C2PAEmailN fill:#add8e6,stroke:#333,stroke-width:2px
    style C2PAConfF fill:#b0e0e6,stroke:#333,stroke-width:2px
    style Verifier fill:#bbf,stroke:#333,stroke-width:2px
    style MediaOutlet fill:#f9f,stroke:#333,stroke-width:2px
    style SmartContractEmail fill:#f9f,stroke:#333,stroke-width:2px
    style ConfirmationCode fill:#98fb98,stroke:#333,stroke-width:2px

Processing Each Email Turn (Off-Chain - Repeats)

(Steps 1-4 repeat for each email/turn in the conversation)

1. Receive & Hash Email: YouSeddit system receives the next email (Turn N). It calculates a SHA-256 hash of the full raw email source file (snippetHash_N). This hash represents the complete email turn as a unique, verifiable snippet.
2. Store Email Off-Chain: The full raw email source is stored (optionally encrypted) in IPFS, generating an IPFS CID (CID_N).
3. Header Extraction & Analysis: System extracts key email headers and calculates a turn-specific Provenance Score based on factors like digital signatures (PGP/S/MIME), encryption, and DKIM/SPF results.
4. Determine Type & Links: The system identifies the email as an “initiator” or “response” based on headers (e.g., In-Reply-To). If it’s a response, it identifies the snippetHash of the initiator email it replies to (initiatorHash).

On-Ledger Recording (Email Turn N - Repeats)

(Steps 5-6 repeat for each email/turn)

5. Evidence Record Smart Contract Interaction: System calls an “Evidence Record” smart contract function providing:
   • The current email’s snippet hash (snippetHash_N).
   • The IPFS CID (CID_N) linking to the raw email content.
   • The snippet type (“initiator” or “response”).
   • If it’s a “response”, the initiatorHash (the snippetHash of the email being replied to).
   • The calculated Provenance Score for this turn (ProvScoreN).
   • Other relevant metadata (sender, recipient, timestamp from headers).
6. Ledger Recording: The smart contract records this information immutably on the ledger, creating a verifiable entry for the email turn and linking responses back to their initiators. A transaction ID (TxID_N) is generated.

Processing Final Confirmation (Off-Chain - Turn F)

(This occurs once at the end of the agreed-upon exchange)

7. Receive & Hash Confirmation: YouSeddit system receives confirmation (e.g., a specific email reply or signal). A hash is calculated for this confirmation action (ConfirmationSnippetHash_F).
8. Update Overall Provenance: The confirmation may boost the Overall Provenance Score for the entire thread.

On-Ledger Recording (Confirmation Turn F)

9. Confirmation Smart Contract Interaction: System calls a smart contract function (e.g., recordConfirmation) providing:
   • The confirmation snippet hash (ConfirmationSnippetHash_F).
   • The hash of the last actual email snippet (snippetHash_N) to link the confirmation to the end of the exchange.
10. Ledger Recording: The smart contract records the confirmation, linking it to the last email turn.

Verification & Usage

11. Context Tracing: Verifiers can trace the conversation context by starting from a response snippet’s ledger entry and following the recorded initiatorHash link back to the initiating email’s ledger entry.
12. Content Verification: The snippetHash on the ledger can be used to verify the integrity of the email content retrieved from the linked IPFS CID.
13. Provenance Check: Individual turn scores and the overall score (potentially updated by confirmation) provide trust indicators.
14. Licensing: Smart contracts can manage licensing based on verified ledger entries for specific snippets (e.g., licensing a specific response/quote linked to its initiator).
15. Optional C2PA: C2PA manifests can optionally be generated and linked (e.g., via IPFS CID in the ledger record) to provide further details about the email source or processing, complementing the core on-ledger linking.

Security Architecture

Youseddit’s security architecture includes multiple layers of protection:

1. Email Provenance Scoring - Analyzes factors like PGP/GPG/S/MIME signing/encryption and attestation codes to determine the reliability of email exchanges.
2. On-Ledger Snippet Records & Linking - Evidence Record smart contracts store immutable snippetHash proofs for each turn, linking responses to initiators for verifiable context.
3. Off-Chain Content Storage (IPFS) - Original content (email source, transcript snippets) stored off-chain, linked via IPFS CIDs in ledger records.
4. C2PA Content Provenance - Optional layer providing additional metadata about content origin and processing, potentially linked from ledger records.
5. Wallet-Based Authentication - For secure user access control.
6. Smart Contract Enforcement - For automated licensing compliance based on verified snippet hashes and provenance scores recorded on the ledger.

1.2 - Smart Contracts

Smart Contract Architecture

Youseddit utilizes a suite of smart contracts to manage the verification, ownership, and licensing of journalistic content while maintaining GDPR compliance through a hybrid on-chain/off-chain approach.

Core Contracts

The smart contract architecture consists of the following primary components:

Evidence Record Contract

The foundation of the YouSeddit platform, this contract manages the cryptographic proofs of email content:

• Records hashes linking quote snippets to their source emails
• Stores IPFS pointers to encrypted off-chain content
• Manages publication authorization status
• Provides verification mechanisms for publishers and readers

License Management Contract

Controls the licensing and monetization of verified content:

• Manages licensing terms and pricing
• Handles royalty distributions to content owners
• Enforces licensing restrictions based on publication status
• Tracks usage and expiration dates

Publisher Registry Contract

Maintains a registry of authorized publishers:

• Verifies publisher identities
• Tracks licensing agreements
• Manages domain authorization for content display
• Handles subscription models for frequent publishers

Technical Design Principles

The YouSeddit smart contract architecture follows these key principles:

1. GDPR Compliance: Sensitive content remains encrypted off-chain, with only cryptographic hashes and metadata stored on-chain

2. Data Minimization: Contracts store only essential verification information and access controls

3. Verification-First: All contracts prioritize immutable verification paths for content authenticity

4. Decentralized Ownership: Content owners maintain control over their data through cryptographic key ownership

5. Interoperability: Contracts implement standard interfaces for broader ecosystem integration

Deployment Strategy

The smart contracts are deployed on Polygon (PoS) for:

• Cost-effective transaction fees
• High throughput
• EVM compatibility
• Robust developer tooling
• Environmental sustainability

Security Measures

All smart contracts undergo:

• Formal verification testing
• Independent security audits
• Rate-limiting protections
• Proxy patterns for upgradability
• Event monitoring for suspicious activity

1.2.1 - Evidence Record Smart Contract

Evidence Record Smart Contract

The EvidenceRecord smart contract represents a core component for recording cryptographic proofs of quotes within Youseddit’s distributed ledger infrastructure. It facilitates linking quotes to their original context (stored off-chain) while maintaining GDPR compliance. The broader YouSeddit concept involves creating a verifiable conversation chain on the ledger, where each initiator and response quote potentially receives its own entry, linking back to the previous turn in the conversation.

Contract Overview

This specific EvidenceRecord contract example focuses on recording evidence for a response quote, linking its hash (responseQuoteHash) to the hash of the full encrypted exchange (fullExchangeHash) stored off-chain (e.g., on IPFS via storagePointer).

Important Note on Chaining: To realize the full concept of a verifiable conversation chain, the YouSeddit system (potentially using variations or extensions of this contract, or managing links off-chain) must ensure:

1. Both initiator and response quotes ideally receive distinct ledger entries.
2. Each ledger entry (or its associated C2PA manifest) contains a verifiable reference (e.g., transaction hash) to the ledger entry of the immediately preceding quote in the conversation flow.
3. The C2PA manifest generated for any quote robustly encodes this backward link, allowing context traversal.

This contract provides the mechanism to anchor a quote (primarily the response) to its full context; the explicit on-ledger chaining requires further architectural definition or is managed via C2PA references generated off-chain.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

contract EvidenceRecord {
    // Struct to hold evidence record data
    struct Evidence {
        bytes32 fullExchangeHash;   // SHA-256 hash of the complete encrypted email exchange (initiator + response)
        string storagePointer;      // IPFS CID pointing to the encrypted exchange file
        address owner;              // Owner of the evidence record (typically the source/interviewee providing the response quote)
        uint256 timestamp;          // When the evidence was recorded
        bool isPublished;           // Whether this response quote is approved for publication
    }
    
    // Mapping from response quote hash to evidence record
    mapping(bytes32 => Evidence) public evidenceRecords;
    
    // Events
    event EvidenceRecorded(bytes32 indexed responseQuoteHash, bytes32 fullExchangeHash, string storagePointer, address owner);
    event QuotePublicationStatusChanged(bytes32 indexed responseQuoteHash, bool isPublished);
    
    /**
     * @dev Record a new evidence entry linking a response quote to the full exchange
     * @param responseQuoteHash Hash of the specific response quote text
     * @param fullExchangeHash Hash of the complete encrypted email exchange file
     * @param storagePointer IPFS CID pointing to the encrypted exchange file
     */
    function recordEvidence(
        bytes32 responseQuoteHash,
        bytes32 fullExchangeHash,
        string memory storagePointer
    ) public {
        // Ensure this response quote hash hasn't been recorded before
        require(evidenceRecords[responseQuoteHash].timestamp == 0, "This response quote hash is already recorded");

        // Create and store the evidence record
        evidenceRecords[responseQuoteHash] = Evidence({
            fullExchangeHash: fullExchangeHash,
            storagePointer: storagePointer,
            owner: msg.sender,
            timestamp: block.timestamp,
            isPublished: false
        });
        
        emit EvidenceRecorded(responseQuoteHash, fullExchangeHash, storagePointer, msg.sender);
    }
    
    /**
     * @dev Change the publication status of a response quote
     * @param responseQuoteHash Hash of the specific response quote text
     * @param publishedStatus New publication status
     */
    function setPublishedStatus(bytes32 responseQuoteHash, bool publishedStatus) public {
        // Ensure the response quote record exists
        require(evidenceRecords[responseQuoteHash].timestamp > 0, "Evidence record does not exist");

        // Ensure only the owner can change the status
        require(evidenceRecords[responseQuoteHash].owner == msg.sender, "Only the owner can change publication status");

        evidenceRecords[responseQuoteHash].isPublished = publishedStatus;

        emit QuotePublicationStatusChanged(responseQuoteHash, publishedStatus);
    }
    
    /**
     * @dev Retrieve evidence record for a response quote hash
     * @param responseQuoteHash Hash of the specific response quote text
     * @return The evidence record
     */
    function getEvidence(bytes32 responseQuoteHash) public view returns (
        bytes32 fullExchangeHash,
        string memory storagePointer,
        address owner,
        uint256 timestamp,
        bool isPublished
    ) {
        Evidence storage evidence = evidenceRecords[responseQuoteHash];

        // Ensure the response quote record exists
        require(evidence.timestamp > 0, "Evidence record does not exist");

        return (
            evidence.fullExchangeHash,
            evidence.storagePointer,
            evidence.owner,
            evidence.timestamp,
            evidence.isPublished
        );
    }
    
    /**
     * @dev Check if a response quote is approved for publication
     * @param responseQuoteHash Hash of the specific response quote text
     * @return Whether the response quote is published
     */
    function isQuotePublished(bytes32 responseQuoteHash) public view returns (bool) {
        // Ensure the response quote record exists
        require(evidenceRecords[responseQuoteHash].timestamp > 0, "Evidence record does not exist");

        return evidenceRecords[responseQuoteHash].isPublished;
    }
}

Key Features

Data Structure

The Evidence struct contains:

• fullExchangeHash: SHA-256 hash of the complete encrypted email exchange file (initiator + response)
• storagePointer: IPFS CID pointing to the encrypted exchange file
• owner: Address of the evidence record owner (typically the source/interviewee)
• timestamp: When the evidence was recorded on the distributed ledger
• isPublished: Whether this response quote is approved for publication

Core Functions

recordEvidence

Records an evidence entry for a quote (typically the response quote), linking its hash to the hash of the full encrypted email exchange and its IPFS location. To support chaining, the off-chain system calling this function must handle the recording of the preceding quote and ensure the appropriate backward link is included in the C2PA manifest.

function recordEvidence(
    bytes32 responseQuoteHash,
    bytes32 fullExchangeHash,
    string memory storagePointer
) public

• responseQuoteHash: SHA-256 hash of the specific plaintext response quote
• fullExchangeHash: SHA-256 hash of the complete encrypted email exchange file
• storagePointer: IPFS CID pointing to the encrypted exchange file

setPublishedStatus

Allows the owner (source/interviewee) to control whether a specific response quote is approved for publication.

function setPublishedStatus(bytes32 responseQuoteHash, bool publishedStatus) public

• responseQuoteHash: Hash of the specific response quote text
• publishedStatus: New publication status (true/false)

getEvidence

Retrieves the complete evidence record for a specific response quote hash.

function getEvidence(bytes32 responseQuoteHash) public view returns (
    bytes32 fullExchangeHash,
    string memory storagePointer,
    address owner,
    uint256 timestamp,
    bool isPublished
)

isSnippetPublished

Checks if a specific response quote is approved for publication.

function isQuotePublished(bytes32 responseQuoteHash) public view returns (bool)

Event Emissions

EvidenceRecorded

Emitted when a new evidence record is created.

event EvidenceRecorded(bytes32 indexed responseQuoteHash, bytes32 fullExchangeHash, string storagePointer, address owner)

SnippetPublicationStatusChanged

Emitted when the publication status of a response quote is changed.

event QuotePublicationStatusChanged(bytes32 indexed responseQuoteHash, bool isPublished)

Usage Flow

1. Record Each Turn (Conceptual Flow):

   • Turn 1 (Initiator): Journalist sends initiator quote. System processes it, records it on the ledger (obtaining TxID_Initiator1), and generates its C2PA manifest.
   • Turn 2 (Response): Source sends response quote. System processes the exchange, records the response quote using recordEvidence (obtaining TxID_Response1), and generates its C2PA manifest. Crucially, this C2PA manifest must include a verifiable link back to TxID_Initiator1. The recordEvidence call anchors the response to the full exchange context (fullExchangeHash, storagePointer).
   • Turn 3 (Initiator): Journalist sends another initiator quote. System records it (obtaining TxID_Initiator2) and generates its C2PA manifest, which must link back to TxID_Response1.
   • …and so on for the entire conversation.

2. Authorization Control: The source/interviewee (owner) uses setPublishedStatus to control publication authorization for their specific response quotes recorded via this contract.

3. Verification: Publishers/readers use the C2PA manifest of any quote. The manifest allows verification of the quote itself against its ledger entry (TxID_Current) and enables tracing the conversation backward by following the embedded link to the previous quote’s ledger entry (TxID_Previous). The getEvidence function can retrieve the full context hash and IPFS pointer associated with a specific recorded quote hash.

4. Publication Check: Media outlets use isQuotePublished for specific response quotes recorded via this contract.

5. Authorization Control: The source/interviewee (owner) can call setPublishedStatus to control whether their specific response quote is authorized for publication.

6. Verification: Publishers and readers can call getEvidence using the hash of a response quote to retrieve the evidence record, including the hash of the full exchange, which can be used (with appropriate access) to verify its authenticity and context.

7. Publication Check: Media outlets can call isQuotePublished to verify whether a specific response quote is authorized for publication by the source.

GDPR Compliance

This smart contract design supports GDPR compliance by:

• Storing only cryptographic hashes and metadata on-chain, not personal data
• Keeping the full exchange content encrypted and off-chain on IPFS
• Allowing content owners to control publication status
• Providing a verifiable chain of custody for the conversation (via C2PA manifests linking preceding ledger entries) without exposing sensitive content directly on-chain.

1.2.2 - Pricing Model: Estimated Cost Impact Assessment

Estimated Cost Impact Assessment

This document provides a hypothetical assessment of the potential financial impact on newspaper production if all quoted material were sourced through a system using the Youseddit Smart Contract Pricing Model.

Disclaimer: This is a high-level estimate based on numerous assumptions and simplified parameters derived from the conceptual model. Actual costs would vary significantly based on real-world usage patterns and finalized model parameters.

Assessment Steps

1. Estimate Quote Usage: Assumed average number of quotes per newspaper edition.
2. Estimate Quote Characteristics: Distributed quotes across Time, Category, and Relevance factors based on simplified assumptions.
3. Define Model Parameters: Used example parameters from the pricing model documentation, notably a Base Price of $3.
4. Calculate Average Quote Cost: Determined the price for different quote types using the formula (Price = BasePrice × F_time × F_category × F_relevance) and calculated a weighted average.
5. Estimate Total Cost: Multiplied the estimated average quote cost by the estimated quote volume.

Key Assumptions (Simplified Examples)

• Volume: 50 quotes/day (Daily paper), 100 quotes/week (Weekly paper).
• Base Price: $3.00.
• Characteristics Distribution:
  • Time: Primarily fresh (70%), some recent (20%), few older (10%).
  • Category: Mostly standard impact (70%), some high impact (30%).
  • Relevance (Combined): Mostly medium (60%), some low (30%), few high (10%).
• Multipliers: Used example values (e.g., F_time from 5.0 down to 0.5, F_category 1.0 or 1.5, F_relevance 0.7 to 2.0).

Estimated Results

• Average Cost Per Quote: Roughly estimated to be in the $12 - $18 range, using $15 as a working average for this assessment.
• Total Estimated Cost Impact:
  • Daily Newspaper: ~50 quotes/day * $15/quote ≈ $750 per day (Approx. $274,000 annually).
  • Weekly Newspaper: ~100 quotes/week * $15/quote ≈ $1,500 per week (Approx. $78,000 annually).

Conclusion

Based on these simplified assumptions and the conceptual model (with a $3 base price), universally applying this pricing model to all quotes would introduce a significant new operational cost for traditional newspaper production.

The actual financial impact is highly sensitive to:

• The finalized Base Price.
• The specific multipliers and weights chosen for Time, Category, and Relevance factors.
• The real-world distribution of quote characteristics used by publications.
• Potential offsetting factors like new revenue streams or reduced costs elsewhere.

Further analysis with refined parameters and real-world data is necessary for a more accurate assessment.

1.2.3 - Pricing Model: Journalist Income Simulation (1 Year)

Journalist Income Simulation (1 Year)

This document presents a hypothetical simulation modeling the potential supplementary income for a single journalist over 12 months using the Youseddit Smart Contract Pricing Model. Unlike the static assessment, this simulation considers the cumulative effect of adding new quotes each month and the price decay impacting revenue from older quotes.

Disclaimer: This simulation uses simplified assumptions for quote characteristics, price decay, and licensing patterns. Actual income depends heavily on real-world factors.

Simulation Assumptions

• Base New Quotes Added: 20 per month.
• Base Initial Quote Price (Avg): $15.00 per license (Based on BasePrice=$3, F_time=5.0, F_cat=1.0, F_rel=1.0).
• Journalist’s Share: 90%.
• Base Initial Revenue per License: $15.00 * 90% = $13.50.
• Price Decay Function: F_time(t) = max(0.5, 5.0 * e^(-0.05 * t)), where t is days since quote creation. The price multiplier decays relative to the initial multiplier (5.0).
• Base Licensing Pattern (Avg per Quote):
  • Month 1 (Avg Age ~15 days): 3 licenses purchased.
  • Month 2 (Avg Age ~45 days): 2 licenses purchased.
  • Month 3 onwards: 0 licenses purchased (Total 5 licenses per quote).
• Base Revenue Calculation:
  • Month 1 Revenue/License ≈ $13.50 * (F_time(15) / F_time(0)) ≈ $13.50 * (2.36 / 5.0) ≈ $6.37
  • Month 2 Revenue/License ≈ $13.50 * (F_time(45) / F_time(0)) ≈ $13.50 * (0.53 / 5.0) ≈ $1.43
• Seasonality / Event Adjustments:
  • Summer Dip (July, Aug): 50% reduction in new quotes added AND 50% reduction in licenses purchased.
  • Winter Holiday Dip (Dec): 30% reduction in new quotes added AND 30% reduction in licenses purchased.
  • Event Spikes (Mar, Apr, Oct, Nov): Base quote production, but 25% increase in licenses purchased.
• Assumed Base Monthly Salary: $5,417 (approx. $65k/year, for visualization).¹

Monthly Income Simulation

Conclusion

Under these revised simulation assumptions (including seasonality and event spikes):

• The journalist’s supplementary income fluctuates significantly, peaking during event spikes (~$550/month) and dropping during seasonal dips (~$110-125/month).
• The total estimated supplementary income over 12 months is approximately $4,800.

This dynamic simulation yields a lower annual income than the static “Medium Pickup” estimate ($16,200) because it accounts for price decay. The inclusion of seasonality further reduces the total compared to the non-seasonal simulation (~$5,200) due to the significant impact of the summer dip.

This highlights the sensitivity of income potential to:

• Timing of Licenses: How quickly quotes are licensed after publication significantly impacts revenue due to price decay.
• Decay Rate: A slower decay rate would increase income.
• Licensing Volume: More licenses per quote directly increase income.
• Initial Quote Value: Higher initial multipliers (from relevance, category) increase income.

1.2.4 - Smart Contract Pricing Model

Smart Contract Pricing Model

Guiding Principles

Youseddit’s pricing for verified quote pairs (linked initiator and response quotes) must be clear and simple for journalists and writers. While the exact formula remains internal, the principles guiding it should be easy to grasp. This document outlines those principles.

We base pricing on three factors:

1. Time: How recent is the response quote (and the exchange it belongs to)?
2. Category: What is the topic?
3. Relevance: How prominent is the source providing the response quote? What is the quality of the response? How scarce is this type of information?

See a mock newspaper example demonstrating how verified response quotes (linked to their initiator context) might appear in a publication.

Philosophy: Empowering Journalists

While the underlying mechanics involve several factors, the goal for the journalist is simple: focus on securing and verifying impactful quote exchanges. The YouSeddit pricing model is designed to just work behind the scenes, automatically assessing the multifaceted value of your verified quote pair based on its timeliness, topic, and relevance.

We handle the complexity so you don’t have to. The system aims to intelligently capture the market value derived from your journalistic instincts – whether that’s breaking news, securing a response from a key figure, uncovering a unique perspective, or providing deep insight within a verified exchange. The result should feel intuitive: valuable journalistic work in securing and verifying quote pairs translates directly into fair compensation through the smart contract, empowering you to pursue the next story.

1. Time

New information costs more, reflecting the economic principle of the diminishing marginal utility of information over time. Like news, quote pairs lose value as they age. Prices for the pair will decrease from a set maximum for fresh exchanges to a minimum for older ones.

Next Step: Define a clear formula for this price decay over time for the quote pair, including maximum and minimum values.

2. Category

Quote pairs are categorized by the topic of the exchange. Topics with broad impact or high current interest (e.g., global economics, AI breakthroughs) result in a higher price for the pair than niche or local topics, reflecting media theories like Agenda-Setting.

Next Step: Create a defined list of categories and their corresponding price tiers or multipliers for quote pairs.

3. Relevance (Influence / Lippmann)

The price reflects the source’s (the individual providing the response quote) potential influence on public perception, or what Walter Lippmann termed the “pseudo-environment”. Quote pairs featuring responses from figures who significantly shape this pseudo-environment within a given category command higher prices than those from less influential individuals.

Next Step: Develop a system to rank sources’ influence within categories to set price tiers for the quote pairs they are part of.

3b. Relevance (Dialogue Quality / UDQA)

A different approach assesses relevance based on the intrinsic quality of the response quote itself using a structured rubric like the Universal Dialogue Quality Assessment (UDQA) framework. This focuses on measurable aspects like responsiveness, clarity, helpfulness, accuracy, and safety within the context of the initiator-response exchange.

• Focus on Content: This view prioritizes the substance and construction of the response quote, independent of the source’s fame.
• Quantifiable Rubric: UDQA provides specific dimensions (Responsiveness, Clarity, Helpfulness, Accuracy, Safety) that can potentially be assessed, even automatically, to generate a quality score.

This perspective suggests pricing for the quote pair could reflect not just who the source is, but how well their response quote communicates and contributes value based on the UDQA criteria within the exchange.

Next Step: Develop and evaluate methods (potentially NLP-based) for reliably scoring response quotes against the UDQA dimensions within their exchange context.

Alternative Perspective: Inverse Relevance Pricing

An alternative viewpoint argues that source relevance should exert inverse pressure on the price of the quote pair. The strongest form suggests that exchanges involving less prominent individuals might hold unique value and should therefore be more accessible (i.e., lower priced).

• Discovery Value (Weak Ties): Less prominent sources often offer novel perspectives in their responses. Lowering the cost barrier for these quote pairs encourages journalists to uncover potentially groundbreaking insights from less central sources.
• Supply, Demand, and Saturation: Highly influential figures generate a vast volume of public statements. Consequently, the marginal value and demand for one additional verified quote pair involving such a figure may be lower compared to a rare, unique exchange with a less-covered source. Pricing could reflect this dynamic.
• Amplifying Diverse Voices: Pricing that favors less “relevant” sources could actively promote journalistic diversity, giving platform to underrepresented viewpoints and challenging dominant narratives shaped by the usual influential figures.
• Incentivizing Deeper Reporting: Making quote pairs involving less-known experts or individuals cheaper could incentivize journalists to move beyond readily available soundbites and pursue more in-depth, original exchanges.

This perspective suggests that while source influence is a factor, a pricing model for quote pairs could strategically reduce the cost associated with lower-ranked source relevance to foster a richer information ecosystem.

Next Step: Evaluate the strategic implications of both direct and inverse source relevance pricing models for quote pairs on the YouSeddit platform.

Synthesized Pricing Formula (Conceptual)

While defining precise metrics for qualitative aspects like “dialogic quality” is complex, we can structure a conceptual formula to integrate the discussed factors, similar in approach to Multi-Attribute Utility Theory (MAUT) used in decision analysis. This formula serves as a framework for further definition:

$$ \text{Price} = \text{BasePrice} \times F_{\text{time}}(t) \times F_{\text{category}}(c) \times F_{\text{relevance}}(l, b, s) $$

Where:

• BasePrice: A constant minimum price for any verified quote pair.
• F_time(t): A time decay function. Value starts high for new quote pairs (t=0, based on exchange time) and decreases over time t, approaching a minimum multiplier > 0.
  • Example: Exponential decay: $$ F_{\text{time}}(t) = \max(\text{mult}{\text{min}}, \text{mult}{\text{init}} \times e^{-\lambda t}) $$ (where \lambda is the decay rate)
  • Requires Definition: initial_multiplier, min_multiplier, decay_rate.
• F_category(c): A multiplier based on the quote pair’s topic category c. Higher impact categories yield higher multipliers.
  • Requires Definition: A mapping of categories c to specific multiplier values (>= 1).
• F_relevance(l, b, s): A composite function combining different relevance aspects:
  • l: Lippmann Influence metric (source’s prominence/impact).
  • b: UDQA Quality metric (response quote’s intrinsic dialogue quality score within the exchange).
  • s: Supply/Scarcity metric (inverse of quote pair availability/source saturation).
  • Conceptual Structure: $$ F_{\text{relevance}}(l, b, s) \approx (1 + w_L \cdot \text{norm}(l) + w_B \cdot \text{norm}(b)) \times (1 + w_S \cdot \text{norm}(s)) $$
    • norm(): Normalization function to bring metrics l, b, s to a comparable scale (e.g., 0 to 1).
    • w_L, w_B, w_S: Weighting factors determining the relative impact of Lippmann influence, UDQA quality, and Supply/Scarcity. Note that s represents scarcity here (inverse of saturation), so higher s increases the price.
    • This structure allows weighting the source’s influence (l), the response quote’s quality (b), and the quote pair’s rarity/scarcity (s).
  • Requires Definition: Precise metrics for l, b, s; normalization methods; weighting factors w_L, w_B, w_S. Defining b objectively is particularly challenging.

Key Challenge: The primary challenge lies in developing objective, quantifiable metrics for l, b, and s, and agreeing on the appropriate weighting factors (w_L, w_B, w_S) to align with Youseddit’s strategic goals.

Example: Price Decay Over Time

Let’s illustrate the time decay function F_time(t) with hypothetical values:

• Base Price = $3
• Initial Time Multiplier (mult_init) = 5.0 (Quote pair is 5x base price when new)
• Minimum Time Multiplier (mult_min) = 0.5 (Quote pair price never drops below 50% of base * other factors)
• Decay Rate (\lambda) = 0.05 (per day)
• Category Multiplier (F_category) = 1.5 (e.g., for a high-impact topic)
• Relevance Multiplier (F_relevance) = 2.0 (e.g., for a quote pair with a high-influence source, high-quality response, and high scarcity)

Using the formula: $$ F_{\text{time}}(t) = \max(0.5, 5.0 \times e^{-0.05 t}) $$

And the overall price formula: $$ \text{Price}(t) = 3 \times F_{\text{time}}(t) \times 1.5 \times 2.0 = 9 \times F_{\text{time}}(t) $$

Here’s how the price might decay over the first 90 days:

Note: This is a simplified example. The actual decay rate, multipliers, and the point at which the minimum is reached would be determined by platform policy and market analysis. This table provides data points that could be used to generate a visual chart of the price decay curve.

Steelman Justification for the Formula

The strongest argument for adopting this multi-faceted formula rests on its potential to create a nuanced and balanced marketplace for verified information, moving beyond simplistic pricing models.

• Reflects Complex Value, Simply: It acknowledges that a quote pair’s value isn’t monolithic. The formula aims to capture this complexity automatically, providing a fair valuation for the linked initiator and response.
• Balances Market Reality with Quality: By incorporating both source influence (l) and response quality (b), the formula attempts to balance the market’s tendency to overvalue fame with a mechanism to reward substantive, insightful response quotes, regardless of the source’s prominence.
• Mitigates Information Saturation: The scarcity factor (s) addresses the diminishing marginal value of exchanges involving over-exposed figures or topics, preventing inflated prices for readily available information and potentially incentivizing the discovery of less common quote pairs.
• Adaptability through Weighting: The weighting factors (w_L, w_B, w_S) provide crucial flexibility. YouSeddit can strategically adjust these weights over time to fine-tune the market dynamics, perhaps initially emphasizing influence (w_L) but gradually increasing the weight of quality (w_B) or scarcity (w_S) as the platform matures and seeks to differentiate itself.
• Encourages Desired Outcomes: Depending on the weighting, the formula can be tuned to actively encourage specific journalistic behaviors, such as seeking out diverse sources (high w_S), rewarding high-quality responses (high w_B), or prioritizing timely exchanges (high initial F_time).

While acknowledging the significant challenge in objectively measuring b (response quality), this formula provides the most comprehensive framework discussed for capturing the multifaceted nature of quote pair value.

Projected Long-Term Influence

Implementing a pricing model this complex could have significant long-term effects as YouSeddit gains traction:

• Shaping Journalistic Incentives: If the weighting favors quality (w_B) and scarcity (w_S), journalists might be incentivized to seek out less prominent but more insightful sources, potentially diversifying media narratives. Conversely, a heavy emphasis on influence (w_L) could reinforce the focus on established figures.
• Influencing Public Discourse: By potentially making diverse or high-quality quote pairs more accessible or valuable, the model could subtly influence which sources and responses gain prominence in news produced using YouSeddit content.
• Creating a Market for “Quality”: If the b metric (response quote quality) can be implemented effectively, YouSeddit could pioneer a market that explicitly values the substance of the response within its verified context.
• Potential for Gaming/Manipulation: As the model becomes understood, actors might attempt to manipulate the metrics (e.g., artificially boosting perceived influence l, optimizing quotes for perceived quality b). Constant vigilance and refinement of the metrics would be necessary.
• Setting Industry Standards: A successful implementation could influence how other platforms or news organizations value and source information, potentially leading to broader adoption of more nuanced valuation methods.
• Complexity Barrier: The model’s complexity could also be a barrier to adoption or understanding for some users, requiring clear communication and potentially simplified interfaces.

Ultimately, the long-term influence will depend heavily on the specific implementation details, particularly the definition and weighting of the relevance components (l, b, s), and the platform’s ability to measure them accurately and resist manipulation.

User Control

How much control users (journalists, buyers) should have over these pricing factors within the smart contract system needs further discussion.

1.2.5 - Relevance Metric: Lippmann Influence (l)

Relevance Metric: Lippmann Influence (l)

This metric attempts to quantify the speaker’s potential influence on public perception, drawing inspiration from Walter Lippmann’s concept of the “pseudo-environment” described in Public Opinion. It focuses on the speaker’s prominence and reach within a specific category or topic.

Conceptual Definition

The l metric represents the degree to which a quote from this individual is likely to shape or reinforce the public’s understanding (the “pseudo-environment”) related to the topic. It aligns with communication theories of opinion leadership, where certain individuals disproportionately influence others’ attitudes or behaviors. Higher influence suggests the quote carries more weight in public discourse simply due to the speaker’s established position or network centrality.

Potential Measurement Factors (Requires Definition)

Quantifying l could involve a composite score based on factors like:

• Media Mentions: Frequency and prominence of the speaker’s coverage in relevant media outlets over a defined period.
• Social Media Reach & Centrality: Follower counts, engagement rates, and discussion volume related to the speaker on major platforms, potentially analyzed using social network analysis metrics (e.g., degree, eigenvector centrality) to gauge influence within online conversations.
• Institutional Role: Formal position or title held by the speaker within relevant organizations (e.g., CEO, Head of State, leading academic).
• Citation Frequency: How often the speaker is cited or referenced by others in the field or media.
• Search Engine Prominence: Volume and ranking of search results related to the speaker and the topic.

Role in Pricing Formula

In the Synthesized Pricing Formula, the normalized l value is weighted (w_L) to contribute positively to the overall price. A higher l generally increases the price, reflecting the perceived market value associated with quotes from highly influential figures.

Challenges

• Objectivity: Defining objective measures and avoiding bias in assessing influence.
• Dynamic Nature: Influence changes over time and requires periodic recalculation.
• Context Sensitivity: Influence can be highly context-dependent (e.g., influential in one field but not another).

Next Step: Develop specific, measurable proxies for influence and define the calculation methodology for the l score.

1.2.6 - Relevance Metric: Universal Dialogue Quality Assessment (UDQA)

Relevance Metric: Universal Dialogue Quality Assessment (UDQA)

This metric attempts to capture the intrinsic quality of a quote by assessing fundamental aspects of dialogue quality, applicable to any conversational text snippet, including quotes sourced for Youseddit. It replaces the previous Buber-inspired concept with a more structured, potentially automatable rubric.

Conceptual Definition

The UDQA metric provides a weighted score based on five key dimensions of dialogue quality present within the quote (or the immediate context it’s drawn from). A higher score indicates a quote that is more responsive, clear, helpful, accurate, and safe.

UDQA Formula

For any dialogue snippet $D$ (representing the quote and its immediate context), the quality can be computed as:

$$ \text{UDQA}(D) = \alpha R(D) + \beta C(D) + \gamma H(D) + \delta A(D) + \epsilon S(D) $$

Where:

• $\alpha, \beta, \gamma, \delta, \epsilon$ are weights that sum to 1 (e.g., default weights: 0.25, 0.25, 0.2, 0.15, 0.15).
• $R(D), C(D), H(D), A(D), S(D)$ are the scores for each component metric (normalized 0-1).

Component Metrics

1. Responsiveness $R(D)$:
   • Focus: Does the quote directly address the points or questions raised in the preceding context (e.g., the interviewer’s question)?
   • Formula: $$ R(D) = \frac{\text{Number of initiator points addressed in response}}{\text{Number of addressable points in initial query}} $$
2. Clarity $C(D)$:
   • Focus: Is the quote unambiguous and easy to understand?
   • Formula: $$ C(D) = 1 - \frac{\text{Ambiguous or vague statements}}{\text{Total statements in response}} $$
3. Helpfulness $H(D)$:
   • Focus: Does the quote provide information or perspective that progresses the goal of the conversation or adds value?
   • Formula: $$ H(D) = \frac{\text{Information or actions that progress conversation goal}}{\text{Total information or actions in response}} $$
4. Accuracy $A(D)$:
   • Focus: Does the quote contain identifiable factual errors or inconsistencies? (Requires external knowledge or comparison).
   • Formula: $$ A(D) = 1 - \frac{\text{Identifiable factual errors or inconsistencies}}{\text{Total factual claims made}} $$
5. Safety $S(D)$:
   • Focus: Does the quote avoid potentially harmful, biased, or inappropriate content?
   • Formula: $$ S(D) = 1 - \frac{\text{Potentially harmful, biased or inappropriate content}}{\text{Total response content}} $$

Practical Application & Role in Pricing

An automated system (potentially an LLM monitor) could analyze quotes against these dimensions.

In the Synthesized Pricing Formula, the normalized UDQA score (let’s still call the variable b for consistency with the formula) is weighted (w_B) to contribute positively to the overall price. A higher b (UDQA score) increases the price, reflecting a premium placed on quotes deemed to possess higher intrinsic quality based on this rubric.

Challenges

• Quantification: Defining precise, objective methods for counting “addressable points,” “ambiguous statements,” “helpful actions,” “factual claims,” and “harmful content” within a quote is challenging, especially for automated systems.
• Context Dependency: Assessing responsiveness and helpfulness requires understanding the surrounding dialogue context. Accuracy requires external fact-checking.
• Weighting: Determining the appropriate weights ($\alpha, \beta, \gamma, \delta, \epsilon$) is subjective and depends on platform priorities.
• Scalability: While potentially more automatable than purely philosophical assessments, robust NLP analysis for all dimensions can be computationally intensive.

Next Step: Develop and evaluate NLP models or clear guidelines for assessing each UDQA component score for quotes within the YouSeddit system.

1.2.7 - Relevance Metric: Supply/Scarcity (s)

Relevance Metric: Supply/Scarcity (s)

This metric applies fundamental microeconomic principles of supply and demand to the market for quotes. It acts as a counterweight or modifier to pure speaker influence (l), acknowledging that high availability (supply) can diminish the marginal value and equilibrium price, especially considering the unique characteristics of information goods where reproduction costs can be low (though verification adds cost).

Conceptual Definition

The s metric represents the scarcity of verified quotes from a particular source or about a specific niche topic within the YouSeddit platform and potentially the broader public domain. A higher s value indicates greater scarcity (lower supply/saturation), suggesting the quote is rarer and potentially more valuable from a supply-side perspective.

Potential Measurement Factors (Requires Definition)

Quantifying s could involve factors like:

• Volume of Existing Quotes (Speaker): The total number of verified quotes already available from the specific speaker within the YouSeddit system and potentially estimated from external sources. Higher volume leads to lower s.
• Volume of Existing Quotes (Topic): The total number of verified quotes available on the specific, narrow topic. High volume leads to lower s.
• Frequency of Speaker’s Public Statements: How often the speaker makes public statements or gives interviews. Frequent statements suggest lower scarcity (lower s).
• Exclusivity / Differentiation: Is the quote exclusive to the YouSeddit platform or widely disseminated? Higher exclusivity, a form of product differentiation or artificial scarcity, increases the s value.
• Time Since Last Quote: A longer time since the speaker was last quoted on the topic might increase perceived scarcity (s).

Role in Pricing Formula

In the Synthesized Pricing Formula, the normalized s value (representing scarcity) is weighted (w_S) to contribute positively to the overall price. A higher s (meaning greater scarcity/lower saturation) increases the price, reflecting the premium associated with rarer information. This directly incorporates the “Inverse Relevance Pricing” perspective by ensuring that readily available quotes (low s) are not overpriced solely due to speaker influence (l).

Challenges

• Defining Scope: Determining whether to measure scarcity only within YouSeddit or attempt to estimate broader public availability.
• Data Acquisition: Gathering reliable data on external quote availability is difficult.
• Topic Granularity: Defining topic boundaries for scarcity measurement can be ambiguous.

Next Step: Define the precise scope (internal vs. external) and develop methods for tracking quote volume per speaker and topic to calculate the s score.

1.2.8 - Simulation: Freelance Videographer (State Legislature)

Simulation: Freelance Videographer (State Legislature)

This simulation models potential income for a freelance videographer specializing in state legislative sessions, using YouSeddit to license short, verified video clips containing key quotes or moments from debates, hearings, or interviews. This scenario assumes income follows a typical legislative calendar, with peaks during the main session and lulls during recesses.

Disclaimer: This simulation uses highly simplified assumptions about clip value, licensing frequency, and seasonality. Actual income depends on the specific events covered, the impact of the clips, market demand, and finalized model parameters.

Simulation Assumptions

• Asset: Short, verified video clips (containing quotes/key moments) licensed via Youseddit.
• Base Initial Clip Price (Avg): $25.00 per license (Assumed higher value for video & political relevance; BasePrice=$5, F_time=5.0, F_cat=1.0, F_rel=1.0).
• Journalist’s Share: 90%.
• Base Initial Revenue per License: $25.00 * 90% = $22.50.
• Price Decay Function: F_time(t) = max(0.5, 5.0 * e^(-0.05 * t)) (Same decay as text quotes for simplicity).
• Base Licensing Pattern (Avg per Clip):
  • Month 1 (Avg Age ~15 days): 4 licenses purchased (Higher initial interest assumed).
  • Month 2 (Avg Age ~45 days): 2 licenses purchased.
  • Month 3 onwards: 0 licenses purchased (Total 6 licenses per clip).
• Base Revenue Calculation:
  • Month 1 Revenue/License ≈ $22.50 * (F_time(15) / F_time(0)) ≈ $22.50 * (2.36 / 5.0) ≈ $10.62
  • Month 2 Revenue/License ≈ $22.50 * (F_time(45) / F_time(0)) ≈ $22.50 * (0.53 / 5.0) ≈ $2.39
• Seasonality / Event Adjustments (State Legislature Cycle):
  • Session Peak (Jan-May): 150% production (30 clips/month) AND 150% licenses purchased (6 for new, 3 for previous).
  • Session Wind-Down (June): 100% production (20 clips/month) AND 100% licenses purchased (4 for new, 2 for previous).
  • Off-Session/Summer (Jul-Aug): 25% production (5 clips/month) AND 25% licenses purchased (1 for new, 0 for previous - simplified).
  • Interim/Pre-Session (Sep-Dec): 75% production (15 clips/month) AND 75% licenses purchased (3 for new, 1 for previous - simplified).
• Assumed Direct Project Income (Monthly): $5,000 (Jan-May), $3,500 (Jun), $1,000 (Jul-Aug), $2,500 (Sep-Dec). Illustrative, varies greatly.

Monthly Income Simulation (Freelance Video Journalist)

Conclusion

This simulation, incorporating seasonality for both direct project work and YouSeddit licensing based on a state legislative calendar, shows:

• Amplified Seasonality: Total monthly income shows extreme peaks during the legislative session (Jan-May, ~$7100/month) and deep troughs during the off-session (Jul-Aug, ~$1050/month).
• Significant Supplement during Peak: The YouSeddit supplement provides a substantial boost (~$2100/month) during the busiest legislative period.
• Modest Off-Season Contribution: YouSeddit income is minimal during the off-season but still provides some revenue when direct project work is scarce.
• Total Annual Potential: The total estimated supplementary income from YouSeddit over 12 months remains approximately $13,500, added on top of the assumed direct project income (~$40,500).

For a freelance videographer focused on state legislatures, YouSeddit offers a way to further capitalize on peak session activity and provides a small income floor during off-peak times. The overall income pattern remains highly seasonal.

{{/* Removed footnote [^1] as base salary assumption was removed */}}

2 - API Documentation

YouSeddit API

The YouSeddit API provides programmatic access to the platform’s core functionality, enabling developers to integrate authentication, content verification, and marketplace features into their applications.

Authentication

All API requests require authentication using an API key or OAuth 2.0 token. Tokens can be generated in the Youseddit Developer Portal.

Base URL

https://api.youseddit.com/v1

Content Endpoints

Verification API

The Verification API allows third-party services to verify the authenticity of quotes and content obtained through Youseddit.

GET /verify/{content_id}

Parameters:

• content_id (required): The unique identifier for the content

Response:

{
  "verified": true,
  "creator": "journalist@example.com",
  "source": "public_figure@example.com",
  "timestamp": "2025-03-15T14:22:31Z",
  "hash": "5ae0a0f542458d1379e0a603a5419e631dcdc1c45a1020a4d371400dd92bd9e3",
  "blockchain_tx": "0x7d931ff3a802d6c5b8c94e5421ccd1e392bde1c9ff7283173121a1c52348ec5e"
}

Smart Contract Access

POST /contracts/access

Request Body:

{
  "content_id": "quote-123456",
  "license_type": "non_exclusive",
  "duration_days": 30
}

Response:

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expires_at": "2025-05-07T00:00:00Z",
  "transaction_id": "tx-789012",
  "verification_url": "https://derstandard.youseddit.com/President_AT"
}

2.1 - Domain & Email Reference

YouSeddit Domain & Email Reference

This document provides a comprehensive reference of all the domains, subdomains, and email addresses required for the YouSeddit platform. Use this guide during system setup, development, and configuration to ensure consistency across the platform.

Domain Structure

The YouSeddit platform uses a hierarchical domain structure to organize its various services and features.

Main Domain

• youseddit.com - Primary domain for the platform

Subdomains

Core Services

Content & Publisher Subdomains

Each publisher or media outlet using YouSeddit for content verification receives a dedicated subdomain:

Community & Support

URL Paths

Main Website

API Endpoints

Email Addresses

System Accounts

User Support

Business & Partnerships

Developer Resources

Technical Identifiers

Email Configuration

SPF Record

v=spf1 include:_spf.youseddit.com include:_spf.mailfwd.youseddit.com -all

DKIM Configuration

Ensure DKIM is properly configured for all sending domains to maximize email deliverability.

DMARC Policy

v=DMARC1; p=reject; rua=mailto:dmarc-reports@youseddit.com; pct=100; adkim=s; aspf=s

Domain Registration & Management

• All domains should be registered with the same registrar for centralized management
• Use strong account security (2FA, unique passwords)
• Configure auto-renewal to prevent accidental expiration
• Implement DNSSEC for all domains
• Set extended expiration periods (5+ years) for critical domains

SSL Certificates

• Wildcard certificate for *.youseddit.com
• Individual certificates for high-security services

DNS Configuration Best Practices

• Use redundant DNS providers
• Implement DNS monitoring with alerts
• Maintain DNS documentation with all records
• Use short TTLs during migrations, longer TTLs (3600+) for stability

Related Documentation

• System Architecture
• API Documentation
• C2PA Extension Deployment

This reference should be updated whenever new domains or email addresses are added to the system.

3 - User Guide

YouSeddit User Guide

Welcome to the YouSeddit user guide. This section provides detailed instructions for journalists, content creators, and media organizations on how to use the YouSeddit platform.

Getting Started

Account Setup

1. Create a YouSeddit account at youseddit.com/signup
2. Complete email verification and two-factor authentication setup
3. Generate your PGP key pair or import an existing key
4. Connect a compatible crypto wallet

Email Configuration

To use Youseddit’s email verification system:

1. Configure your email client to use PGP/GPG for email signing
2. Add your verification email (verify@youseddit.com) to trusted recipients
3. Install the YouSeddit email plugin for your preferred email client

Using the Platform

Recording Conversation Turns

1. Conduct your email exchange using PGP/GPG signed emails.
2. Forward each relevant email (initiator or response) individually to verify@youseddit.com as the conversation progresses, or forward the entire thread when complete for batch processing (system must identify individual turns and their order).
3. The system verifies signatures, identifies each turn (initiator/response), records it on the ledger, and links it to the previous turn’s record.
4. Review the recorded conversation chain via the YouSeddit interface.

Licensing & Verification

Once turns are recorded on the ledger:

1. C2PA Attestation: Each recorded turn automatically receives a C2PA manifest containing verifiable links to its ledger entry and the previous turn’s entry.
2. Licensing: Select specific quotes (typically responses) within the chain that you wish to license. Set licensing terms (exclusive/non-exclusive, duration, pricing) via associated smart contracts.
3. Verification: Use the YouSeddit browser extension or verification tools to inspect the C2PA manifest of any quote, verify its authenticity against the ledger, and trace its context backward through the conversation chain.

Selling Quote Access

1. Share your quote marketplace listing with potential buyers
2. Approve access requests through the dashboard
3. Monitor usage and receive automated payments
4. Manage renewal and termination of licenses

3.1 - Journalist Feedback Survey

Journalist Feedback Survey

Thank you for your interest in providing feedback on the YouSeddit platform concept. Your insights as a working journalist are invaluable.

Please complete the survey embedded below. It should take approximately 10-15 minutes. Your responses will be kept confidential.

If you have trouble with the embedded form, you can also access it directly here.

3.2 - Creating Test Ledger Entries for PoC

Creating Test Ledger Entries for Proof-of-Concept

This guide explains how to create placeholder records on the Sepolia Ethereum testnet. These records simulate real blockchain entries for linking quotes in Proof-of-Concept (PoC) documents, like the Verifiable Quotes PoC page. This allows demonstrating the linking mechanism without deploying a full smart contract using a standard Ethereum testnet.

Prerequisites

• MetaMask: Install the MetaMask browser extension.
• Note on Multiple Wallets: If you have multiple browser wallet extensions installed (e.g., MetaMask and Coinbase Wallet), they might conflict. You may need to temporarily disable other wallet extensions via your browser’s extension settings for the desired wallet (MetaMask) to connect correctly to websites like Chainlist or faucet sites.

Steps

1. Set up MetaMask for Sepolia Testnet

You need to add the Sepolia test network to your MetaMask wallet. Sepolia is the recommended Ethereum testnet for application development.

• Go to Chainlist.org. Ensure “Include Testnets” is checked. Look specifically for the official Sepolia testnet which has ChainID 11155111. Be careful not to select other networks that contain “Sepolia” in their name (like zkSync Sepolia, etc.). Connect your wallet to add it automatically.
• Alternatively, add it manually in MetaMask settings:
  • Network Name: Sepolia Testnet
  • New RPC URL: https://rpc.sepolia.org (This is a reliable public endpoint. You can also find others via services like Infura, Alchemy, etc., which may offer higher rate limits if needed for extensive testing, often requiring free sign-up.)
  • Chain ID: 11155111 (This is the key identifier!)
  • Currency Symbol: SepoliaETH
  • Block Explorer URL: https://sepolia.etherscan.io/
• Ensure Sepolia Testnet is selected as your active network in MetaMask.

2. Get Testnet ETH (SepoliaETH)

Transactions require gas fees, even on testnets. You can get free SepoliaETH from a faucet. Note that some faucets may require you to hold a small amount of mainnet ETH in your wallet or sign up for an account.

• Copy your MetaMask wallet address.
• Visit a Sepolia faucet:
  • sepoliafaucet.com
  • faucet.quicknode.com/ethereum/sepolia
  • infura.io/faucet/sepolia
  • (Search for other “Sepolia ETH faucet”)
• Paste your address and follow the instructions to request test ETH. A small amount (e.g., 0.1 SepoliaETH) is sufficient for many test transactions.

3. Prepare Data for a Quote

For each quote you want to link in your PoC, gather its essential metadata.

• Example Data:
  • quote: “This is the first source document…” (The actual text)
  • cid: QmP5zJFaRTCmoQcjKgynj9Apu31nmXHQ23SXZXiB4FQwQY (IPFS CID of the source)
  • source: “Source Email 1” (Description of the source)
• Generate Quote Hash: Calculate a unique identifier for the quote text itself, preferably using SHA-256. You can use online tools or programming libraries for this.
  • Example SHA-256 Hash: 0xabc123...def
• Combine Data: Create a simple string containing the key information.
  • Example String: QuoteHash:0xabc123...def, CID:QmP5zJFaRTCmoQcjKgynj9Apu31nmXHQ23SXZXiB4FQwQY, Source:Source Email 1

4. Convert Data to Hexadecimal

Blockchain transaction data is often sent in hexadecimal format.

• Take the combined data string from Step 3.
• Use an online tool (e.g., search “text to hex converter”) or programming tools to convert the string to its hexadecimal representation.
• Ensure the output starts with 0x. If not, prepend it manually.
  • Example Hex Data: 0x51756f7465486173683a3078616263...

5. Send the Testnet Transaction

Now, embed the hex data into a transaction on the Sepolia testnet.

• Open MetaMask (ensure Sepolia Testnet network is selected).
• Click Send.
• Recipient: Enter your own MetaMask address or the zero address (0x0000000000000000000000000000000000000000).
• Amount: Enter 0 SepoliaETH.
• Hex Data / Input Data: Find the field for transaction data (you might need to enable advanced gas settings). Paste the hex-encoded data string (including 0x) from Step 4 into this field.
• Click Next, review the gas fee (it should be very small), and Confirm the transaction.

6. Get the Transaction Hash (TxID)

Once the transaction is confirmed, you need its unique identifier.

• Go to the Activity tab in MetaMask.
• Click on the confirmed transaction you just sent.
• Click View on block explorer (or similar link).
• This opens the transaction details on sepolia.etherscan.io.
• Copy the Transaction Hash (e.g., 0x1234abcd...). This is the tx value you’ll use in your PoC document.

7. Repeat for Other Quotes

Repeat Steps 3 through 6 for every quote you need to create a placeholder record for in your PoC. Each quote should have its own unique transaction hash.

8. Update Your PoC Document

• Open the Markdown file containing your PoC quotes (e.g., content/blog/verifiable-quotes-poc.md).
• Find the shortcodes or links representing your quotes.
• Replace the placeholder tx values or link destinations with the actual Transaction Hashes you obtained from Sepolia Etherscan in Step 6.

Now your PoC document will link to real transactions on the Sepolia testnet, effectively simulating links to on-chain verification records.