6 posts tagged with "architecture"

For years, our company has been a well-known provider of BigBlueButton hosting and support services. We've deployed, managed, and scaled it for countless clients, and we have a deep respect for the role it has played in the open-source education community. It paved the way.

But after years in the trenches, supporting live sessions, online classes, and events at scale, we found ourselves running into the same fundamental walls. We weren't just using the software; we were experiencing its architectural limits firsthand. The frustration wasn't just about bugs; it was about an architecture that, while powerful for its original purpose, presented challenges for the kind of elastic scalability and developer agility that modern web applications demand.

We realized we had a choice: continue building workarounds, or take everything we had learned and build the solution we knew our users needed.

We chose to build. This is the story of why Plug-N-Meet exists.

We’ve all felt that moment of panic. You’re in an important online meeting, the chat is full of crucial links, and then you accidentally hit refresh. Everything is gone. To solve this, many applications store your entire session on their backend servers. This allows them to restore your session, but it comes at a huge cost: your sensitive data is now stored permanently on someone else's hard drive.

At plugNmeet, we believe this is the wrong trade-off. We've made a deliberate architectural choice to use your browser's own storage to provide a resilient experience without compromising your privacy.

Our philosophy is simple: if we don't need the data on our server to make the service work, we don't touch it.

What is a meeting recording? Is it just a collection of video and audio streams? Or is it a faithful replica of a live, interactive experience?

At Plug-N-Meet, we believe a recording should be a perfect, trustworthy artifact. When you watch it back, the whiteboard annotations should appear at the exact moment the speaker was discussing them. The chat messages should pop up in perfect sync with the conversation. The shared presentation should be exactly as the audience saw it.

To achieve this perfect fidelity, we made a deliberate architectural choice for our recorder: we record the final, rendered output, not just the individual parts. This article explains why this headless Chrome-based approach, while CPU-intensive, is fundamentally better and more reliable than the alternatives.

In the world of secure communication, End-to-End Encryption (E2EE) is the gold standard. It ensures that only the participants in a conversation can decrypt and view the media streams, not even the server itself. At plugNmeet, we've implemented a robust E2EE model based on the WebRTC Insertable Streams API.

But "E2EE" isn't a single, one-size-fits-all solution. A critical question remains: where do the encryption keys come from, and who manages them?

plugNmeet offers two distinct models for managing E2EE keys, controlled by a simple setting: enabled_self_insert_encryption_key. Understanding the difference is key to choosing the right security posture for your application.

If you manage a Learning Management System (LMS) like Moodle or a Content Management System (CMS) like WordPress, you've likely faced this frustrating scenario: you have a vibrant community, a rich content library, and a well-defined user base, but the moment you need to host a live class or a webinar, you have to send everyone away to a third-party, standalone application.

You generate a Zoom link, post it on your site, and hope your users can find it, log in correctly, and navigate back when it's over. This experience is clunky, disjointed, and it breaks the seamless learning environment you've worked so hard to build.

At plugNmeet, we believe this is a fundamentally flawed workflow. That's why we made a deliberate architectural choice: to be a plugin-first platform, not just another standalone app.

Every great application is built on a foundation of smart architectural choices. For a real-time video conferencing platform, these choices are the difference between a smooth, reliable experience and a frustrating mess of lag, dropped calls, and connection errors.

When we designed plugNmeet, we had a clear set of goals: the platform needed to be high-performance, horizontally scalable, resilient, and easy for developers to build upon. This led us to make two fundamental decisions for our backend: we chose LiveKit for our media server and NATS for our real-time messaging layer.

This article is a deep dive into the "why" behind these critical choices.