Try the proposed behavior
The reference stays the same. Switch between fictional viewers with different access to its source.
aikyat://mail/thread/demoFriday's design review
Review the revised interaction notes before the next discussion.
Fictional local example. This demonstrates a draft interaction contract, not real authentication or a deployed permission check.
Reconstructed interface study for this exhibition. It illustrates the product idea, not a screenshot or a live system.
02 / CROSS-PRODUCT INTERACTION + TRUST
Reference-card protocol
A proposed shared contract for referencing Mail, Chat, and other Aikyat objects across product boundaries.
Draft protocol
The source specification is marked draft. This case presents the proposal and its intended behavior, not verified production deployment or conformance. The interactive study uses fictional local data and is not an authorization service.
When a reference crosses products, whose permissions should travel with it?
My part in it
I proposed a platform-level reference-card contract: a reference URI, a standard resolver payload, and a deep link back to the source object. The key decision was to resolve as the viewer. The source product decides what that person can see; the consuming product does not inherit the sender's access or learn every producer's permission model.
What stayed with me
The card is the visible part of a platform decision. A shared contract lets product teams integrate through one common shape, while keeping object meaning and access decisions with the source product.
The alternatives I rejected
Bespoke renderers would make each consumer track other products' data models. Producer-rendered UI would constrain consistent theming and accessibility. Sender-identity resolution would give the wrong identity authority over the card. The proposal separated data, rendering, and access decisions.
Snapshots, freshness, and the trust boundary
The draft proposed storing a snapshot with a reference and refreshing it when viewed, balancing responsiveness and offline use against stale information. Cache behavior, error states, and invalidation remained open design work. This exhibit demonstrates viewer-scoped resolution only; it does not claim that snapshot reuse is permission-safe in a deployed system.
A product contract, not a Chat-only feature
The design included common card data, source-product actions, versioning, and proposed conformance checks. The aim was for Mail, Chat, and future products to share the same reference mechanism while retaining their own product surfaces.