Supabase & Database Migrations
Relevant source files
The following files were used as context for generating this wiki page:
Supabase serves as the primary persistence, authentication, and logic execution layer for the TAMV Atlas ecosystem. It integrates a PostgreSQL database with Edge Functions to handle complex operations like repository fusion, identity verification, and MSR (Mutable System Record) event logging. The system is designed to be "optionally persistent," meaning the API remains functional for basic tasks even if the Supabase connection is unavailable, albeit with restricted routes.
The database architecture is defined through a series of migrations that establish schemas for identity profiles, wiki content, and governance. These migrations ensure consistency across federated environments, supporting the project's goal of a "soberanía tecnológica" (technological sovereignty) framework.
Sources: README.md:12-25, federation/tamv-digital-nexus/supabase/functions/tamv-unified-api/index.ts:1-25
1. Database Schema and Entities
The core data model is structured around several critical tables that manage the lifecycle of the TAMV Atlas, from user identities to content versioning.
Core Tables and Relationships
The following ER diagram illustrates the primary relationships between wiki content, user roles, and identity profiles within the Supabase schema.
The diagram shows the hierarchical relationship where modules contain articles, and articles maintain a history through versions.
Entity Definitions
| Table Name | Primary Purpose | Key Fields |
|---|---|---|
wiki_articles | Stores the main body of the Atlas documentation. | id, module_id, content_md, access_level, slug |
identity_profiles | Manages persistent identifiers (PIDs) and trust scores. | did, orcid, isni, doi_prefix, trust_score |
msr_events | Logs immutable audit trails for system actions. | id, actor_id, action, evidence_hash, severity |
github_repos | Tracks federated repositories and their metadata. | full_name, stars, language, federation_id |
user_roles | Defines access control using the app_role enum. | user_id, role (ciudadano, dev, admin, etc.) |
Sources: src/integrations/supabase/types.ts:40-350
2. Migration Lifecycle and Tracking
Database changes are managed via SQL migrations located in supabase/migrations/. These migrations follow a chronological naming convention to ensure deterministic updates to the schema.
Migration Inventory
The system tracks several critical migration phases as documented in the federation manifest:
- Initial Schema (
001_initial_schema.sql): Establishes the core tables for profiles and basic system data. - Identity & Membership: Migrations like
20250301_utamv_bci_membership.sqlhandle the evolution of the identity system. - Advanced Features: Includes extensions for university systems (
university_extended.sql) and territorial operating systems (rdm_digital_os.sql).
Sources: public/federation-manifest.json:200-225
3. Edge Functions and Logic Orchestration
Supabase Edge Functions act as the "FUSION CORE" and "UNIFIED API," orchestrating data flow between the database and external services.
TAMV Fusion Core
This function handles health checks and content synchronization across federated repositories. It verifies the availability of critical tables before performing updates.
This flow describes how the Fusion Core validates the database before synchronizing content and creating an immutable log.
Sources: federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:15-110
Unified API Modules
The tamv-unified-api exposes several domain-specific modules for interacting with the database:
- Identity (ID-NVIDA): Retrieves profile data and dignity scores.
- Governance (CITEMESH): Manages roles and DAO proposals.
- Economy (TCEP): Handles wallet balances and transaction ledgers.
Sources: federation/tamv-digital-nexus/supabase/functions/tamv-unified-api/index.ts:45-150
4. Security and Access Control
Access to the database is secured through a combination of Supabase Auth, Row Level Security (RLS), and custom Role-Based Access Control (RBAC) functions.
Application Roles
The system utilizes a custom enum app_role to define user permissions:
admin,dev,academia,gobierno,empresario,ciudadano.
Validation Logic
The database includes stored functions to check user permissions:
has_role(_role, _user_id): Checks for an exact role match.has_min_role(_min, _user_id): Checks if the user meets a minimum threshold of authority.
Sources: src/integrations/supabase/types.ts:356-385
5. MSR (Mutable System Record) Ledger
The MSR system utilizes the database to create an audit trail for every significant action. Each entry in the msr_events table is accompanied by an evidence_hash.
Evidence Generation
When an event (like a content sync or a DAO proposal) occurs, the system generates a hash of the payload to ensure integrity:
const evidenceHash = await crypto.subtle
.digest("SHA-256", new TextEncoder().encode(JSON.stringify(report)))
.then((buf) =>
Array.from(new Uint8Array(buf))
.map((b) => b.toString(16).padStart(2, "0"))
.join("")
);
Sources: federation/tamv-digital-nexus/supabase/functions/tamv-fusion-core/index.ts:114-123
Conclusion
The Supabase integration in TAMV Atlas provides a robust foundation for federated identity and content management. By combining a strictly typed PostgreSQL schema with versioned migrations and cryptographic event logging (MSR), the system ensures that "technological sovereignty" is maintained through verifiable and auditable data practices.
Sources: README.md:85-95, src/pages/wiki/modulo-omega/WikiValeMas.tsx:50-70