[ public api ]

Every video on streamTXC is identified by its IPFS CID — a cryptographic hash of the file's bytes. Same bytes → same CID. Different bytes → different CID. Always.

That makes the CID the only identifier that actually matters. Our database row, our gateway URL, our chain timestamp, and any third-party IPFS pinner anywhere in the world all reference the exact same content via the exact same string. If we ever go dark, you can re-pin any CID elsewhere and the link still resolves.

# A CID looks like this:
bafybeigsqgnxogzyi7fdyogldjvia3juqkxnjv...

# Anyone can fetch it from any IPFS gateway:
curl -L https://ipfs.io/ipfs/{cid} -o video.mp4
curl -L https://gateway.pinata.cloud/ipfs/{cid} -o video.mp4
curl -L https://streamtxc.com/api/stream/{cid}    -o video.mp4

Treat the CID as the canonical link to a video — pass it around, stamp it on chain, embed it, archive it. Our /v/{cid} page is just a friendly wrapper around it.

When a video is claimed, paid for, renewed, taken down, or DMCA'd, we broadcast a tiny TXC transaction whose OP_RETURN output carries an ≤80-byte tag describing the event. Every event is sent to a per-video deposit address, so a single mempool address page is the entire public lifecycle of that video — claim, payment, renewal, takedown, the whole thing.

Comments work the same way: the comment body is pinned to IPFS, then its CID is stamped against the video's wallet via OP_RETURN. The chain proves when something was said and by which wallet — IPFS proves what was said.

event tags broadcast in OP_RETURN

  C  claim          — first time a video lands on the network
  P  payment        — hosting payment received
  R  renewal        — hosting prepaid for another period
  T  takedown       — uploader took it down
  D  DMCA           — moderator pulled it
  M  metadata       — title/description/uploader update
  X  comment        — IPFS CID of a new comment body

Result: TXC proof is permanent — the timestamp does not expire even if our gateway goes away. Anyone can decode the OP_RETURN payloads against a video's deposit address and reconstruct its full history without trusting us.

streamTXC has no usernames or passwords. To prove you control a wallet, you sign a one-time challenge message with TXC Core's Sign Message tool (or any wallet that produces a base64 message signature for a legacy "T…" address). We verify it server-side against the TXC node — no transaction, no spend, no gas.

# Step 1 — request a challenge
curl -X POST https://streamtxc.com/_serverFn/requestWalletLogin \
  -H "content-type: application/json" \
  -d '{"data":{"wallet":"T9..."}}'

# → { "message": "streamTXC — Sign in...", "challengeToken": "eyJhbGc..." }

# Step 2 — sign `message` in TXC Core (File → Sign Message),
# then hand the signature + challengeToken back:

curl -X POST https://streamtxc.com/_serverFn/completeWalletLogin \
  -H "content-type: application/json" \
  -d '{"data":{
        "challengeToken": "eyJhbGc...",
        "signature":      "H4r...=="
      }}'

# → session token (5 min challenge TTL, then verified)

The challenge message explicitly says "signing this does NOT authorize any transaction or spend any TXC." That's true — message signing is a pure ECDSA proof of key ownership. The wallet itself never moves.

Programmatic verification of any TXC-signed message — not just ours — is also exposed as a one-shot endpoint, see §06.