FEEN Identifier (FID) Specification

Version: 1.0.0
Author: Cyril Kato
Published: July 11, 2025
License: Open Web Foundation Agreement 1.0

1. Status of this document

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as normative requirements.

2. Overview

A FEEN Identifier (FID) is a fixed-length cryptographic fingerprint derived from a canonical FEEN string.

While FEEN represents a Position, a FID identifies it: a compact, opaque value suitable for equality testing, hash-table keying, caching, and repetition detection without comparing full FEEN strings.

Two Positions share the same FID if and only if their canonical FEEN strings are identical.

2.1 Scope

FID defines:

the algorithm for computing a fingerprint from a FEEN string,
the output format of that fingerprint.

2.2 Non-goals

FID does not define:

any notion of Position similarity, distance, or equivalence beyond exact string identity,
storage or indexing strategies,
any game-specific semantics.

3. Dependencies

FID depends on:

FEEN v1.0.0 — the input MUST be a valid, canonical FEEN string.

4. Algorithm

4.1 Input

The input MUST be a valid FEEN string in canonical form (as defined by the FEEN specification).

Implementations MUST reject non-canonical or invalid FEEN strings before computing a FID.

4.2 Hash function

The FEEN string MUST be encoded as a sequence of UTF-8 bytes (which, for the ASCII-only FEEN format, is identical to the raw ASCII bytes) and hashed using SHA-256.

4.3 Output

The output is the lowercase hexadecimal encoding of the full 256-bit SHA-256 digest: a string of exactly 64 hexadecimal characters ([0-9a-f]{64}).

5. Formal definition

Given a canonical FEEN string F:

FID(F) = hex(SHA-256(F))

Where:

SHA-256 is the hash function defined in FIPS 180-4,
hex is the lowercase hexadecimal encoding of the resulting 256-bit digest.

6. Examples

See FID Examples for computed FID values across chess, shōgi, and xiangqi positions.

7. Properties

Deterministic: the same canonical FEEN string always produces the same FID.
Fixed-length: a FID is always exactly 64 hexadecimal characters (256 bits).
Collision-resistant: two distinct FEEN strings produce different FIDs with overwhelming probability.
One-way: a FEEN string cannot be recovered from its FID.
Canonical-dependent: because FEEN enforces canonical form, there is exactly one valid FEEN string per Position, and therefore exactly one FID per Position.

8. Conformance

Producers MUST validate and canonicalize the FEEN input before hashing.
Producers MUST use SHA-256 and output lowercase hexadecimal.
Consumers MUST treat FID comparison as case-sensitive string equality on the 64-character hex string.

9. Design rationale

9.1 Why SHA-256?

SHA-256 is widely available, well-studied, and provides sufficient collision resistance for Position identification. It is supported natively or via standard libraries in virtually all programming languages.

9.2 Why not a shorter hash?

Truncated hashes increase collision probability. For applications that require shorter identifiers (e.g., URL slugs), implementations MAY truncate a FID for display purposes, but MUST use the full 64-character FID for identity comparison.

9.3 Why require canonical FEEN?

Canonicalization guarantees that two semantically identical Positions produce the same FID. Without it, equivalent Positions with different serializations (e.g., different empty-count splitting) would produce different FIDs, breaking the identity property.

10. License

This specification is made available under the terms of the Open Web Foundation Agreement 1.0.

The authoritative legal text is the OWF “Final Specification Agreement (OWFa 1.0)”.