Building live interpretation.
Maintaining the platform around it.

Overview

My work with FOSSASIA began in October 2025, well before GSoC. I started contributing to Eventyay’s shared platform: fixing checkout and permission problems, building organizer workflows, and improving the infrastructure that other features depend on. That work grew into ongoing maintenance, architecture planning, and reviews across repositories.

During GSoC, I built on those relationships to develop VoxBento’s live interpretation infrastructure and establish the Eventyay Business foundation, including pricing, entitlements, subscriptions, and billing. This report follows that continuous journey, from early Eventyay contributions through the work completed during the program.

GSoC project: VoxBento: Real-Time Speech Translation and Multilingual Interpretation. Contributor: Arnav Angarkar. Organization: FOSSASIA. The account below includes my wider FOSSASIA work and the people who mentored and collaborated with me throughout it.

Eventyay core: foundations across the platform

Speaker, session, and order import workflows

I built an end-to-end speaker and session import flow, covering upload, column mapping, asynchronous processing, and creation or update of the underlying records. The mapping layer handles custom questions and remembers configuration. The import service links speakers and submissions, resolves rooms and tracks, and makes imported sessions available to the organizer’s schedule editor.

This also meant fixing failures beyond the import form itself: sessions outside the configured event dates could disappear from the organizer editor; missing rooms and null descriptions could break scheduling; transient backend errors could leave processing pages stuck. The work connected import, data integrity, and scheduling into a usable organizer workflow. I also added an order-import mapping interface.

Merged evidence: speaker/session import and schedule-editor work #2629, order import mapping #3440, and speaker upsert corrections #3433.

Shared forms and permission boundaries

I integrated custom fields into order forms and centralized the built-in CFP field definitions. Saved form layouts now normalize missing built-in fields against a canonical order, rather than relying on several independently maintained lists. This gives later form changes a consistent place to define their behavior.

Related permissions work made reviewer track selection event-scoped, so organizers could choose tracks in the context of the correct event. Earlier checkout work addressed a voucher-redemption race by acquiring the database row lock before checking availability. These are small-looking interfaces with important underlying guarantees: consistent fields, correctly scoped access, and limits that hold under concurrent requests.

Merged evidence: order-form custom fields #1975, canonical CFP definitions #3442, event-scoped track permissions #2481, and voucher locking #1399.

Telemetry, authentication, and contributor infrastructure

I implemented the deployment telemetry sender and receiver: a Django service sends daily deployment/version information, using bucketed counts, to a Google Apps Script receiver. This established a mechanism for understanding deployments rather than treating individual production instances as invisible to maintainers.

I also moved Wikimedia social authentication back through Django-allauth’s native flow instead of bypassing its account records in a custom callback. The AI-assisted contributor workflows are covered in their own section below.

Merged evidence: telemetry #1996, native social login #3444.

Plugin delivery and platform performance

As Eventyay’s plugin ecosystem grew, I implemented separate dependency behavior for development and production. Development builds can refresh plugins; production builds use locked revisions. The cross-repository update receiver triggers development builds but opens a pin-update PR for production, keeping review between an upstream plugin change and its release.

Other platform work removed full-schedule serialization from the speaker overview in favor of targeted pagination, and centralized image optimization across uploads, settings, and historical-image backfills. These are shared mechanisms that benefit multiple organizer and attendee workflows.

Merged evidence: plugin dependency strategy #4780, cross-repository update workflow #5095, speaker pagination #4785, and shared image pipeline #5175.

A neutral core for commercial extensions

The Business work also required foundations in Eventyay itself. I moved commercial settings out of core and added neutral entitlement, fee-policy, and billing-ownership interfaces. These let Business supply commercial policy without requiring Core or payment plugins to import Business models directly. The Business case study below explains how those interfaces connect to pricing and collection.

Merged evidence: commercial-policy separation #5985, entitlement interface #5441, and neutral fee-policy resolver #6415.

VoxBento: the live interpretation system

Keep live audio independent of AI processing

I implemented browser WHIP publishing into MediaMTX, made that the primary ingest path, and moved the interpreter portal to FastAPI and WebSocket coordination. This established a clear boundary: the media server transports interpreter audio; Python manages sessions, roles, booth state, and asynchronous processing.

