01
One contract for multiple surfaces
Connect exposes gRPC, gRPC-Web, and HTTP/JSON from the same edge for native clients, browsers, and external tooling.
Execution gateway
One platform for identity, modules, media, and external services.
Vianium concentrates Connect, auth, OAuth, billing, streaming, observability, and protected state behind one backend that serves apps, dashboard, and automation through the same contract.
Designed as an execution core: one layer for clients, plugins, and operations.
5 live modules
3 Connect transports
1 control plane
Current runtime
Connected stack
ConnectgRPCMongoDBRedisStripePrometheusGoNode.js
Active pieces
5 locally active modules
3 Connect transports
2 real-time streams
1 billing layer
Platform
The important parts already live in the central layer.
The product does more than connect services. It already gathers the pieces that usually end up scattered across backend, tools, and frontends: identity, protocols, linked accounts, media, health, and billing.
02
Identity and linked accounts in one place
Registration, login, refresh, revocation, and per-plugin OAuth remain centralized in the platform.
03
Core services already production-shaped
Health, boot info, Prometheus metrics, Stripe webhooks, and stream proxying already live inside the gateway.
04
Plugins with clear boundaries
Each module runs behind gRPC with typed contracts and operational isolation between capabilities.
Connect surface
gRPCgRPC-WebHTTP/JSONSSE
Core services
Auth + JWTPer-plugin OAuthMedia proxyStripe billingHealth + metricsLive events
Use cases
Real operating scenarios built from one execution layer.
Vianium already covers the areas that fragment fastest as a product grows: multiple surfaces, linked accounts, sensitive media, and automation.
01
Unify apps, dashboard, and external tooling
Use the same Connect contract for native surfaces, web, and automation instead of maintaining parallel backends.
02
Launch linked-account modules
Enable Reddit, Threads, Drive, or YouTube with per-plugin OAuth and isolated per-user state.
03
Operate messaging and media from the core
Keep media, sessions, events, presence, and sensitive flows inside the platform instead of scattering them across clients.
04
Open the product to agents and automation
Expose typed capabilities to tools and agents through the same edge, with centralized auth, revocation, and observability.
Developer experience
Clear contracts, visible boundaries, and one consistent surface to build on.
The platform does more than bundle capabilities. It also provides a disciplined way to extend them without duplicating auth, state, observability, or integration logic.
The gateway serves gRPC, gRPC-Web, and HTTP/JSON from the same contract.
Each module lives behind proto and gRPC, with clear boundaries between core and plugin.
OAuth, revocation, media, metrics, and health do not need to be rebuilt for every client.
Probes, metrics, and streams make the backend behave like real infrastructure instead of a black box.
Contract-first surface
The goal is to let apps, dashboard, and external tooling connect to one shared surface instead of duplicating auth, state, and integration logic.
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/JSONModules
Five active modules with concrete behavior, not decorative demos.
Each module already exposes real product operations while sharing the same identity, encryption, and operational fabric.
01 WhatsApp
Messaging
Messaging, media, groups, channels, communities, catalog, and real-time events on top of Baileys.
Messages and reply/edit/deleteMedia, locations, and pollsGroups, newsletters, and communitiesLabels, catalog, and presence
02
Media
YouTube
Search, metadata, captions, history, subscriptions, and authenticated streaming through InnerTube plus proxying.
Search and video metadataCaptions, related, and playlistsSubscriptions and historyStream proxy for playback
03 Reddit
Personal feed
Home feed, subreddits, profiles, posts, comments, and authenticated user actions.
Home feed and searchPost + commentsVote, save, and hideProfile and OAuth status
04
Publishing
Threads
Publishing, discovery, mentions, replies, and insights with the user account linked into the platform.
Create + publish flowMentions and repliesKeyword search and discoveryAccount and post insights
05
Storage
Drive
File browsing, folders, sharing, and chunked uploads on top of Google Drive.
List, get, and renameFolders and moveShare linksResumable uploads
Security
Security is already part of the runtime, not separate from the product.
Credentials, tokens, and sensitive data are protected through a real key hierarchy, authenticated encryption, and session revocation inside the backend.
A1
Hardened passwords with Argon2id
Credentials use Argon2id with 64 MB of memory, 3 iterations, a random 16-byte salt, and constant-time verification.
K2
256-bit MEK and per-user DEK
The MEK lives in VIANIUM_MEK and is never stored in Mongo. Registration creates one random DEK per user and stores it encrypted with AES-256-GCM.
D3
HKDF-SHA256 derivation per user and purpose
Operational keys are derived per user and per plugin to isolate Reddit, Threads, Drive, YouTube, and WhatsApp internal data.
E4
AES-256-GCM for sensitive data at rest
Encrypted blobs use a random 12-byte nonce and built-in authentication so tampering is detected before any payload is opened.
L5
Lookups without plaintext exposure
Queryable sensitive identifiers are indexed through deterministic HMAC-SHA256 values instead of exposing the original value in storage.
S6
Sessions with targeted revocation
JWT sessions use HS256 with a random 128-bit JTI and can be revoked by identifier when a cache backend is present.
Current coverage
Protection does not stop at login.
Today the model covers identity, linked accounts, and plugin-level sensitive persistence.
Credentials
Passwords are never stored in plaintext or reversible form.
Key hierarchy
The user DEK remains encrypted under the MEK, while the MEK stays outside the database.
Per-plugin OAuth
Reddit, Threads, Drive, and YouTube persist tokens under per-user, context-derived keys.
Messaging state
Chats, messages, contacts, media, and sessions use AES-256-GCM plus HMAC lookup hashes.
Architecture
A request enters once, and the rest of the system keeps the contract, state, and control intact.
The gateway receives clients, resolves identity, routes into plugins, and keeps operational visibility without forcing you to reimplement the same logic across every surface.
01
Typed ingress
The same proto definitions feed apps, dashboard, tools, and automation.
02
Core service resolution
Auth, billing, media, health, revocation, and webhooks live in the same layer.
03
Per-module execution
Each plugin receives gRPC with defined contracts and protected per-user state.
04
Visible operations
Probes, metrics, streams, and health control expose what the platform is doing in real time.
Operational flow
From the Connect edge into plugins, storage, and observability.
The architecture serves multiple surfaces without fragmenting authentication, encryption, billing, or telemetry.
Client ingress
Apps, web, and external tooling consume the same Connect edge.
Gateway core
Auth, OAuth, billing, media proxying, and health handlers.
Plugin fabric
Typed microservices for WhatsApp, YouTube, Reddit, Threads, and Drive.
Infrastructure
MongoDB, Redis, Stripe, and unified metrics under one runtime.
FAQ
What teams usually ask before they integrate the platform.
What exactly is Vianium today?
Today it is an execution platform with a Connect gateway, unified identity, billing, observability, and active modules for WhatsApp, YouTube, Reddit, Threads, and Drive.
Is it only for legacy systems?
No. It can serve thin or older clients, but the current product fits better as an execution backend for multiple surfaces, linked-account modules, and automation.
What kinds of clients can connect?
Native apps via gRPC, browsers via gRPC-Web, and external tools via HTTP/JSON. The same Connect layer handles the edge.
How do new capabilities get added?
As plugins or typed services behind the gateway. That lets the product expand without rewriting the shared logic in every client.
What belongs in the platform versus the client?
The platform already owns auth, per-plugin OAuth, JWT revocation, media, health, metrics, billing webhooks, and sensitive persistence. Clients stay focused on interface and user experience.
How is sensitive state protected?
With Argon2id for credentials, a 256-bit MEK outside the database, keys derived per user and purpose, AES-256-GCM, and session revocation by JTI.
Next step
Start with one account and expand from the core.
Attach modules when you need them. Keep identity, media, billing, and operations under one platform.