diff --git a/SPECIFICATION-v1.md b/SPECIFICATION-v1.md new file mode 100644 index 0000000..affcc8b --- /dev/null +++ b/SPECIFICATION-v1.md @@ -0,0 +1,943 @@ +# TIC Protocol Version 1 + +**Status:** Draft for community review +**Protocol identifier:** `tic` +**Protocol version:** `0x1` +**Last updated:** 2026-08-20 + +## Abstract + +TIC (Transaction Inscribed Comments) is an Ethscriptions child protocol for +attaching comments and reactions to Ethereum addresses, transactions, +Ethscriptions, and other hexadecimal identifiers. + +TIC version 0 stores both routing metadata and comment content in a JSON body +using the media type `message/vnd.tic+json`. That representation is suitable +for text, but it prevents an image, audio file, video, or other media payload +from being the directly renderable body of the Ethscription. + +TIC version 1 introduces a media-backed envelope. The Ethscription body is the +actual comment or reaction content, while TIC routing metadata is carried in +data URL parameters: + +```text +data:;rule=esip6;p=tic;op=;d=;base64, +``` + +This document defines the envelope, metadata encoding, operations, topic +syntax, validation, indexing, lifecycle, security, and compatibility rules for +TIC version 1. + +TIC v1 is additive. Existing TIC v0 records remain valid and implementations +are expected to read both versions permanently. + +## Status of This Document + +This document is a draft intended to produce interoperable implementations and +collect community feedback. Normative language describes the current proposed +behavior, but the proposal may change before TIC v1 is declared stable. + +The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, +**SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and +**OPTIONAL** in this document are to be interpreted as described by +[BCP 14](https://www.rfc-editor.org/info/bcp14) when, and only when, they appear +in all capitals. + +## Goals + +TIC v1 is designed to: + +1. Make the Ethscription body directly renderable as image, audio, video, text, + or another media type. +2. Permit indexers to discover TIC records and route operations without first + decoding arbitrary JSON. +3. Preserve the existing TIC topic model and reaction semantics. +4. Define deterministic validation behavior across independent + implementations. +5. Permit a safe, permanent dual-read migration from TIC v0. +6. Align with the `p` / `op` / `d` envelope already used by Ethscriptions + collection operations. + +## Non-goals + +TIC v1 does not define: + +- private or encrypted metadata; +- mutable or editable on-chain content; +- application moderation policy; +- a universal interpretation for every topic; +- composition of multiple protocols in one envelope; +- ESIP-7 gzip payloads; +- ESIP-8 attachment-backed comments; +- browser security policy beyond minimum implementation requirements; or +- an IANA registration of `p`, `op`, or `d` for every underlying media type. + +## Terminology + +### Ethscription + +An object created and tracked according to the Ethscriptions protocol. + +### Ethscription ID + +The transaction hash of the transaction that created the Ethscription. An +Ethscription ID is a 32-byte value conventionally represented as a lowercase +`0x`-prefixed hexadecimal string. + +### Content URI + +The complete UTF-8 data URL used to create the Ethscription, including its +media type, parameters, encoding marker, comma, and encoded payload. + +### Media type essence + +The media type without parameters, for example `image/png` or `text/plain`. + +### Payload + +The decoded bytes after the comma in the data URL. In TIC v1, these bytes are +the actual comment or reaction content. + +### Envelope + +The data URL header and the TIC parameters `p`, `op`, and `d`. + +### Metadata + +The UTF-8 JSON object encoded in the `d` parameter. + +### Creator + +The immutable Ethscriptions creator associated with the creation event. TIC +uses the creator as the author of a comment or reaction. + +### Current owner + +The address that currently owns the Ethscription according to the +Ethscriptions protocol. The creator and current owner can be different. + +### Tombstone + +The application-level state assigned to a TIC record whose Ethscription has +been transferred to the zero address. + +## Normative Dependencies + +TIC v1 depends on the following specifications: + +- [Ethscriptions Protocol Specification](https://docs.ethscriptions.com/overview/protocol-specification) +- [ESIP-6: Opt-in Ethscription Non-uniqueness](https://docs.ethscriptions.com/esips/accepted-esips/esip-6-opt-in-ethscription-non-uniqueness) +- [RFC 2397: The `data` URL scheme](https://www.rfc-editor.org/rfc/rfc2397.html) +- [RFC 4648: Base-N Data Encodings](https://www.rfc-editor.org/rfc/rfc4648.html) +- [RFC 8259: JSON](https://www.rfc-editor.org/rfc/rfc8259.html) +- [RFC 6838: Media Type Specifications and Registration Procedures](https://www.rfc-editor.org/rfc/rfc6838.html) + +When Ethscriptions data URL validity differs from a general-purpose URL or +MIME parser, Ethscriptions validity determines whether an Ethscription exists. +TIC v1 then applies the additional validation rules in this document. + +An object can therefore be a valid Ethscription while not being a valid TIC v1 +record. + +## Compatibility With TIC v0 + +TIC v0 uses a JSON body with this media type and parameter: + +```text +data:message/vnd.tic+json;rule=esip6, +``` + +Its JSON body contains `topic`, `content`, `version: "0x0"`, and optional +`encoding` and `type` fields. + +TIC v1 does not alter, replace, or invalidate TIC v0. Implementations: + +- **MUST** continue to recognize valid TIC v0 records; +- **MUST NOT** rewrite an existing v0 record as v1; +- **MUST** permit v0 and v1 records in the same topic and reply tree; and +- **SHOULD** expose the protocol version in APIs and storage. + +Historical implementations may choose to read pre-ESIP-6 legacy TIC records. +Such compatibility behavior is outside TIC v1 and does not make those records +valid TIC v1 records. + +## TIC v1 Envelope + +### General form + +The general TIC v1 form is: + +```text +data:[;...];rule=esip6;p=tic;op=;d=;base64, +``` + +A canonical writer emits TIC parameters in this order: + +1. `rule=esip6` +2. `p=tic` +3. `op=` +4. `d=` +5. `base64` encoding marker + +Media-specific parameters, such as `charset=utf-8`, appear after the media +type and before `rule=esip6`. + +Example: + +```text +data:text/plain;charset=utf-8;rule=esip6;p=tic;op=comment;d=;base64, +``` + +### Parameter ordering + +Parameter ordering has no semantic meaning. Readers **MUST** accept valid TIC +parameters in any order before the `base64` marker. + +Writers **MUST** use the canonical order above to reduce needless variation. + +### Parameter names + +Parameter names are case-insensitive. A reader treats `P` and `p` as the same +parameter name when detecting duplicates. + +Canonical writers **MUST** emit lowercase parameter names. + +### Duplicate parameters + +A parameter name **MUST NOT** appear more than once, using case-insensitive +comparison. Any duplicate parameter makes the record invalid TIC v1. + +This rule applies to TIC parameters, `rule`, and media-specific parameters. + +### Unknown parameters + +A reader **MUST** ignore unknown, non-duplicated parameters for TIC semantic +processing. It **MUST NOT** remove them from the stored content URI. + +An unknown parameter does not make a record invalid unless it violates the +underlying Ethscriptions data URL rules. + +### Required parameters + +A TIC v1 record requires exactly one of each of the following: + +| Parameter | Required value | Meaning | +| --- | --- | --- | +| `rule` | `esip6` | Opts into Ethscription non-uniqueness | +| `p` | `tic` | Selects the TIC protocol | +| `op` | `comment` or `reaction` | Selects the TIC operation | +| `d` | Unpadded base64url | Encodes TIC metadata | + +Parameter values defined by TIC are case-sensitive. For example, `p=TIC` and +`op=Comment` are invalid. + +### Protocol parameter: `p` + +`p` identifies the child protocol. TIC v1 requires the exact value `tic`. + +An envelope can contain only one `p` parameter. TIC v1 does not define a way +for one envelope to claim multiple child protocols. + +### Operation parameter: `op` + +`op` identifies the operation before metadata is decoded. TIC v1 defines: + +- `comment` +- `reaction` + +An implementation that encounters `p=tic` with an unknown `op` value +**SHOULD** retain it as an unsupported TIC operation for diagnostics and +future reprocessing, but **MUST NOT** treat it as a valid comment or reaction. + +### Metadata parameter: `d` + +`d` contains `base64url(UTF-8(JSON))` using the URL- and filename-safe alphabet +from RFC 4648 section 5. + +The `d` value: + +- **MUST** use only `A-Z`, `a-z`, `0-9`, `-`, and `_`; +- **MUST NOT** contain `=` padding; +- **MUST NOT** contain whitespace or line breaks; +- **MUST NOT** be empty; +- **MUST** use zero canonical pad bits; +- **MUST** decode to no more than 4,096 bytes; and +- **MUST** round-trip exactly when decoded and re-encoded as unpadded + base64url. + +Standard base64 and base64url are distinct encodings. A reader **MUST NOT** +accept `+`, `/`, or `=` in `d` as a compatibility shortcut. + +### Payload encoding marker + +TIC v1 requires the exact lowercase marker `;base64` immediately before the +comma separating the header from the payload. + +`base64` is an encoding marker, not a `name=value` parameter. + +The TIC v1 core profile does not accept ESIP-7 `;gzip` in place of `;base64`. +A future specification may define a separately testable gzip profile. + +### Payload encoding + +The payload after the comma: + +- **MUST** be strict standard base64 as defined by RFC 4648 section 4; +- **MUST NOT** contain whitespace or line breaks; +- **MUST** use required `=` padding; +- **MUST** use zero canonical pad bits; +- **MUST** round-trip exactly when decoded and re-encoded; and +- **MUST** decode to at least one byte. + +The unpadded base64url rule applies only to `d`. The media payload uses +standard padded base64 because the data URL declares `;base64`. + +TIC v1 adds no payload-size limit beyond the underlying Ethscriptions rules. +Clients **MAY** impose documented resource limits when retrieving or rendering +content, but such limits do not change protocol validity. + +## Media Types and Content + +### Media type requirement + +A TIC v1 data URL **MUST** include a nonempty, syntactically valid media type +with a type and subtype, such as: + +- `image/png` +- `image/gif` +- `video/mp4` +- `audio/mpeg` +- `text/plain` +- `text/markdown` + +Canonical writers **MUST** lowercase the media type essence. + +TIC v1 does not maintain a protocol-level allowlist of media types. A valid TIC +record can use a media type that a particular client does not render. + +Protocol validity and client rendering support are separate concepts. + +### Text media + +A TIC v1 record using a `text/*` media type: + +- **MUST** include `charset=utf-8`; +- **MUST** encode the payload as valid UTF-8; and +- **MUST NOT** include a UTF-8 byte order mark. + +Readers **MUST** honor the declared charset when they render text. TIC clients +are only required to render UTF-8 text. + +### Payload semantics + +The decoded payload is the content of the TIC operation. TIC v1 therefore +removes the need for v0's `content` and `encoding` metadata fields. + +The outer media type describes how a client may interpret the content. + +The declared media type is untrusted input. It does not prove that the payload +actually has that format or that the payload is safe to render. + +### Active content + +Clients **MUST NOT** execute untrusted active content with the application's +origin or privileges. HTML, SVG, scripts, and other active formats **MUST** be +isolated using an appropriate sandbox or refused. + +Clients **MAY** maintain a rendering allowlist while continuing to index valid +but unsupported TIC records. + +## Metadata Object + +### Schema + +After base64url and UTF-8 decoding, `d` must contain this JSON object: + +```typescript +interface TICV1Metadata { + topic: string; + version: '0x1'; +} +``` + +Example: + +```json +{ + "topic": "0x1234", + "version": "0x1" +} +``` + +### JSON requirements + +The decoded metadata: + +- **MUST** be valid JSON according to RFC 8259; +- **MUST** be encoded as UTF-8; +- **MUST NOT** begin with a byte order mark; +- **MUST** have a JSON object as its top-level value; +- **MUST** contain unique member names in every object; +- **MUST NOT** contain lone UTF-16 surrogate values after JSON unescaping; +- **MUST NOT** exceed eight levels of JSON nesting, counting the top-level + object as level one; and +- **MUST** contain the required `topic` and `version` members exactly once. + +JSON member names are case-sensitive. `Topic` is not `topic`. + +### Version + +`version` **MUST** be the JSON string `"0x1"`. + +The version identifies the TIC semantic and metadata version. The envelope +decoding rules for `p`, `op`, and `d` are expected to remain stable so that an +indexer can discover and retain future versions. + +An implementation that encounters a different version **SHOULD** retain the +record as an unsupported TIC version for future reprocessing, but **MUST NOT** +interpret it using v1 semantics. + +### Unknown metadata members + +A reader **MUST** ignore unknown metadata members when processing TIC v1. This +permits compatible optional extensions. + +A writer **SHOULD** emit only fields defined by this specification or by a +published extension. New fields that change the meaning of existing required +fields require a new TIC version rather than an extension. + +Ignoring an unknown field does not mean trusting, displaying, or executing its +value. + +### Canonical metadata serialization + +A canonical TIC v1 writer without extensions **MUST** serialize metadata as +compact JSON with `topic` followed by `version` and no insignificant +whitespace: + +```json +{"topic":"0x1234","version":"0x1"} +``` + +Readers **MUST NOT** depend on JSON member order or whitespace. + +TIC v1 does not require the JSON Canonicalization Scheme. The full content URI +already determines Ethscription content identity. + +## Topics + +### Syntax + +A topic is one or more hexadecimal components separated by colons: + +```text +topic = component *(":" component) +component = "0x" 1*HEXDIG +``` + +Additional TIC v1 limits are: + +- the complete topic **MUST NOT** exceed 2,048 ASCII characters; +- a topic **MUST NOT** contain more than 64 components; +- every component **MUST** contain at least one hexadecimal digit; and +- whitespace is not permitted. + +The `0x` prefix **MUST** be lowercase. Hexadecimal digits may be uppercase or +lowercase when read. + +Odd-length hexadecimal components remain valid for compatibility with v0 and +compact integer forms such as `0x1`. + +### Canonical form and equality + +The canonical topic form lowercases all hexadecimal digits while preserving +component boundaries. + +Topic equality **MUST** be determined by comparing canonical forms. + +Writers **MUST** emit canonical lowercase topics. Indexers **SHOULD** retain +the original topic for diagnostics while also storing the canonical topic for +lookup. + +### Interpretation + +The TIC core protocol treats valid topics as opaque identifiers. Applications +may apply conventions, including: + +- a 20-byte component as an Ethereum address; +- a 32-byte component as a transaction hash or Ethscription ID; or +- `contract-address:token-id` as an NFT topic. + +These interpretations are not implied by syntax alone. In particular, a +32-byte topic cannot be classified as a reply without resolving it against +indexed Ethscriptions and TIC records. + +### Replies + +`reply` is not a TIC operation. + +A comment can be interpreted as a reply when: + +1. its operation is `comment`; +2. its canonical topic is a 32-byte Ethscription ID; and +3. resolving that ID finds the parent TIC record. + +The reply target is the parent's Ethscription ID, not its content SHA or media +payload hash. + +An unresolved 32-byte topic remains a valid topic and **MUST NOT** be rejected +merely because the referenced object is unknown to an indexer. + +## Operations + +### `comment` + +`op=comment` declares that the decoded media payload is a comment associated +with `topic`. + +The payload can be textual or non-textual. TIC itself does not distinguish a +top-level comment from a reply in the operation name. + +### `reaction` + +`op=reaction` declares that the decoded media payload represents a reaction to +`topic`. + +A reaction may be text, emoji, image, animation, audio, or another valid media +payload. Applications decide how supported reaction media is displayed and +aggregated. + +`op` replaces the optional v0 `type` field. A v1 metadata object **MUST NOT** +use a `type` field to override `op`. + +## Authorship, Ownership, and Tombstones + +### Authorship + +The Ethscription creator is the immutable author of a TIC record. + +Metadata does not override authorship. A field claiming a different author, +whether known or unknown to this specification, has no core TIC meaning. + +### Ownership + +The current owner controls the Ethscription as an Ethscriptions asset. +Ownership transfer does not change the TIC author, topic, operation, payload, +or creation time. + +### Tombstones + +A TIC record whose Ethscription is transferred to +`0x0000000000000000000000000000000000000000` is tombstoned. + +A tombstone: + +- is controlled by the current owner, who may differ from the creator; +- does not erase or mutate on-chain content; +- **SHOULD** hide the payload from default application views; +- **MUST NOT** remove the record from reply-tree structure; and +- **MUST NOT** tombstone other Ethscriptions with identical content. + +Applications **MUST NOT** describe a tombstone as cryptographic proof of the +original author's intent unless the creator was also the owner that performed +the transfer. + +## Identity and Hashing + +The Ethscriptions protocol defines the authoritative identity and content hash +of the record. + +For TIC v1: + +- the Ethscription ID is the creation transaction hash; +- the Ethscription content SHA covers the complete UTF-8 content URI; +- changing `topic`, `op`, parameter order, JSON whitespace, or any other byte + in the data URL changes the content SHA; +- two records that render identical payload bytes can have different content + SHAs; and +- ESIP-6 permits multiple Ethscriptions with the exact same content URI and + content SHA, while each still has a distinct Ethscription ID. + +Indexers **MAY** compute a separate hash of the decoded payload for media +deduplication. Such a hash is derived application data and is not the TIC +record's identity. + +## Detection and Validation Algorithm + +An indexer processing an Ethscription should use the following sequence: + +1. Confirm that the object is a valid Ethscription according to the + Ethscriptions protocol. +2. Preserve the complete original content URI. +3. Parse the data URL into media type essence, ordered raw parameters, encoding + marker, and payload. +4. Compare parameter names case-insensitively and reject duplicate names for + TIC v1 processing. +5. If a `p` parameter exists: + 1. If its value is not `tic`, the record is not TIC. + 2. If its value is `tic`, process the record only as a versioned TIC + envelope. Do not fall back to v0 if v1 processing fails. +6. If no `p` parameter exists, independently test the record against the TIC + v0 rules. +7. For a TIC v1 candidate, require `rule=esip6`, `op`, `d`, and `;base64`. +8. Decode and validate the media payload using strict standard base64. +9. Decode `d` using strict canonical unpadded base64url. +10. Enforce the decoded metadata byte limit before JSON parsing. +11. Decode UTF-8 strictly and parse JSON with duplicate-member detection. +12. Validate `version`, `topic`, and the recognized operation. +13. Store the raw URI, normalized routing values, normalized topic, version, + validity, and any structured validation error. + +### No fallback after explicit protocol selection + +If `p=tic` is present, a malformed or unsupported envelope **MUST NOT** be +reinterpreted as TIC v0. This avoids different implementations assigning +different meanings to the same record. + +### Recommended validation result categories + +Reference implementations should distinguish at least: + +- `valid` +- `not_tic` +- `unsupported_version` +- `unsupported_operation` +- `invalid_envelope` +- `missing_parameter` +- `duplicate_parameter` +- `invalid_metadata_base64url` +- `metadata_too_large` +- `invalid_metadata_utf8` +- `invalid_metadata_json` +- `duplicate_json_member` +- `invalid_topic` +- `invalid_payload_base64` +- `empty_payload` +- `unsupported_payload_encoding` + +Exact application error messages are not normative. + +## Canonical Writer Algorithm + +A canonical TIC v1 writer performs these steps: + +1. Validate and lowercase the media type essence. +2. For `text/*`, validate UTF-8 and add `charset=utf-8`. +3. Validate and canonicalize the topic. +4. Select exactly one supported operation. +5. Construct metadata with `topic` followed by `version: "0x1"`. +6. Serialize compact UTF-8 JSON without a BOM. +7. Encode the JSON as canonical unpadded base64url. +8. Encode the nonempty payload as strict canonical standard base64 with + required padding. +9. Serialize media-specific parameters, then + `rule=esip6;p=tic;op=;d=;base64`. +10. Append a comma and the encoded payload. +11. Validate the completed data URL with both an Ethscriptions validator and + the TIC v1 parser before submitting it. + +## Indexer Requirements + +### Discovery + +Indexers **SHOULD** extract child-protocol routing parameters during ingestion +rather than scanning `content_uri` during every read. + +At minimum, a general Ethscriptions indexing layer should expose indexed +equivalents of: + +```text +protocol_name +protocol_operation +``` + +For TIC, application storage should additionally retain: + +```text +tic_version +tic_topic_original +tic_topic_normalized +tic_validation_status +tic_validation_error +``` + +An index covering protocol, operation, and chain position is recommended: + +```text +(protocol_name, protocol_operation, block_number, transaction_index, id) +``` + +The complete original content URI **MUST** remain available. + +### Dual-read queries + +TIC activity queries must include both: + +1. valid v0 records discovered by their v0 media type; and +2. valid v1 records discovered through `p=tic` and their operation. + +A media-backed TIC record will normally have a media type such as `image/png`. +Filtering only for `message/vnd.tic+json` will therefore omit valid v1 records. + +### Backfill + +Existing indexers **SHOULD** perform a one-time historical backfill that parses +stored content URIs and populates protocol and operation fields. + +Regex or substring filtering of every content URI is acceptable as a bounded +migration technique but **NOT RECOMMENDED** as the permanent production read +path. + +### Unsupported and invalid records + +Indexers **SHOULD** retain enough information to reprocess unsupported versions +and operations after software upgrades. + +Invalid TIC candidates **MUST NOT** appear as valid comments or reactions, but +implementations **SHOULD** count validation failures by stable error category. + +## Rendering Requirements + +A TIC client: + +- **MUST** treat the original content URI and payload as untrusted; +- **MUST** distinguish protocol validity from rendering support; +- **MUST NOT** use exact equality against a parameterized media type when it + intends to compare only the media type essence; +- **SHOULD** render supported passive media from the original data URL or from + an equivalently decoded, isolated resource; +- **SHOULD** provide a safe fallback for unsupported media; +- **MUST** sandbox or refuse active content; and +- **MUST NOT** expose the hosting application's credentials or origin authority + to rendered TIC content. + +An implementation that reconstructs a payload-only URL for safe rendering +**MUST** retain the original content URI for identity, indexing, sharing, and +verification. + +## Security and Interoperability Considerations + +### Metadata is public + +TIC metadata is embedded, not hidden. It is publicly visible in transaction +calldata and the Ethscription content URI. + +No private information should be placed in `d` unless public disclosure is +intended. + +### Parser differentials + +Lenient base64, duplicate JSON members, invalid Unicode, duplicate parameters, +and case differences can cause independent implementations to interpret the +same bytes differently. + +The strict validation and round-trip requirements in this document are +intended to prevent those differentials. + +### Resource exhaustion + +Implementations must enforce the metadata byte and nesting limits before +performing expensive application processing. Implementations should also use +bounded media decoding and rendering. + +### MIME confusion + +A declared media type can be false. Clients should use safe decoding libraries, +apply resource limits, and isolate content even when the media type appears +passive. + +### Authenticity + +The envelope does not provide an additional signature. Authorship comes from +the Ethscriptions creator information derived from Ethereum transaction or +contract-event processing. + +Metadata fields cannot override that creator. + +### Compatibility claims + +RFC 2397 permits media-type parameters, and unknown parameters are commonly +ignored during media rendering. This does not guarantee compatibility with +every wallet, browser, database, exact-MIME dispatcher, or custom indexer. + +Implementations should publish a compatibility matrix covering the media types +and clients they support. + +### Parameter namespace + +`p`, `op`, and `d` are an Ethscriptions envelope convention with existing +ecosystem precedent. They are not claimed to be newly registered parameters of +every underlying IANA media type. + +The short names reduce calldata while providing protocol and operation +discovery. A broader Ethscriptions specification or registry for these +parameters is recommended. + +## Examples + +### Plain-text comment + +Metadata: + +```json +{"topic":"0x1234","version":"0x1"} +``` + +Unpadded base64url metadata: + +```text +eyJ0b3BpYyI6IjB4MTIzNCIsInZlcnNpb24iOiIweDEifQ +``` + +Payload text: + +```text +Hello, TIC! +``` + +Standard base64 payload: + +```text +SGVsbG8sIFRJQyE= +``` + +Complete data URL: + +```text +data:text/plain;charset=utf-8;rule=esip6;p=tic;op=comment;d=eyJ0b3BpYyI6IjB4MTIzNCIsInZlcnNpb24iOiIweDEifQ;base64,SGVsbG8sIFRJQyE= +``` + +### Text reaction to a 32-byte topic + +Metadata: + +```json +{"topic":"0x1111111111111111111111111111111111111111111111111111111111111111","version":"0x1"} +``` + +Complete data URL for a thumbs-up reaction: + +```text +data:text/plain;charset=utf-8;rule=esip6;p=tic;op=reaction;d=eyJ0b3BpYyI6IjB4MTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMSIsInZlcnNpb24iOiIweDEifQ;base64,8J+RjQ== +``` + +### Image comment template + +```text +data:image/png;rule=esip6;p=tic;op=comment;d=;base64, +``` + +Angle-bracket placeholders are explanatory only and are not valid encoded +values. + +## Invalid Examples + +| Example condition | Reason | +| --- | --- | +| Missing `rule=esip6` | ESIP-6 is mandatory for TIC | +| `p=TIC` | Protocol value is case-sensitive | +| `op=reply` | `reply` is not a v1 operation | +| Two `d` parameters | Duplicate parameters are invalid | +| `d=abc=` | Metadata padding is forbidden | +| `d` containing `+` or `/` | Standard base64 is not base64url | +| `version: "0x0"` inside v1 `d` | Unsupported version | +| Topic `0x123...` | Topic contains non-hexadecimal characters | +| Topic `0x` | Topic component has no digits | +| `;gzip,` payload | Core v1 requires `;base64,` | +| Empty payload after the comma | Content must contain at least one byte | +| Duplicate JSON `topic` members | Duplicate JSON names are invalid | +| Unknown `op` | Unsupported operation, not a comment | + +## Versioning and Extensions + +The protocol identifier remains `tic` across TIC versions. + +Future versions should retain `p=tic` and the base64url JSON meaning of `d` +where possible so indexers can discover and retain records before supporting +their semantics. + +Compatible v1 extensions may add optional metadata fields or operations through +public review. They must define: + +- field or operation name; +- exact value syntax; +- validation behavior; +- size impact; +- security considerations; +- behavior for implementations that do not support the extension; and +- conformance vectors. + +An extension must not redefine `topic`, `version`, `p`, `op`, `d`, or the media +payload semantics. Such changes require a new TIC version. + +## Conformance + +An implementation must pass a shared, language-neutral suite of valid and +invalid vectors before claiming TIC v1 conformance. + +The conformance suite should cover at least: + +- image, audio, video, and UTF-8 text payloads; +- comment and reaction operations; +- reordered parameters; +- parameter-name casing; +- unknown parameters and metadata fields; +- duplicate parameters and JSON members; +- strict standard base64 and base64url behavior; +- invalid UTF-8 and Unicode surrogate handling; +- metadata size and nesting limits; +- valid, invalid, and normalized topics; +- unsupported versions and operations; +- mixed v0/v1 reply trees; and +- tombstone behavior. + +At least two independent implementations should produce identical results for +every vector before TIC v1 is declared stable. + +## Deployment Sequence + +The recommended rollout is: + +1. Publish this draft and collect review. +2. Freeze the envelope, validation, topic, and lifecycle rules. +3. Publish the reference parser, writer, and conformance vectors. +4. Add indexed protocol and operation discovery. +5. Backfill existing indexed Ethscriptions. +6. Deploy permanent dual-read support for TIC v0 and v1. +7. Test browser, wallet, explorer, AppChain, and indexer compatibility. +8. Enable v1 writers behind a feature flag. +9. Publish compatibility results. +10. Declare v1 stable only after independent conformance. + +Writers should not be enabled before readers and indexers can discover and +process v1 records. + +## Review Questions + +The following provisional decisions deserve specific community review: + +1. Is 4,096 decoded metadata bytes an appropriate maximum? +2. Are a 2,048-character topic and 64 components sufficiently flexible? +3. Should odd-length hexadecimal topic components remain valid? +4. Should core protocol validity remain media-type agnostic, with rendering + allowlists left to clients? +5. Should `version` remain inside `d`, or should it also be discoverable as a + top-level parameter? +6. Is an owner-controlled zero-address tombstone the correct lifecycle model, + given that the current owner may differ from the creator? +7. Should a future profile support ESIP-7 gzip or ESIP-8 attachments? +8. Should the `p` / `op` / `d` envelope be formalized upstream as an + Ethscriptions-wide convention or ESIP? + +## References + +- [TIC v0 repository specification](README.md) +- [GitHub Issue #1: Hidden Metadata via `x-meta`](https://github.com/Ethereum-Phunks/tic-protocol/issues/1) +- [Ethscriptions Protocol Specification](https://docs.ethscriptions.com/overview/protocol-specification) +- [ESIP-6: Opt-in Ethscription Non-uniqueness](https://docs.ethscriptions.com/esips/accepted-esips/esip-6-opt-in-ethscription-non-uniqueness) +- [Ethscriptions Collections](https://docs.ethscriptions.com/ethscriptions-appchain/collections) +- [RFC 2397: The `data` URL Scheme](https://www.rfc-editor.org/rfc/rfc2397.html) +- [RFC 4648: Base-N Data Encodings](https://www.rfc-editor.org/rfc/rfc4648.html) +- [RFC 6648: Deprecating the `X-` Prefix](https://www.rfc-editor.org/rfc/rfc6648.html) +- [RFC 6838: Media Type Specifications and Registration Procedures](https://www.rfc-editor.org/rfc/rfc6838.html) +- [RFC 8259: JSON](https://www.rfc-editor.org/rfc/rfc8259.html)