The distinction matters when speech recognition or translation slows down. An AI worker should not sit in the critical path between an interpreter’s microphone and a listener. The early relay implementation also addressed interpreter handoff: keeping the outgoing stream briefly alive while the next publisher connects avoids tearing down the listener’s HLS stream.

Merged evidence: browser WHIP publishing #56, primary MediaMTX ingest #78, and FastAPI migration and interpreter relay #81. These establish the implementation history; they are not a benchmark of current end-to-end latency.

Turn floor audio into captions and translation

I added the floor-audio path: a headless browser joins the Jitsi conference, captures its audio, and streams it through RTSP into MediaMTX. Transcription workers generate segments, translation workers process finalized text, and WebSockets deliver results to listeners. Room and booth configuration lets organizers select providers and target languages; transcripts and translations persist for later access.

This extended the platform beyond human interpreter booths to captions and machine-assisted multilingual access to the main session. Floor capture, transcription, and translation #159 links the implementation, architecture, configuration, and demonstration material.

Make the system usable under real operating conditions

I worked on playback and operational failures as well as features. A client-side audio scheduler buffers synthesized speech; model-download states reach the interface instead of appearing as unexplained translation timeouts; unwanted capture and comfort-noise artifacts were removed. Security work added production secret validation, OAuth throttling, token-log redaction, and lifecycle auditing.

Merged evidence: playback and translation reliability #411, production secret validation #223, and OAuth security and observability #379.

Integration is a contribution with its own responsibilities

Some later PRs integrate existing work rather than originate every feature. For example, AI interpretation configuration #888 preserves the original implementation and authorship by @thisisanubhav, while resolving conflicts, reconciling migrations and routing, and addressing review feedback. I count that as integration and hardening work, not sole authorship of the original feature.

Eventyay Business: from foundation to billing

Establish the plugin and its data model

I built the initial plugin scaffold and introduced Tier, TierVersion, TierPrice, and TierEntitlement. These separate a commercial plan from its published configuration, currency and billing interval, and the capabilities it grants. The administration workflow makes published versions immutable and creates a new draft when a plan changes, preserving historical configuration.

I then added the capability registry and organizer subscriptions, including automatic Free-tier assignment. This provides the underlying model for pricing and access rather than embedding plan names throughout the application.

Merged evidence: scaffold #28, foundational models #31, versioned publication workflow #34, capability registry #35, and subscriptions #37.

Keep commercial policy outside Eventyay core

The matching core work introduced a thin entitlement API and a generic provider interface. Feature code asks whether an organizer may use a capability; a plugin provides the decision. Core does not need a direct dependency on Business tier models. With no restricting provider, the entitlement interface preserves the unrestricted self-hosted behavior.

Usage events feed an organizer-scoped, database-enforced idempotency mechanism. A retried usage event must not become a second billable record. Core integration also connects free registrations, bulk email usage, and administrator-seat checks to that interface.

Merged evidence: entitlement kernel #5441, provider decisions #5447, idempotent usage records #43, and core usage and limits #5505.

Build pricing and the subscription lifecycle

I implemented Stripe Checkout and webhook integration for subscriptions and add-ons, then added upgrades, scheduled downgrades, proration, and grace-period handling. The public pricing page became configurable rather than a separate hardcoded view of the offering.

These were steps in an evolving billing architecture. The initial subscription integration is part of the history; the later consolidated-invoice work establishes a different collection boundary and migration controls.

Merged evidence: Checkout and webhooks #77, plan changes #78, and public pricing #146.

Make invoices reproducible and payment ownership explicit

The consolidated billing work reuses Core’s canonical organizer customer and payment method, records authorization for off-session collection, and separates invoice calculation from payment collection. I added auditable invoices, reproducible calculation, and collection through Stripe PaymentIntents.

A key migration concern was preventing the legacy collector and the new billing component from charging the same organizer. Core now exposes a generic ownership signal; Business claims ownership only at an explicit cutover boundary. Preflight checks assess customer, payment method, authorization, and competing legacy subscriptions before activation.

Merged evidence: canonical payer and authorization #105, auditable invoices #106, reproducible calculation #107, PaymentIntent collection #108, core collection ownership #6499, and migration preflight #110.

Verify before activating collection

I built a reconciliation mode that executes invoice calculation inside a rollback-only transaction and persists a comparison snapshot. Administrators can inspect results, export them, and explicitly accept a ready result. Acceptance records the exact fingerprint; changed calculations invalidate the earlier acceptance. The activation path rechecks readiness under a lock.

