Lately, I've been spending a lot of time picking up groceries for senior citizens in my town, and I often call them when I drop everything off to make sure they got it okay. One woman ended up talking with me on the phone for over an hour, just chatting about college and life and her "fun years" as she called them. It occurred to me that there are a truly massive number of people, especially senior citizens who are not extremely adept at using technology or don't have close family members, who are completely isolated right now. We wanted to find an extremely simple way to connect people over common interests on a safe and friendly platform that doesn't require any previous technical experience.
What it does
The site has very few buttons and only 2 pages to keep it as simple as possible. After signing up, a user can either call people that they have already spoken to or select from an endless number of topics to search for a friend to talk with about. Once they finish selecting topics, they enter a "lobby" where the site pairs them up with someone looking to discuss similar topics and they can video chat or phone chat for as long as they'd like.
A sample user is Margaret, an 80-year-old woman who lives alone and does not have anyone in the area that can visit her or call her. Through this site, she can sign up for an account using her email and input all of her favorite authors as topics. When she clicks the find a friend button she is paired up with Amanda, a 22-year-old English major who also loves those books and is quarantined at home. They talk for an hour and agree to talk for an hour or two a couple times a week to have a “virtual book club” and talk about their favorite books. Margaret and Amanda both feel a little less alone now.
To elaborate further on the steps required for use of the site, let’s go through Margaret’s case.
- Margaret enters her email, her name, and a password to use for the account
- She clicks “find a new friend” to open the pop-up window.
- She types in each one of her favorite authors to the search bar to add them as conversation topics.
- She clicks “Ready to find a friend!”
- After a couple of moments, Margaret is automatically connected to a call with Amanda
- Later, when Margaret returns to the site, Amanda is listed as an “Old friend” so that it’s easy for Margaret to call her again!
What we have so far
What we have currently is a design mockup made on Figma and a solid plan for how to move forward. Our website is simple, and our front end will be able to be developed fairly quickly. Laid out below is our plan for further development.
The frontend will be written in React, allowing for creating web apps and desktop apps with minimal overhead. Outside of basic authentication tasks, the application itself will have to store minimal data, only needing to persistently store information on each customer and previous contacts.
When a customer requests to be connected with another customer, they will be entered into a queue stored ephemerally. Failures will be reported to the client, who will be prompted to reconnect. In the event of multiple failures, a client will be able to view a modal that presents them with some steps for debugging.
The queue will match on a best-effort basis as described above, with the server prompting waiting users with relevant queries, such as whether they’d be interested in discussing a different topic. Upon a match, if both users confirm, the server will act as an intermediary to negotiate a video connection over webRTC or something similar.
The queue will be stored in Redis or some other distributed queueing system. The language and framework that the server is implemented in is immaterial, given precisely how generic the interface being provided is. That said, we are considering Go and Node/Express.
The most natural primary concern in scaling this out to many users is that too many video streams would overwhelm our infrastructure. However, given that all connections are peer-to-peer, the vast majority of data does not reach our servers. Operating a service where the individual web workers are stateless, with all state being stored in Redis or an outside database, allows simple horizontal scaling and portability between local and cloud platforms. In a local deployment, the web workers, database workers, and Redis workers could be easily spun up as individual containers. In production, the scaling of each service could be abstracted away by putting each behind its own load balancer.
Given that the target of this application isn’t necessarily tech-savvy, we will be designing around ease of use. Our application can be designed around a single page with all buttons clearly marked with text reflecting their purpose. We believe that not assuming that our clients have any intuition as to the meaning of symbols or the locations of various features is the best way to ensure a usable application and that keeping a simple feature set on a single page is the most effective way to exorcise unnecessary complexity.
Additionally, our application will contain a set of interactive guides that walk a customer through all basic features-- making a new connection, talking with an old one, and saving a connection. The interactivity will empower the customer and reinforce their ability to do it on their own in the future.
Given that the target of this application may be disabled, some critical features must be present at the outset to ensure that everyone can effectively use this application. First off, all text will be resizeable through a bar present on the screen at all times. Second, all pages will have full-screen reader support, eased by having buttons with text.
As this is video communication between two individuals, we need to take measures to prevent customers’ data from being accessed anomalously. The first measure we’ll take to prevent this is simply not storing much information-- we have no need for any location information, for instance. Of the information that we have for a single customer, all that we will display to another customer is the first customer’s first name and whether they are online.
As noted more in-depth below, we will encourage users to not reveal personal or financial information by displaying a reminder to the customer.
In a basic implementation, communication would occur directly between the two client computers. An adversary could be able to get more information on another customer from their IP address. This could be remedied in a few ways-- using an API could obscure the IP addresses of customers from each other. Using a third-party service, such as by creating a meeting in Zoom and then opening it, could also serve to remedy this. We could also create a lightweight proxy service to obscure the IP addresses and separate it from the remainder of the services, ensuring that the performance of each service is decoupled.
Malicious and Impermissible use
In general, most malicious users will attempt to phish elderly or less technically savvy individuals. While there is no strict way to prevent this, we provide a constant view reminding users to not give anyone money or divulge personal information. In our current design, it is displayed to the right of the video screen, but alternatively, it could be flashed at a configurable time interval.
Additionally, we will provide a button visible at all times to report the person on the other end of the call. Once a customer reports someone, regardless of the result of the moderation process, they will never be matched with that person again.
There are additional behaviors, such as nudity, which we would like to avoid showing to our customers. Video will be delayed, and a few frames from each customer’s stream could be sent to a service to detect any immediately visible impermissible behaviors using computer vision techniques. Since ML is not yet a perfect science and we don’t want to accidentally end a very lovely visit with a very ugly cat (for example), the customer on the other end would be informed of the impermissible behavior and asked if they want to continue the call, rather than the potential offender automatically being kicked.
Finally, there could be malicious software piggybacked on the video stream. Preventing this would require an in-depth understanding of the protocols, and in general, we can trust web browsers and libraries to have that expertise. We could help to mitigate these risks by checking the client’s browser version, and prompting them to update (and instructing them as to how) if there is a streaming-related vulnerability.
In general, all technologies needed for this application already exist and are well established. The infrastructure needed to run it is relatively inexpensive and can be virtualized onto commodity hardware. Video streaming capability is built into all modern web browsers, and there are many APIs to simplify the task. Given that the workload will be focused on the client, this could scale up easily, and letting users control what they want to talk about while programmatically allowing them to widen their search pool also means that this would be effective with very few initial customers. Revenue is beyond the scope of this discussion, but in an ideal situation, we would like to provide this as a free service to anyone who needs it.