docs: propose TIC v1 specification

[chopperdaddy]

## Summary

This PR proposes TIC Protocol Version 1 as an additive media-backed format for comments and reactions.

TIC v0 stores routing metadata and content together in a `message/vnd.tic+json` body. TIC v1 allows the Ethscription body to be directly renderable media while moving TIC routing metadata into data URL parameters.

Proposed envelope:

```text
data:<media-type>;rule=esip6;p=tic;op=<comment|reaction>;d=<base64url-metadata>;base64,<payload>

Example decoded metadata:

{
  "topic": "0x1234",
  "version": "0x1"
}

Relates to #1.

Motivation

This enables images, video, audio, text, and other media to function as standalone Ethscriptions while remaining discoverable and threadable by TIC-aware indexers and clients.

The proposal incorporates feedback from Issue #1 and its discussion, including:

• Using p, op, and d instead of a generic x-meta field
• Keeping tic lowercase as the canonical protocol identifier
• Preserving mandatory rule=esip6
• Using strict, unpadded base64url for metadata
• Treating replies as comments whose topic resolves to a parent TIC Ethscription
• Defining parameter ordering, duplicates, invalid UTF-8, unknown fields, and resource limits
• Documenting the effect of metadata on Ethscription identity
• Requiring indexed protocol and operation discovery before enabling writers

What this specification defines

• The TIC v1 data URL envelope
• Comment and reaction operations
• Metadata encoding and JSON validation
• Topic syntax, normalization, equality, and reply resolution
• Media payload and MIME handling
• Authorship, ownership, and zero-address tombstones
• Identity and hashing consequences
• Canonical writer and validation algorithms
• Indexer discovery and dual-read requirements
• Rendering and security requirements
• Conformance expectations and deployment sequence
• Valid and invalid examples

Backwards compatibility

TIC v1 is additive.

• TIC v0 remains permanently valid.
• Existing records require no migration or rewriting.
• Implementations are expected to read v0 and v1 concurrently.
• Writers should not emit v1 until indexers and clients can discover and process it.

This PR does not enable v1 writers or change existing application behavior.

Important provisional decisions

The current draft proposes:

• version: "0x1" inside d
• A 4,096-byte decoded metadata limit
• A 2,048-character topic limit
• Up to 64 topic components
• Odd-length hexadecimal components remaining valid
• No protocol-level media-type allowlist
• Strict standard base64 for the media payload
• Strict unpadded base64url for d
• comment and reaction as the initial operations
• No distinct reply operation
• No ESIP-7 gzip or ESIP-8 attachment profile in core v1
• Owner-controlled zero-address tombstones

Review requested

The specification contains a dedicated Review Questions section. Feedback is especially requested on:

1. Metadata and topic limits
2. Topic syntax and normalization
3. Whether version should also be a top-level parameter
4. Media-type validity versus client rendering allowlists
5. Tombstone semantics when the creator and current owner differ
6. Future gzip and attachment support
7. Whether p / op / d should be formalized as an Ethscriptions-wide convention
8. Any parsing behavior that could produce inconsistent results across implementations

Follow-up work

After the specification reaches consensus:

• Build a reference TIC v1 parser and writer
• Publish language-neutral conformance vectors
• Add indexed protocol and operation fields
• Backfill existing Ethscriptions
• Add permanent v0/v1 dual-read support
• Test browser, wallet, explorer, and indexer compatibility
• Enable v1 writers behind a feature flag

Testing

The complete examples in the specification were programmatically decoded and checked for:

• Canonical unpadded base64url metadata
• Valid UTF-8 JSON
• Valid TIC v1 topic and version
• Canonical standard base64 payloads

git diff --check also passes.