01
Un contrato para varias superficies
Connect expone gRPC, gRPC-Web y HTTP/JSON desde el mismo borde para clientes nativos, navegadores y tooling externo.
Gateway de ejecución
Una sola plataforma para identidad, módulos, media y servicios externos.
Vianium concentra Connect, auth, OAuth, billing, streaming, observabilidad y estado protegido detrás de un backend que sirve apps, dashboard y automatización con el mismo contrato.
Diseñado como núcleo de ejecución: una sola capa para clientes, plugins y operación.
5 módulos activos
3 transportes Connect
1 plano de control
Runtime actual
Stack conectado
ConnectgRPCMongoDBRedisStripePrometheusGoNode.js
Piezas activas
5 módulos en producción local
3 transportes Connect
2 streams en tiempo real
1 capa de billing
Plataforma
Lo importante ya está en la capa central.
El producto no solo conecta servicios. Ya reúne las piezas que normalmente terminan dispersas entre backend, herramientas y frontends: identidad, protocolos, cuentas enlazadas, media, health y facturación.
02
Identidad y cuentas enlazadas en un solo lugar
Registro, login, refresh, revocación y OAuth por plugin quedan centralizados en la plataforma.
03
Servicios núcleo listos para producción
Health, boot info, métricas Prometheus, webhooks de Stripe y stream proxy ya viven dentro del gateway.
04
Plugins con límites claros
Cada módulo corre detrás de gRPC, con contratos tipados y aislamiento operativo entre capacidades.
Superficie Connect
gRPCgRPC-WebHTTP/JSONSSE
Servicios centrales
Auth + JWTOAuth por pluginProxy de mediaBilling StripeHealth + metricsEventos en vivo
Casos de uso
Escenarios reales para lanzar productos conectados desde una sola capa.
Vianium ya cubre los frentes que más rápido se fragmentan cuando el producto crece: múltiples superficies, cuentas enlazadas, media sensible y automatización.
01
Unificar apps, dashboard y tooling externo
Usa el mismo contrato Connect para superficies nativas, web y automatización sin mantener backends paralelos.
02
Lanzar módulos con cuentas enlazadas
Activa Reddit, Threads, Drive o YouTube con OAuth por plugin y estado aislado por usuario.
03
Operar mensajería y media desde el core
Mantén media, sesiones, eventos, presencia y flujos sensibles dentro de la plataforma en lugar de dispersarlos en clientes.
04
Abrir el producto a agentes y automatización
Expón capacidades tipadas a herramientas y agentes sobre el mismo borde, con auth, revocación y observabilidad centralizadas.
Experiencia técnica
Contratos claros, límites visibles y una superficie consistente para construir encima.
La plataforma no solo empaqueta capacidades. También expone una manera disciplinada de extenderlas sin duplicar auth, estado, observabilidad ni lógica de integración.
El gateway sirve gRPC, gRPC-Web y HTTP/JSON desde el mismo contrato.
Cada módulo vive detrás de proto y gRPC, con límites claros entre core y plugin.
OAuth, revocación, media, métricas y health no se vuelven a implementar por cliente.
Probes, métricas y streams permiten tratar el backend como infraestructura real, no como una caja negra.
Superficie tipada
El objetivo es que apps, dashboard y tooling externo se conecten a una misma superficie en lugar de duplicar auth, estado y lógica de integración.
service AuthService {
rpc Login(LoginRequest) returns (AuthResponse);
rpc Register(RegisterRequest) returns (AuthResponse);
}
service YouTubeService {
rpc Search(SearchRequest) returns (SearchResponse);
rpc GetStreamURLs(GetStreamURLsRequest) returns (GetStreamURLsResponse);
}
// One edge: gRPC + gRPC-Web + HTTP/JSONMódulos
Cinco módulos activos con funciones concretas, no demos decorativas.
Cada módulo ya expone operaciones reales del producto y aprovecha el mismo tejido de identidad, cifrado y operación.
01 WhatsApp
Mensajería
Mensajería, media, grupos, canales, comunidades, catálogo y eventos en tiempo real sobre Baileys.
Mensajes y reply/edit/deleteMedia, ubicaciones y pollsGrupos, newsletters y comunidadesLabels, catálogo y presencia
02
Media
YouTube
Búsqueda, metadatos, captions, historial, suscripciones y streaming autenticado mediante InnerTube y proxy.
Search y video metadataCaptions, related y playlistsSubscriptions e historyStream proxy para reproducción
03 Reddit
Feed personal
Home feed, subreddits, perfiles, posts, comentarios y acciones autenticadas del usuario.
Home feed y searchPost + commentsVote, save y hidePerfil y estado OAuth
04
Publishing
Threads
Publicación, discovery, menciones, replies e insights con cuenta enlazada del usuario.
Create + publish flowMentions y repliesKeyword search y discoveryAccount y post insights
05
Storage
Drive
Exploración de archivos, carpetas, sharing y uploads por chunks sobre Google Drive.
List, get y renameFolders y moveShare linksResumable uploads
Seguridad
La seguridad ya forma parte del runtime, no vive aparte del producto.
Credenciales, tokens y datos sensibles se protegen con una jerarquía de claves real, cifrado autenticado y revocación de sesión dentro del backend.
A1
Contraseñas endurecidas con Argon2id
Las credenciales usan Argon2id con 64 MB de memoria, 3 iteraciones, salt aleatorio de 16 bytes y verificación en tiempo constante.
K2
MEK de 256 bits y DEK por usuario
La MEK vive en VIANIUM_MEK y no se guarda en Mongo. En el registro se genera una DEK aleatoria por usuario y se persiste cifrada con AES-256-GCM.
D3
Derivación HKDF-SHA256 por usuario y propósito
Las claves operativas se derivan por usuario y por plugin para aislar Reddit, Threads, Drive, YouTube y los datos internos de WhatsApp.
E4
AES-256-GCM para reposo sensible
Los blobs cifrados usan nonce aleatorio de 12 bytes y autenticación integrada para detectar manipulación antes de abrir el contenido.
L5
Lookups sin texto plano
Identificadores sensibles consultables se indexan con HMAC-SHA256 determinístico en lugar de exponer el valor original en la base.
S6
Sesiones con revocación dirigida
Los JWT usan HS256 con JTI aleatorio de 128 bits y pueden revocarse por identificador cuando existe backend de cache.
Cobertura actual
La protección no se queda en el login.
Hoy el modelo cubre identidad, cuentas enlazadas y persistencia sensible a nivel de plugin.
Credenciales
Las contraseñas nunca se guardan en claro ni en formato reversible.
Jerarquía de claves
La DEK del usuario queda cifrada bajo la MEK y la MEK permanece fuera de la base de datos.
OAuth por plugin
Reddit, Threads, Drive y YouTube persisten tokens con claves derivadas por usuario y contexto.
Estado de mensajería
Chats, mensajes, contactos, media y sesiones usan AES-256-GCM con hashes HMAC para lookups.
Arquitectura
Una solicitud entra una vez y el resto del sistema conserva contrato, estado y control.
El gateway recibe clientes, resuelve identidad, deriva hacia plugins y mantiene visibilidad operativa sin obligarte a reimplementar la misma lógica en cada superficie.
01
Entrada tipada
Las mismas definiciones proto alimentan apps, dashboard, herramientas y automatización.
02
Resolución de servicios core
Auth, billing, media, health, revocación y webhooks viven en la misma capa.
03
Ejecución por módulo
Cada plugin recibe gRPC con contratos definidos y estado protegido por usuario.
04
Operación visible
Probes, métricas, streams y control de salud muestran qué está ocurriendo en tiempo real.
Flujo operativo
Del borde Connect hacia plugins, storage y observabilidad.
La arquitectura sirve varias superficies sin fragmentar autenticación, cifrado, billing ni telemetría.
Entrada de clientes
Apps, web y tooling externo consumen el mismo borde Connect.
Core del gateway
Auth, OAuth, billing, proxy de media y handlers de salud.
Tejido de plugins
Microservicios tipados para WhatsApp, YouTube, Reddit, Threads y Drive.
Infraestructura
MongoDB, Redis, Stripe y métricas unificadas bajo el mismo runtime.
FAQ
Lo que normalmente se pregunta antes de integrar la plataforma.
¿Qué es exactamente Vianium hoy?
Hoy es una plataforma de ejecución con gateway Connect, identidad unificada, billing, observabilidad y módulos activos para WhatsApp, YouTube, Reddit, Threads y Drive.
¿Está orientado solo a sistemas legacy?
No. Puede servir clientes delgados o antiguos, pero el producto actual encaja mejor como backend de ejecución para múltiples superficies, módulos conectados y automatización.
¿Qué superficies pueden conectarse?
Apps nativas vía gRPC, navegadores vía gRPC-Web y herramientas externas vía HTTP/JSON. El borde lo resuelve la misma capa Connect.
¿Cómo se agregan nuevas capacidades?
Como plugins o servicios tipados detrás del gateway. Eso permite ampliar el producto sin reescribir la lógica compartida en cada cliente.
¿Qué se resuelve en la plataforma y qué queda fuera?
Dentro ya viven auth, OAuth por plugin, revocación JWT, media, health, métricas, webhooks de billing y persistencia sensible. Los clientes se quedan con interfaz y experiencia.
¿Cómo se protege el estado sensible?
Con Argon2id para credenciales, MEK de 256 bits fuera de la base, claves derivadas por usuario y propósito, AES-256-GCM y revocación de sesión por JTI.
Siguiente paso
Empieza con una sola cuenta y expande desde el núcleo.
Conecta módulos cuando los necesites. Mantén identidad, media, billing y operación bajo una sola plataforma.