This is a useful example of the architecture behind the UI: calculate → inspect → accept → activate, with billing effects kept out of reporting mode. The merged changes include regression tests for calculation side effects, acceptance, and blocked-organizer behavior.

Merged evidence: non-collecting reconciliation #127, review and acceptance #128, and controlled rollout #130.

The history also includes automatic preparation #141, which was reverted in #142. It is included in the authored-PR ledger but is not presented as a retained capability. Merged PR totals alone cannot describe the final state of a system.

Coding with AI: shared instructions and repository skills

Alongside product development, I built and integrated infrastructure for AI-assisted coding across Eventyay, VoxBento, and Visdom. This included agent instruction files, repository context, and task-specific SKILL.md playbooks. The aim was to make project knowledge reusable: where code belongs, which architectural boundaries matter, how to perform a change, and what to validate before submitting it.

One source of truth across coding assistants

In Eventyay, I expanded agents.md into a canonical policy and added small adapter files for Claude, Codex, Cursor, and GitHub Copilot. Those adapters point back to shared rules rather than maintaining independent copies. The policy records concrete constraints such as event-scoped queries, import conventions, frontend standards, and ORM efficiency, with links to file-specific instructions.

In Visdom, I added CLAUDE.md, CODEX.md, GEMINI.md, and Copilot instructions that reference the existing AGENTS.md and skill directory. This gives contributors using different assistants a common starting point while keeping repository policy in one place.

Merged evidence: Eventyay unified agent policy #2447 and Visdom skill and assistant integration #1301.

Turn project knowledge into practical workflows

For Eventyay, I introduced skills for Django models, API endpoints, forms, migrations, local development, Docker deployment, documentation, and repository navigation. A follow-up added frontend and pull-request workflows, reference material, templates, validation scenarios, and a skill-layout validation script. I also corrected deployment guidance and skill paths as the system evolved.

For VoxBento, I introduced architecture, route, database, transcription, and change-impact maps alongside skills for navigation, architecture and security review, incident investigation, testing, and production-readiness review. These give an assistant context for tracing a change through the actual application. Follow-up work added YAML metadata for skill discovery and integrated a broader library of planning, implementation, debugging, review, and handoff skills.

For Visdom, I expanded and standardized skills around its own engineering concerns: authentication, Python client behavior, frontend pane lifecycle, callbacks, environment persistence, offline replay, streaming performance, and polling parity. Each playbook identifies when to use it, the workflow to follow, and relevant guardrails and code references.

Merged evidence: Eventyay skills #2767, standardization and validation #3118, VoxBento context and skills #142, discovery metadata #184, additional skill integration #219, and Visdom workflows #1301.

Bring the same discipline to review

I later added an AI code-review protocol for Eventyay #5000, covering architecture checks, file-specific standards, security validation, and actionable feedback. This extends the shared guidance from implementation into review.

Together, this work made AI-assisted contribution a documented, repository-aware workflow. My contribution spans authoring project-specific instructions and integrating reusable skills; it does not imply original authorship of every imported playbook. The merged files demonstrate the infrastructure delivered, without claiming a measured productivity gain or replacing human review.

Issues, architecture, and planning

I opened 333 issues across FOSSASIA in the audited snapshot. They include reproducible bugs, architectural proposals, implementation plans, and acceptance criteria. This work helped turn a broad feature request into changes that contributors could implement and reviewers could evaluate.

• Interpretation architecture. VoxBento RFC #40 documents the starting system, missing capabilities, media-path decisions, role model, integration boundaries, and a phased implementation roadmap. It records the early design; later PRs show how that design evolved.
• Commercial platform boundaries. Eventyay epic #5890 lays out ownership across Core, Stripe, and Business, and the transition to consolidated organizer invoices. This links the cross-repository foundation to the implementation sequence.
• Concrete data and validation contracts. Business #4 specifies tier, version, price, and entitlement models. Reconciliation #124 specifies rollback-only calculation, reproducible snapshots, and tests that demonstrate the absence of billing side effects.

Browse every issue I opened across FOSSASIA. An opened issue records problem definition and coordination; its implementation and current status are visible in the linked discussion and PRs.

Maintenance and review work

Reviewing was a substantial part of my contribution. It included checking authorization across repository boundaries, following changes through migrations and integration tests, and requesting fixes before accepting an implementation.

