Project .taste

A zero-dependency TypeScript SDK for deterministic 16-byte social preview packets.

Comment

Inspiration

Social timelines usually receive their heaviest data first: text, media URLs, engagement metadata, and repeated fields all arrive before the client knows the shape of the next screen. Project .taste explores a different ordering. What if a client could receive a tiny, deterministic preview contract first, reserve the interface, and let full content arrive independently afterward?

What it does

Project .taste is a developer tool for progressive social timeline rendering. It projects rich post metadata into one fixed 16-byte (128-bit) packet, arranged as a 4x4 semantic matrix. The packet carries visual palette indexes, motion hints, layout geometry, interaction state, a reserved byte, and a protocol version.

The client decodes those same 16 bytes into a preview: it can reserve media slots and text geometry, apply a visual palette, and reflect social state before the full content path completes. The packet is not a replacement for real text or images. It is a stable preview contract that works alongside an existing REST, GraphQL, gRPC, or edge API while the full content loads asynchronously.

How we built it

The core is a published TypeScript SDK, xtaste-client-sdk. TasteEncoder performs the server or edge projection step; TasteDecoder performs the client-side expansion step. The package has zero runtime dependencies and stays synchronous, using Uint8Array and bitwise operations rather than a runtime framework.

The repository includes an executable end-to-end test that builds the real SDK, checks the 16-byte invariant, verifies the encode/decode round trip, and rejects an invalid packet length. It also includes a browser demo that hydrates ten preview cards from 160 bytes, plus a deterministic benchmark that compares a 100-post Twitter v2-shaped fixture with 100 packets.

How Codex and GPT-5.6 were used

Codex with GPT-5.6 helped inspect the existing prototype, remove speculative runtime layers, shape the SDK around a single fixed-size contract, and keep the core dependency-free. It also helped build the exported encoder and decoder, write the executable round-trip path, create the deterministic benchmark, prepare CI, and turn the browser demo into a clear judge path.

The most important decision was to verify the exported SDK rather than maintain a separate test-only implementation. That kept the demo, package, tests, and benchmark all pointed at the same behavior.

Challenges we ran into

The hard part was deciding what belongs in 16 bytes and what does not. The packet needs enough structure to render a useful preview without pretending to contain full-fidelity content. The four rows make that boundary explicit: visual ambiance, motion dynamics, layout skeleton, and state plus versioning.

We also avoided inventing a second transport protocol. Delivery, ordering, retransmission, and full-content fetching remain the responsibility of the application and its transport. Project .taste only defines the compact preview representation.

Accomplishments that we're proud of

The local benchmark reduces a deterministic 100-post fixture from 47.40 KB (48,542 bytes) to 1.56 KB (1,600 bytes), a 96.70% reduction before full content arrives. This is a reproducible fixture rather than a claim about every production timeline or network.

More importantly, the full judge path is public: the source is MIT-licensed on GitHub, the SDK is installable from npm, the browser demo is hosted on GitHub Pages, and the repository documents how to run the tests and benchmark locally.

What we learned

The smallest useful protocol is often more valuable than a flexible one. A fixed-size preview makes the client contract easy to test, version, and render. The work reinforced that performance-oriented developer tools need honest boundaries as much as attractive numbers.

What's next for Project .taste

Byte 14 is reserved and Byte 15 stores the protocol version, leaving a clear compatibility path. Next, we will explore a small edge or API sidecar that emits .taste packets beside existing responses, and validate the preview contract against more kinds of timeline content without changing the full-content data model.

Built With

Share this project:

Updates