columbia
Kit de proxy HTTP auto-alojado para uso personal que implementa un modelo de confianza dividida mediante OHTTP (RFC 9458). Separa la identidad del cliente del contenido solicitado, evitando que ningún operador vincule quién hace qué petición. Requiere infraestructura propia y no es una VPN general.
Ficha actualizada 26 sept 2026, 17:27 · upstream 26 sept 2026, 16:57 · release v1.7.1
Qué es columbia
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Columbia es un toolkit de proxy HTTP diseñado para uso personal y no comercial, construido sobre el protocolo OHTTP (RFC 9458) para garantizar la privacidad mediante un modelo de confianza dividida estructural. A diferencia de las soluciones tradicionales, la arquitectura asegura que ningún operador individual posea simultáneamente la identidad del cliente y el contenido solicitado. El sistema se compone de cuatro servicios principales: relay, gateway, commons cache y token issuer, cada uno con responsabilidades específicas para proteger la privacidad en diferentes capas de la red.
La operación funciona mediante un camino de confianza dividida donde el relay recibe la identidad del cliente pero solo datos cifrados opacos, mientras que el gateway descifra el contenido pero nunca ve la IP del cliente. Esto impide que cualquier parte reconstruya el historial de lectura de un usuario sin complicidad entre operadores. El toolkit requiere auto-alojamiento en servidores propios y gestión de claves, no ofreciendo servicios gestionados en la nube.
El sistema incluye controles de abuso en el relay (limitación por IP, concurrencia) y permite caché de contenido público para reducir peticiones upstream. Es compatible con credenciales de nivel de aplicación anónimas y soporta estándares como HPKE y BHTTP, aunque no maneja autenticación vinculada a identidad de usuario ni actúa como túnel general tipo VPN.
- Lectura segura de contenido público (feeds, APIs) sin revelar quién accede
- Acceso a APIs públicas mediante credenciales compartidas de aplicación anónimas
- Implementación de transporte privado en aplicaciones que requieren separar identidad y contenido
- Caché descentralizada de recursos públicos para reducir latencia upstream
- Pruebas de modelos de confianza dividida sin depender de proveedores comerciales
- Arquitectura de confianza dividida: el relay ve la IP pero no el contenido, el gateway ve el contenido pero no la IP
- Cumplimiento estricto de RFC 9458 (OHTTP) y estándares HPKE para cifrado en tránsito
- Controles de abuso integrados en el relay sin registrar peticiones ni IPs en logs operativos
- Caché opcional para contenido público que reduce la carga en servidores upstream
- Soporte para tokens anónimos verificables mediante Apple App Attest y blind-signing
- Requiere auto-alojamiento y gestión manual de claves, no es un servicio SaaS
- No soporta autenticación vinculada a identidad de usuario (sesiones/login) en el proxy
- El gateway requiere configuración estricta de ALLOWED_TARGET_ORIGINS para evitar SSRF
- La privacidad depende de que los operadores del relay y gateway no coludan
- No es una VPN general; solo enruta peticiones específicas con credenciales anónimas
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Despliegue en contenedores o servidores propios. El relay debe ser el único punto público, exponiendo /ohttp-configs para claves del gateway. Configurar ALLOWED_TARGET_ORIGINS estrictamente en el gateway para evitar SSRF. Usar almacenamiento separado para el token issuer y el relay. No compartir credenciales de operador entre servicios. Verificar logs RED solo en relay.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.