Skynet is best thought of as a single shared operating system for the Internet. All files and applications exist in the same global space, and MySky is a technology we are rolling out to make the most of this shared technology.
In the simplest sense, MySky is a decentralized identity protocol that gives users their own empire of data within Skynet. Everything that happens inside of that empire is under the control of the user, but it can also be visited by anyone else and shared around freely.
The true power of MySky lies in the way it facilitates sharing data between users and applications. MySky provides a standard for declaring data in a way that makes it easy for anyone in the world to discover that data. At the same time, it provides standards for protecting that data, ensuring only data which is meant to be found is discoverable by others.
Finally, MySky provides simple yet powerful tooling that enables applications to make use of the same data. For example, the profile information of a user like their preferred name and avatar can be placed in a shared folder, and then safely used and updated by all of the user’s applications. This tooling extends to any type of data.
At its core, MySky is a decentralized identity protocol. It is a single sign-in that can be re-used across every application. In some ways, it’s similar to the ‘Sign in with Google’ button, except instead of Google owning your identity getting information about every app you use, you own your identity and all of the associated personal information.
We’ve structured MySky so that it works more like logging into your phone than logging onto the Internet. On your phone, once you’ve logged in you can use any of your applications, and you don’t have to keep logging in over and over. The Internet should work the same way, once you’ve logged into your identity in one place, it should just automatically load everywhere else as well.
Fully centralized websites are free to use MySky just for authentication, the same way that they would use a ‘Sign in with Google’ button. But if they want, they can also leverage MySky to make use of the user’s cloud storage. Websites and applications can save and load data through MySky, at no cost to the application owner. This includes access to both private areas specific to the application, and shared areas that are used by many applications.
MySky is careful with the user’s data, ensuring that applications are only allowed to see the data that the user wants them to see, while also ensuring that in most cases the user does not need to be asked whether or not an application can get permissions.
MySky divides the user’s data into “data domains”. Applications request access to view data one domain at a time. Most typically, an application will be requesting access to a data domain that matches its web domain. For example, a website living at the web domain “neopets.com” will want access to the data domain that is also named “neopets.com”.
By default, MySky will automatically grant access if the data domain requested by the application matches the web domain of the application. This means that in most cases — including cases involving shared data — the user does not need to be notified that an application is gaining access to their data. The application lives entirely in the domain where it belongs.
If for some reason the application needs access to another data domain, for example “neopetsimproved.com” wants to access the data domain of “neopets.com”, the user will be notified, and have a chance to deny access. This process also works similarly to a phone, with the user getting a pop-up informing them of the permissions request.
Data Access Controllers
Applications are generally not intended to share data directly. There are a number of challenges that go with direct data sharing. Having developers coordinate around a shared piece of data is much like herding cats: everyone wants to use their own data format and a single bug introduced by one developer can corrupt the data for everyone. A bigger issue is that users have to be asked for permission every time an application joins a shared data space. As we’ve seen both on the Internet with ‘agree to the terms of service’ buttons and on phones with ‘let this application access all sorts of data including data it has no business accessing’ buttons, if a user gets used to agreeing to things, they will keep agreeing even in unsafe situations.
On Skynet, shared data should be manged through ‘Data Access Controllers’, or DACs. A data access controller is a full web application whose entire job is to manage a particular piece of shared data. For example, a user’s profile information may be managed by a DAC at “user-profiles.hns”. Following the permissions conventions established earlier, this means that the DAC has full control over all data in the data domain named “user-profiles.hns”, and that’s where the DAC can store things like the user’s preferred handle, their avatar, preferred pronouns, any other common profile information.
The DAC then creates an API that other applications can use to access the data. The API may have calls like
getAvatar(). When some other application wants access to the user’s profile information, they make API calls to the DAC, and are restricted to only accessing and changing what the DAC API enables.
The DAC is more or less acting as a gatekeeper of the shared data. Because the DAC is the only application with access to the actual raw data, the user doesn’t need to worry about bugs in applications corrupting their common data. This also means that new applications do not need to ask the user for permission when using the shared data — the DAC gets permission automatically because of its web domain, and applications can permissionlessly use any API exposed by the DAC.
The Discoverable Filesystem
Skynet is meant to replace the existing Internet with one where users control all of the data. And the most exciting part of the Internet is the ability to explore and discover things that have been created by others.
To facilitate exploration, every user is given what we call a “discoverable” filesystem. Any data in the discoverable areas of a user’s file system is exposed to the entire world. This is exciting for content that is meant to be seen by others. Examples can include complex works like blog posts and paintings, but examples can also include simple actions such as upvotes.
Every data domain has a discoverable area. When an application is given access to a data domain, they can write freely to the discoverable area of the data domain and be confident that the data will be visible to others.
A key element of discoverable data is that it does not need to be shared by the user. When data is published to the discoverable area, it can be found automatically by other users, other applications, and even automated tools like web crawlers. All you need to know to see a user’s discoverable data is their UserID.
The Hidden Filesystem
While discoverable data is easily the most powerful part of Skynet, it can also be useful to store private data in the cloud. The hidden filesystem functions much like the discoverable filesystem — any application with access to a data domain can write to the hidden areas of that data domain.
Unlike the discoverable areas however, hidden data cannot be found by other people. Data is both encrypted so that other users cannot read it, and also obfuscated so that other users cannot tell who owns the data even if they find that data. Multiple files in the same hidden area cannot be connected together. In this way, hidden files work a bit like the Zcash shielded pool. Everyone can see that a pile of files exists, but nobody can tell which files belong to which accounts.
If the user chooses, they can share read access of subsets of their hidden filesystem with other users. For example, a Skynet based version of DropBox can enable a user to share a private folder with another user.
One of the biggest advantages of MySky is the customization that it provides to users. Users have full control over both the code that is used to generate their seed, and also over the code that is used to grant permission to other applications.
On the seed generation side, the default generates a seed for the user. But the user may already have a seed that they prefer to use. Or the user may want to log into MySky using some other application like Metamask, or even Google.
We really like the default permissions setup of MySky, but there may be reasons that a user wants different behaviors. For example, the user may be interested in using a centralized permissions manager to automatically allow certified applications to get permission to certain data domains, and automatically block known malicious applications from gaining any access to user data at all.
First Party Support
We’re big believers in the data model provided by MySky, and we will be shifting all of our first-party tooling, including
skynet-js, to be MySky oriented. There will be a transition period, but after the transition period we will be expecting all applications to log into MySky to perform data operations on Skynet. We will be providing legacy support for some of the more popular identity solutions already in use today, for example SkyID.
One of the big reasons we want to move all data operations to MySky is that MySky can ensure the user is connected to the right portal. When you upload data to Skynet, that data is only going to last if the uploader is connected to a portal that will continue pinning the data. If the user hasn’t logged in anywhere, the data may be going to a free portal that deletes data with some regularity. But if the user is logged into MySky, MySky can ensure that the data is going to the user’s preferred portal, and that anything will be pinned according to the user’s preferences.
We realize that this is going to be a pretty major shift for many of our already established applications, and it’s not a step that we take lightly. But we also believe that the power of the permissions system, the DAC, the discoverable data areas, and the hidden data areas all more than justify this transition.
MySky is a better way to develop the decentralized web. It gives more control to the user, more convenience to application developers, and better coordination between applications.