The Indigitus CasaNode project is moving from an inherited prototype toward a device that our team can securely maintain, update, and connect to the wider GFAVIP ecosystem.

Our goal is straightforward: create a useful home and community node that can provide private connectivity, report clear local status, and work with the existing GFAVIP touchscreen display. Longer term, we want the same platform to support community dashboards, event displays, optional rewards, and modular decentralized services without making those future features prerequisites for a safe first pilot.

Where the project started

The physical CasaNode sample was built on the existing open-source CasaNode software. When we resumed the project, the device could broadcast its setup network but the onboarding screen was blocked until the correct local connection flow was recovered. The inherited software also assumed a public network configuration that is not realistic for many households using carrier NAT or other restricted internet connections.

We decided to preserve the useful upstream work while taking responsibility for the parts required to operate and support our own devices.

What we have completed

The team has now:

  • recovered the physical unit’s local onboarding flow and confirmed repeatable boots and local administrative access;
  • established maintained Indigitus mirrors of the CasaNode OS and API source;
  • designed a bounded, read-only local status interface for a CasaNode and the GFAVIP ESP32 display;
  • completed host-side CasaNode and display candidates without flashing or deploying them prematurely;
  • designed an outbound-only device-management architecture so future units can be supported without opening inbound management ports;
  • built and tested a clean, reproducible CasaNode API package candidate that excludes retired build output and sensitive signing material; and
  • opened separate public code-review proposals for the package candidate and the Indigitus-owned validation workflow that will check it.

The public code reviews are available here:

What this does not mean yet

This is engineering progress, not a product-release announcement.

We have not yet:

  • published or installed a new CasaNode API package;
  • deployed an Indigitus system image;
  • installed a production remote-management agent;
  • flashed the CasaNode integration into the production GFAVIP display firmware;
  • completed a physical end-to-end CasaNode and ESP32 validation session;
  • enabled a public provider mode on networks where inbound reachability is not available; or
  • launched GFA Gems earning rules, KPI connectors, Handshake resolution, or fleet rollout.

Keeping these distinctions clear matters. Host-side tests can prove that code and protocols behave as designed, but they cannot replace physical validation on the actual CasaNode and display hardware.

Why we are taking a measured approach

A device installed in someone’s home must be supportable after it leaves our office. Updates must be authenticated, narrowly scoped, recoverable, and auditable. Local status must remain private. A network limitation must be reported honestly rather than hidden behind a misleading setup screen.

That is why we are separating the platform into clear modules:

  • the CasaNode operating system and local services;
  • a read-only local status companion;
  • an outbound-only management agent with no arbitrary remote shell;
  • the GFAVIP display and its existing cloud content channel; and
  • future optional applications such as community KPIs, event kiosks, rewards, and decentralized resolvers.

This modular structure lets us improve one layer without weakening the others.

What comes next

Our immediate sequence is:

  1. complete review of the Indigitus validation workflow;
  2. run that validation against the exact CasaNode API package proposal;
  3. integrate the reviewed source and reproduce the package from the resulting final source identity;
  4. perform controlled runtime and rollback checks before installing anything on the physical CasaNode; and
  5. begin a separately supervised CasaNode and GFAVIP display hardware pilot.

The first pilot remains intentionally small: one reliably bootable CasaNode, one securely supportable management path, and one display showing basic local node status. Once those observable checks pass, we can expand toward community dashboards and larger kiosk displays for live events.

Thank you

We know the community has been waiting for a clear update. The project is making real progress, and we are choosing verifiable milestones over premature release claims. We will share the next update when the validation workflow and package review have completed and the physical pilot is ready to begin.