Edit history

Voice channels are only for talking. There is no way for users to do something together inside Fluxer, such as playing a game or using a shared tool, and no way for developers to build interactive apps that run inside Fluxer. Today they would have to leave Fluxer or ask everyone to install something separately.

Let third-party developers host small interactive web apps that users can open together inside a voice channel. An SDK connects the developer's app to the Gateway. Fluxer serves the app on its own isolated subdomain, shown in a sandboxed iframe with a Content Security Policy, and tracks which app each user has opened. Proposed MVP: app authentication, SDK connection registration, routing of HTML and static assets through the SDK, sandboxed rendering, and per-user session tracking. A client-side SDK for app-to-Fluxer communication would come later. This is an initial architectural direction, not a finalized design. I would be glad to help implement it, starting with the registry and lifecycle pieces, and I would welcome guidance since this would be my first Erlang project.

1. SDK endpoint and registry

• The SDK authenticates with the Gateway using an App Secret or Bot Secret. The Gateway validates it and resolves the app_id from PostgreSQL. Unknown or unauthenticated apps cannot register.
• SDK connections use RPC and a heartbeat (interval set relative to the connection timeout) to detect dead connections.
• A single Registry gen_server, under a supervisor, performs all registry writes. It keeps app_id -> {node, pid} and pid -> app_id in Redis and monitors each SDK process. Reads may go to Redis directly.
• Entries carry a TTL refreshed by the heartbeat, so stale entries expire if a node or process disappears.
• On DOWN, the Registry looks up the app_id through the reverse mapping and deletes the registration only if the stored pid still equals the terminated one. This stops a delayed DOWN from an old connection from removing a newer registration.
• A new authenticated connection for an app_id that already has one replaces it: gracefully close the old process, clear its mappings, then register and monitor the new one.

Open question: PIDs are only meaningful on their own node. I chose Redis (with a TTL) to keep this compatible with a possible future distributed setup. If the team prefers pg or another Erlang-native registry, I can switch.

2. Subdomains and isolation

• Each app gets its own origin, for example app-<id>.apps.<domain> (illustrative; final naming is up to the team).
• The Gateway resolves the hostname to an app_id, finds the SDK process through the Registry, and forwards the request over RPC. The SDK passes it to the app's own web server (for example on port 3000) and returns the response. HTML and static asset paths all follow the same route.
• The client embeds the app in an iframe with an explicit, minimal sandbox attribute, and responses carry CSP headers restricting scripts, connections, framing and embedded resources. The exact directives need to be designed around the capabilities apps are allowed to have.

3. Request flow

1. A user launches app 154 in a voice channel.
2. If the user is already in another app, disconnect them from it and clean up that session.
3. The Gateway resolves the subdomain, checks the Redis registration and gets the SDK process.
4. The Gateway sends GET / (or the requested path) over RPC. The SDK fetches it from the app server and returns it.
5. The client loads the response in the sandboxed iframe. Static asset requests follow the same path.
6. The active session is recorded in Redis as user_id -> app_id.

4. Future scope

A client-side SDK where app actions are sent over WSS to the Gateway, validated, routed to the app's SDK connection via RPC, and answered back to the client.

5. Feedback I would like

• Whether this should live in the existing Erlang Gateway or in a separate service. I am more comfortable in Rust, but I am happy to implement it in the existing Erlang codebase to avoid adding a microservice.
• Load: all app traffic, including static assets, would pass through the Gateway and RPC. Is that acceptable, or should assets be served another way?
• Safety: how apps are approved or limited (rate limits, resource limits, abuse handling). I have not designed this yet and would like to align with the team's trust-and-safety approach.
• Whether this fits the roadmap at all.