Interview by Tyler McNierney
Introduction
At the surface level, the atProtocol appears to be a simple, robust software development infrastructure that magically provides a backend service for apps that are built on top of it. Beyond the list of verbs (e.g. put, getKeys), its monitoring service, and libraries that provide atProtocol functionalities, Atsign’s Internet protocol at its highest abstraction layer doesn’t really reveal too much to the software developer (and rightly so to make their programming lives easier!). Diving deeper into the atProtocol, you will soon realize that there is a lot at play, from various rounds of data encryption to device-to-cloud synchronization. Rather than absorbing the entirety of the atProtocol in one go, it’s best to begin by taking the atProtocol one step at a time. Today, we will introduce a critical piece of the atProtocol puzzle — application namespaces — through an interview with Atsign co-founders Colin Constable (CTO) and Kevin Nickels (CPO).
Tyler M: Let’s start from a big-picture perspective. What was your vision for apps that are developed on the atProtocol?
Kevin: First and foremost, we wanted apps focused on delivering new experiences that weren’t possible before the atProtocol. Rather than just repurposing old apps, we wanted developers to think differently. Part of that is predicated on the notion that all your data should be accessible through any app. We also have libraries that allow you to embed services and widgets that are available to any app (e.g. any app can add chats). Being able to inherit context as well as knowledge from other apps and using it is very important.
Colin: Since the beginning, what we wanted to do was allow people to own their data in a simple fashion, with a data model that was a little bit more human-like. If you ask a computer a question, you’ll get the correct answer every time, but if you ask a human a question, depending on who’s asking it, you’ll get a different answer. Before the atProtocol, there was no way of doing that in computer science at the protocol level. By moving this interaction down the stack (from the application layer), the Internet can effectively log into you and ask the same questions. You can then identify who’s asking you questions and give different answers. Once the atProtocol was developed, we alone couldn’t imagine what could come out of it. The reason why we’re participating in hackathons, appathons, and speaking to as many people who will listen to us is because it sparks new neurons, opens new pathways, and causes new apps to just emerge. Kevin and I find that incredibly exciting — the fact that we can create a new technology, know it’s important, and not know what amazing things somebody’s going to do with it.
Tyler M: So, what exactly is a namespace, and how is it used in software development?
Colin: A namespace is a place to put a set of strings or characters together. Most people are familiar with DNS (domain name system): for example, if you type “cnn.com”, “fox.com”, or “bbc.com”, you get news sites. But you can’t just type in “news” and expect the Internet to tell you which particular flavor of news you want. We need to create namespaces so that humans can remember the name and computers can translate it to Internet protocol. Once there is a namespace like “bbc.com,” you can reliably know that somebody owns that particular space, and it needs to be managed so that there are no clashes. For instance, you don’t want to type “bbc.com” and get sent to Amazon’s home page. That’s why they have to be unique, and we at Atsign created a new namespace with @Namespace.
Tyler M: How exactly do namespaces work with atProtocol applications?
Kevin: Ooh, my favorite! Let’s say you have an app called “spacesignal.” The goal of the app is to chat with a complete stranger that you randomly connect with. You can decide whether you really want to chat with them or not, and the entirety of those interactions live in the “spacesignal” namespace for chats. You can have another app called “attached,” which is using exactly the same backend and libraries, but is designed for intimate conversations with your significant other. Again, same backend, same libraries, but the two apps are for diametrically opposite use cases. The only differences between these applications are their namespaces and user experiences. Namespaces allow you to differentiate your data and your user experiences for widely varying things while keeping it very simple to build those applications.
Colin: The atProtocol namespace is a little bit like an iceberg. You may only see “phone@colin” in the namespace, but there are a whole bunch of things in that namespace (e.g. specifying to whom you’re giving permission for your phone number). We tried to make it as simple as possible for the developer, but behind the scenes there are a lot more complications, so a lot of engineering happened to make sure that the namespace is accurate and the right people get the right data at the right time.
Tyler M: That brings me to my final question concerning the security of atProtocol namespaces. What precautions and safety features were considered in its design?
Colin: A lot of things! The namespace is really just a pointer to data. Behind the scenes, the atProtocol relies on a key-value pair — the key is the namespace, and the value is whatever data is in that namespace (and every bit of data also has metadata!). But here’s the catch: that data that I’ve shared (my phone number if Tyler asked for it) is encrypted with Tyler’s public key. We’ve got cryptography going on here that relies on public/private key crypto as well as symmetric key encryption. So only Tyler, who I’ve shared the data with, can actually decrypt that data. If you somehow broke into my phone and looked through my data, all of that is encrypted for the individuals that I’m going to share them with. Since that data is encrypted with another set of keys, if I have 2000 connections on my atProtocol app, you’d have to break into 2001 phones to access all of it. There is in fact additional security on top of the crypto which is already incredibly difficult to break (RSA and AES are what we use), and if we come up with more security layers, we’ll add those too.
Kevin: From a namespace perspective, “phone@colin” is something that you can look up. As Colin said, there are additional things under the cover (like “phone@colin” for who) that make these namespaces polymorphic because there are different values for different combinations of “phone@colin” (e.g. “phone@colin:@tyler” or “phone@colin:@kevin”).
Tyler McNierney is a consultant at Atsign as well as a UC Berkeley student studying electrical engineering and computer science. He is a firm believer in Atsign’s mission statement and decided to remain with the company after the end of his summer internship. In his free time, Tyler M. loves to play piano, write music, and play Super Smash Bros. Ultimate on his Nintendo Switch.
Learn more about Atsign from our GitHub repo.