Three examples show the substance behind the review totals:

• Access rules across Eventyay and VoxBento. In Eventyay Interpretation #146, I identified a fallback that could grant interpreted-audio access to someone holding a paid non-admission product, even when Core denied video access. The review asks the plugin to use the authoritative Core rule and add regression coverage.
• Concurrency and resource lifetime. In VoxBento #694, I requested lifecycle-safe cleanup for a per-booth lock registry and corrected documentation of conditional authentication. The concern was both unbounded retained locks and preserving mutual exclusion during cleanup.
• Integration without losing security behavior. In VoxBento #810, I requested preservation of queued notifications and the shared listener-safe broadcast path during a rebase. The follow-up approval records the integration fixes and validation.

These examples are evidence of review activity, not a claim that every reviewed PR was merged or that every requested change is complete. Review submissions are counted separately from distinct PRs and from authored implementations.

Engineering lessons

Define ownership before extending behavior. In VoxBento, media transport and AI processing need separate responsibilities. In Eventyay Business, commercial policy belongs behind a provider interface, while collection ownership must be explicit during migration. Both prevent one subsystem’s behavior from silently changing another’s guarantees.

Retries need durable identities. A usage event, invoice calculation, or notification can be retried. Database constraints, source references, and reconciliation fingerprints make repeated operations inspectable and help prevent duplicate effects.

A successful request is not sufficient validation. Permission fallbacks, lock cleanup, provider failures, and legacy collection paths require tests that exercise the failure boundary. The linked reviews and migration changes show why checking only the happy path misses consequential defects.

Integration work needs attribution. Preserving another contributor’s commits, resolving migrations, and closing review findings are valuable work. Describing them accurately makes the record clearer than claiming ownership of every line in an authored PR.

Current state and remaining work

This is a working draft, audited on 26 October 2026. The extended GSoC submission deadline is 2 November 2026, 18:00 UTC; it is not a statement that every deployment or rollout is complete.

• Merged implementation: the selected evidence links establish the VoxBento infrastructure and the Eventyay Business foundation, pricing, invoice, reconciliation, and rollout work described above.
• Open authored work: VoxBento #237 remains open in this snapshot. Related AI configuration work has since landed through #888; its final disposition should be reconciled before submission, rather than counted twice as a delivered feature.
• Closed without merging: the filtered GitHub search shows these PRs directly. Some may be superseded; closure alone does not prove either delivery or abandonment.
• Operational verification: merged billing code is not proof that every organizer has completed cutover or that live collection has been verified. Deployment status, final upstream revisions, and mentor acceptance remain to be recorded.
• Final validation: freeze the evidence window at submission, reconcile remaining PRs, and record reproducible test commands and results against the final revisions. Test results cited inside upstream PRs are historical author reports; this report preparation did not rerun the upstream application suites.

Handoff and supporting material

For installation and continued development, use the maintained VoxBento README, VoxBento documentation, and Eventyay Business setup instructions. Business runs as an Eventyay plugin and needs the host development environment; its README also explains the platform-fee upgrade considerations.

The linked PRs preserve implementation discussions, commits, and review history. The GitHub searches below let readers explore authored PRs, opened issues, and reviewed work directly, including contributions from before GSoC.

My engineering notes, GSoC project walkthrough, and talk slides provide additional context. Conference demonstrations are supporting material; they are not substituted for measured performance results.

Mentors and close collaborators

My main mentor throughout this journey was Mario Behling (@mariobehling). I also worked closely with Srivatsav Auswin (@Sak1012), Hong Phuc Dang (@hpdang), Nils Magnus (@Nils-Magnus), Norbert Preining (@norbusan), and Nguyễn Hồng Quân (@hongquan).

These relationships began before GSoC. Meeting and working together at FOSSASIA Summit brought the collaboration beyond issue threads and pull requests: we could discuss the platform, work through problems together, and build on the context we had developed remotely.

During the coding period, I collaborated closely with Saksham Sirohi (@Saksham-Sirohi), Nirupon Pal (@Nirupon123), and Rachit Makwana (@Rachit7168). Our work crossed implementation, review, and integration. Examples include Saksham’s widget and CORS work, Nirupon’s interpretation integration, and Rachit’s session-import mapping work, all of which appear in my review record.

I am grateful to these mentors and collaborators, and to the wider FOSSASIA community, for the discussions, reviews, and shared work behind this report.