The hidden beauty of atProtocol namespaces

Heading with title


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.

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 “”, “”, or “”, 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 “,” 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 “” 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.

A complete example of an @protocol namespace
Caption: A complete example of an atProtocol namespace. The key length can be up to 255 characters, leaving 31 spare characters based on its current composition. If you’ve seen any of our demo apps, the “namespace” variable you may find in our configuration file is actually the “App NameSpace.” This string combined with the “Key” string has a 110 UTF-7 character limit, while the “Shared With” @sign and “Data Owner” @sign both have a 55 UTF-7 character limit. Reading this namespace into English — “@alice is using the Buzz app, and she’s shared her profile picture with @bob.”

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.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Now for some Internet Optimism