Kast Product culture part II: The technical edition

Making the right product decisions is a function of a company’s ability to ingest information from its users and interpret them in a way that makes sense both for the growth of the company and for the happiness of its users. Consider a Venn diagram for each product decision in which one circle represents how well it satisfies a user demand, another represents how it impacts sales (or other success metrics). The third circle is the company’s ability to execute on that product decision. A large portion of that ability to execute will be technical.

In this post, we’ll look at the technical decisions and trade-offs that have been involved in some of the user-centric product decisions Kast has made, which are discussed by our chief experience officer, Elina, in an earlier post on product culture. I’m going to go into some of the technology we have deployed in order to make those product decisions real for Kast’s community of users.

How we keep parties private by default

To a large degree, product decisions come down to default settings. Venmo, for example, sets transactions to be shared publicly by default. Twitter’s algorithmically determined news feeds are the default setting for its users. Recently, the video conferencing app Zoom had to change its default settings, after defaulting to a public setting allowed some people to “zoom-bomb,” or guess the unique meeting URL and join meetings, uninvited. These default settings set the user experience for most users, and send a message about the company’s priorities.

Kast watch parties are private by default. The workflow for private parties is, you either invite somebody or someone requests to join your party. There are two layers that are important in this system. The first is an API microservice layer that we call the Experience Orchestration Layer. It handles everything from listing parties to determining who’s in a party–basically all the data that comes into the user interface for rendering. The second layer turns over each user to a WebRTC server that understands whether that user is eligible to be in that party. From a technical perspective, you can’t authenticate to one of our WebRTC servers unless you’ve gone through the access-check process that verifies your permissions.

How we enable hosts with moderation features

Public watch parties are important on our platform, even though they represent a small percentage of activity on Kast. Our roadmap includes some exciting features that we’ll be unveiling in the coming weeks, built on public watch parties. In some ways, our public setting mimics Zoom’s former default setting, in which all conferences were public. However, “Kast-bombing,” or whatever the Kast equivalent of Zoom-bombing might be, would not be possible. Even in a public watch party, users have to be granted permissions by the host in order to stream video. Until that permission is granted, you can watch and you can chat, but you can’t stream video.

Party hosts (we have two categories: owners and designated moderators) can designate who can stream, they can delete messages from the chat, they can kick users (removed from the party, but allowed to return) and they can ban users (removed from the party and not allowed to return). Because we got a lot of our users from other dying or dead platforms, we quickly found what their behaviors and use cases were going to be and wrapped the security permissions around those cases, in order to prevent the annoyances that had been problematic on those past platforms.

Behaviors that we had to account for ranged from bizarre to evil. There were people who used to come on and just turn their audio on and shout, as well as some who liked to “show off” on video for lack of a better way of putting it. It’s hard to describe all of the possible scenarios in a way that would be suitable for public consumption. From Kast’s early days, it’s been our technical team’s priority to provide party hosts with moderating functionality that would allow them to address these issues.

Engineering on standards

The advantage of working with standards is, there’s thousands of people working on that standard at one time, finding bugs and security holes. Generally, the community of people developing on that standard will find a vulnerability before nefarious actors find it.

As a result, our development decisions usually go something like this: What’s the product requirement? Is there something out there that meets the requirement? Is that something standards-based? If the answer to the second and third questions is yes, and that standards-based product meets our needs, we prefer to use it, rather than build something ourselves. In this way, we think of ourselves as product-centric engineers. Some engineering-centric organizations will do engineering for engineering’s sake, to see if they can solve a problem. We don’t do that at Kast. It’s product-centric engineering.

That’s one of the reasons we chose to use WebRTC for routing. Encryption is a standard feature of WebRTC. In fact, it’s mandatory. Using something else for our web routing and video codecs would likely involve cobbling together encryption and proprietary technologies, falling short of the security assurances conveyed by a standards-based technology.

Our users gain access to watch party video streams via their shared membership on a WebRTC server, where multiple parties can exist but each party maintains its own membership access control. We don’t use web servers or proprietary codecs in any of our clients for proxying video or audio data, as the web server would represent a substantial security vector surface area on a user’s computer, which could be exploited remotely. The network interface that is responsible for adding the access permissions to an individual WebRTC server is not public, which decreases the security vector surface area. Only our separate microservice API layer, which has its own access and authentication protocols, is allowed to talk to the WebRTC servers in order to set up that membership access.

Why we don’t store your video

Sometimes the question of “can we execute” isn’t just about whether we could build a feature, it’s about the implications it would have for other systems that are essential to our product. One area where user demand isn’t necessarily aligned with executability is on storing video. For example, we’ve often discussed features where users could record video using the platform. The answer is, yes, we could add this feature, but then we would have to store that video somewhere, opening up other security vectors against someone accessing that content when they shouldn’t. We’re determined to minimize the potential for this kind of attack by not storing any user video whatsoever, until such time as we can guarantee it’s security.

There is no cache. All video is real-time routed. I can’t go join a party and look at what happened 10 seconds ago. I can only see what’s happening right now.

Not storing videos in the cloud enables us to assure our users that Kast’s streams are end-to-end encrypted. If we were storing videos in the cloud, there would be questions about whether those videos were encrypted; if someone was to gain unauthorized access to the storage, would they be able to watch everything without a decryption key? When you’re storing video, the answer is probably yes.

Conclusion

It’s easy for technical teams (and financial teams) to get into the habit of saying “no.” When product comes up with an idea, it’s “no, that will take too long,” or, “no, that will break things.”

A better mode for technical and product teams is to work in tandem, finding the product development priorities that sit in the center of the Venn diagram I described in the introduction: what are the things that are critical to our users, within our reach and good for our business? As we continue to identify those priorities, I look forward to sharing more of the methods that we use to achieve more product successes at Kast.