Research

What is real, what is being explored, what is a direction.

Technical depth for builders. Every capability below is tagged with its current status. Implemented, prototyped, designed, research, and vision are not the same tense and are not the same promise.

Legend
Implemented

Evidence exists in code or tests in the corresponding source repository.

Prototyped

A partial implementation or working experiment exists.

Designed

Architecture or specification exists.

Research

Concept is being explored.

Vision

Long-term direction without implementation commitment.

01/Group

Nodes

Persistent infrastructure that holds state under user authority. The architectural concept below Codexify and any future interface.

  • Local Codexify runtime (Docker Compose)

    Implemented

    A Codexify Node runs as a local Docker Compose stack: chat, retrieval, document context, and bounded tooling under operator authority. Evidence in the Codexify source repo and developer-guide corpus.

  • Personal Node hardware profiles

    Designed

    Raspberry Pi, laptop, home server, old hardware. Architectural profile and capability expectations are documented; reference builds are early.

  • Cellphone-as-Node and Apple TV-as-Node

    Research

    Devices that can stay on, watching, waiting for something interesting to happen. Concept and proof-of-concept exploration, not shipped capability.

02/Group

Identity portability

The principle that the person remains portable between applications and services. Storage implementation is replaceable; the principle is not.

  • Portable project context in Codexify

    Implemented

    Conversations, documents, and retrieval state are exportable and restorable under explicit operator control. Documented in the Codexify runtime contract.

  • Identity continuity across Codexify surfaces

    Prototyped

    Threads and projects persist across sessions with continuity metadata. Working capability on the supported local runtime path.

  • Identity as portable substrate

    Designed

    The architecture that lets identity move between applications, services, and interfaces without surrendering authority. Specified; not generally available.

03/Group

Relationship boundaries

Explicit, user-controlled boundaries on what one Node, person, or service is allowed to know, share, request, or do with another.

  • Provider governance in Codexify

    Implemented

    Operator posture for runtime model selection, health surfaces, and per-provider configuration. Documented as part of the supported runtime contract.

  • Privacy / sharing / consent vocabulary

    Prototyped

    Working concepts in Codexify workspace for private, shared, public, delegated, and community contexts. Concrete; not complete.

  • Relationship-first data architecture

    Research

    Treating relationships as the primary boundary unit instead of objects-as-rows. Conceptual exploration.

04/Group

Transport independence

The architectural property that relationships and meaning survive changes in transport. Wi-Fi, cellular, Reticulum, Meshtastic, Bluetooth, LAN, cloud relays, and future transports are all candidates.

  • Transport-agnostic Codexify runtime

    Implemented

    Codexify's supported local runtime path does not depend on a particular network topology. Docker Compose local is the canonical supported path.

  • Reticulum and Meshtastic integration

    Research

    Promising transport candidates for off-grid and neighborhood-scale ThreadSpace. Exploration and limited experimentation; not shipped.

  • Schema broadcast over degraded connectivity

    Research

    Compact structured messages exchanged between nodes, with rendering at each end. Promising research direction; semantics must remain explicit, not model-dependent.

05/Group

Local inference

The default posture that authority stays with the user even when execution happens elsewhere. Local model serving is a building block.

  • Local provider posture in Codexify

    Implemented

    Codexify's supported local runtime is built around local provider governance. Local model serving is documented and supported on the canonical path.

  • Local-first model orchestration

    Research

    Architectural direction for graceful model sameness, fall-back, and degraded inference. Conceptual; not a shipped capability.

06/Group

Physical-place digital infrastructure

Digital spaces associated with actual physical places. The flagship scenario for what ThreadSpace enables.

  • Neighborhood local networks

    Research

    Hyperlocal infrastructure that remains useful when central services are down or unavailable. Hurricane-resilient operation is one concrete motivation. Concept and early architecture work.

  • Persistent digital experiences at a place

    Research

    Local nodes that host unique experiences associated with a location. Geocaching-style interaction patterns are an early example. Concept and design exploration.

  • Community-operated digital environments

    Vision

    Local digital environments that communities maintain themselves. A long-term direction without implementation commitment.

Note

Status reflects evidence available in the corresponding source repositories at time of writing. For the current implementation status of Codexify specifically, see the Codexify developer guide.