Node API Monolith Server
Relevant source files
The following files were used as context for generating this wiki page:
The Node API Monolith Server is the central execution engine of the TAMV Atlas, acting as the primary bridge between the project's conceptual narrative and its technical realization. It provides a full-stack platform for managing knowledge, identity (DID/PID), cryptographic signatures, and repository federation. Built primarily using Node.js with native HTTP or Express, the server facilitates identity sovereignty and a persistent ledger system for the TAMV ecosystem.
Sources: README.md:1-12, README.md:55-60
1. Architectural Overview
The server operates as a monolithic core that is progressively evolving toward a federated microservices architecture. It integrates multiple domains including authentication, atlas content management, and ISNI identity services. The current implementation utilizes Node.js (native/ESM) and optionally integrates with Supabase for data persistence and real-time signaling via SSE or WebRTC.
Sources: README.md:14-25, src/pages/wiki/implementacion/ApiIsni.tsx:54-65
1.1 Core Components and Services
The system is structured around the AtlasKernelRuntime, which manages the execution of protocols and local repository fusion.
- Identity/PQC/PID Modules: Handles post-quantum cryptography and persistent identifiers (ORCID, Zenodo, ISNI).
- Repo Fusion Service: Orchestrates the discovery and import of external repositories using the GitHub API and Git subtrees.
- Isabella AI Orchestrator: Manages chat, vision, audio, and haptic feedback logic.
Sources: README.md:55-65, src/pages/wiki/metaverso-xr/RoadmapCivilizatorio.tsx:96-103
1.2 System Architecture Diagram
The following diagram illustrates the relationship between the React frontend, the Node API Server, and the various internal modules and external integrations.
The diagram shows the central role of the AtlasKernelRuntime in orchestrating internal services and external data providers.
Sources: README.md:55-65
2. API Design and Endpoints
The server exposes a multisensorial API (DM-X4™) that manages 11 active domains and 48 federated nodes. The endpoints are organized by functional domains such as Auth, Users, Feed, Identity, and the MSR (Master System Record) ledger.
Sources: src/pages/wiki/metaverso-xr/RoadmapCivilizatorio.tsx:114-130, README.md:31-41
2.1 Functional Endpoints
| Domain | Base Path | Core Functionalities |
|---|---|---|
| Auth | /api/v1/auth | Register, login, token refresh, password reset |
| Identity | /api/v1/identity | Verification, dignity score, organization info |
| MSR/BookPI | /api/v1/msr | Event logging, actor timeline, audit ledger |
| Governance | /api/v1/governance | Proposals, voting, power management |
| PIDs | /v1/pids | Status tracking for ORCID, Zenodo, and ISNI |
| Signature | /v1/signature | Cryptographic signing and verification |
Sources: src/pages/wiki/metaverso-xr/RoadmapCivilizatorio.tsx:121-130, README.md:31-41
2.2 Security and Validation Logic
The server implements a Zero-Trust security posture. Every critical operation is logged to the MSR/BookPI ledger via the logMSREvent function. Access is controlled through JWT and a hierarchical role system: ciudadano, dev, empresario, academia, gobierno, and admin.
Sources: src/pages/wiki/metaverso-xr/RoadmapCivilizatorio.tsx:154-158, src/pages/wiki/implementacion/ApiIsni.tsx:66-75
3. Data Flow and Synchronization
The TAMV Fusion Core acts as the primary orchestrator for health checks and content synchronization. It runs scheduled cycles to verify route availability and database integrity.
Sources: federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:1-20
3.1 Fusion Cycle Sequence
The sequence diagram below shows how a Fusion Cycle is executed and registered in the immutable ledger.
Sequence representing the three-phase fusion cycle: Health, Sync, and Registry.
Sources: federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:133-156
3.2 Data Models
Persistence is structured to handle high-fidelity identity data and audit events.
// Entity Profile Structure (Conceptual)
{
id: string,
type: "Person" | "Organization" | "Territory",
identifiers: ["ISNI", "ORCID", "DID"],
trustScore: number,
metadata: JSON-LD
}
Sources: src/pages/wiki/implementacion/ApiIsni.tsx:44-52
4. Operational Configuration
The server's behavior is heavily dictated by environment variables. If core persistence services like Supabase are missing, the API enters a degraded state, returning 503 Service Unavailable for routes requiring database access.
Sources: README.md:67-70
4.1 Critical Environment Variables
| Variable | Description |
|---|---|
VITE_TAMV_BACKEND_URL | Base URL for frontend-to-backend communication |
SUPABASE_URL | Endpoint for Supabase persistence |
TAMV_BASE_URL | Public entry point for health check validations |
TAMV_ORCID / TAMV_ISNI | Canonical identifiers for ecosystem verification |
Sources: README.md:120-128, federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:15-20
5. Implementation Status
As of February 2026, the Backend Core is reported at 90% operational readiness, with critical gaps remaining in payment integration and advanced WebSocket telemetry.
| Block | Completion | Status |
|---|---|---|
| Backend Core | 90% | Operative |
| MSR / BookPI | 80% | Auditado |
| Governance | 90% | CITEMESH live |
| DevOps | 55% | CI/CD pending |
Sources: src/pages/wiki/metaverso-xr/RoadmapCivilizatorio.tsx:162-171, README.md:100-110
The Node API Monolith Server serves as the foundational "Base de producto digital," providing the necessary infrastructure for identity sovereignty and federated repository management. Its current state is suitable for advanced pre-production and controlled staging environments, while further hardening in security and observability is required for global scale.
Sources: README.md:72-98