Logo

Wildland is a collection of protocols, conventions, software, and (in the not so distant future) a marketplace for leasing storage. All these pieces work together with one goal in mind: to decouple the user’s data from the underlying infrastructure and free them from dependence on online service providers. Is that too vague? Or maybe we’ve piqued your curiosity and you want to find out more about Golem Foundation’s main project? Here’s 10 things you should know about Wildland: where it is today and where it’s heading.

1. Wildland’s high-level rationale

Wildland is our response to the problems of the modern Web.

The development of consumer IT technology took a wrong path over the last decade. Most people rarely use file systems anymore. They don’t interact with raw data. Instead, they have become more and more dependent on various on-line services, which are provided to them by corporate, centralized entities whose goals do not align with the users’ interests.

These services may be convenient to the user, and quite often are free to use, but they come along with strings attached. The loss of privacy inherent to online services is a well-known issue. So is the monetization of users’ online behavior. What is not acknowledged often enough however, is that service providers have an almost unlimited power to deny access to their services, for whatever reason they choose to include in their policies.

Thus, users of modern on-line services have very limited agency, only indirect access to most of their data, and can be cut off from services without a warning. Wildland aims to change all of that. Our ultimate goal is to create a future in which it’s the user, and not the service provider, who is a digital sovereign.

To achieve this goal Wildland completely redesigns data management, by switching from the service-oriented to the data-oriented paradigm, and giving individuals explicit control over their choice of data storage infrastructure.

2. Self-defined containers – Wildland’s building blocks

Wildland uses a triple-layer architecture. The top-most layer is the information layer, where the user has access to all her files. For most users, this will be the only Wildland layer with which they will interact directly. Self-defined data containers provide the building blocks for this layer. As Joanna Rutkowska, Wildland’s chief architect explains, “Wildland containers are similar to Docker containers, except that dockers are for code, and Wildland containers can store any type of information”. What makes Wildland containers truly unique, however, is that they are self-defined.

Every Wildland container has a manifest attached to it. The manifest defines the owner of the container, a list of its contents, various access rights, the backend on which the container is stored, and the various paths through which the container can be accessed.

Unlike most files systems Wildland doesn’t restrict users to only one access-path to their information. To the contrary, it encourages the user to define as many paths to her data as she finds useful. This makes paths in Wildland similar to tags and lets users organize their knowledge in multiple ways. For example, the container which contains the epub version of the Anarchy, State and Utopia by Robert Nozick, could be addressed by a user with the following paths:

.../data/books/titles/Anarchy
.../actor/humans/Robert Nozick
.../topics/politics/libertarianism

The uniqueness of Wildland’s approach to addressing lies in the fact that all those paths are equally valid. This approach allows for the level of multi-categorization which is not available in any other file management system. With Wildland you can create a container, mount it to an existing directory structure, and navigate to it using different paths listed in the manifest. A Wildland container can be hosted in parallel on a local hard drive and some cloud storage bucket. And for each backend, you can define different access policies.

Put together, the user’s containers form what we call an individual “Forest of Knowledge”. This forest corresponds to a non-hierarchical namespace. Browsing this namespace does not require the use of any specific user interface: users can navigate through their forests using Finder, Nautilus, Dolphin, Midnight Commander, a terminal, or any other file manager.

In Wildland individual forests are identified by UIDs (pubkeys), and users can have multiple forests, each identified by a different pubkey. A user can set up a different forest for every device she owns – one for her laptop, another for her desktop, yet another one for her tablet – or for different use cases: work, private, etc. This allows for a compartmentalization of data that many users should find very useful.

3. Wildland comes with bottom-up directories

Wildland also allows users to share part of their forest (i.e. specific containers) with other users.

Making containers residing in remote forests available to other users required the team to come up with some sort of a lookup system. This is a very challenging problem.

Most systems that facilitate resource addressing in vast networks rely on centralization. This is most obvious in the case of the Domain Name System (DNS), which ultimately relies on a small number of root name servers. But as Joanna explains, “We do not want any centralization in our system. Even the Ethereum Name Service is too centralized for us”. Instead of relying on a centralized hierarchical database or a set of smart contracts, Wildland implements a novel notion of bottom-up directories.

Wildland’s lookup system uses “cascading addressing” and “bridge manifests”. A bridge manifest is a container that stores information about another user’s ID. Specifically, it contains her pubkey. When a Wildland client encounters such a container on its path, it realizes that it needs to “jump” to a forest belonging to another user.

Take as an example the following Wildland address:

wildland:pubkey1:path1:path2

Wildland: is a protocol identifier, similar to HTTPS, FTP, etc.

The pubkey1 identifies a forest belonging to a specific user.

The pubkey1:path1 points to a specific container in the pubkey1 user’s forest. This container contains a pubkey that belongs to another user and identifies her forest (pubkey2).

The pubkey1:path1 container is an example of a bridge manifest. It informs the agent who parses the address, that it needs to jump to a forest belonging to the pubkey2 user. Thanks to the information contained in this bridge manifest, a Wildland agent knows that path2 in our example points to a container that resides in the pubkey2 user’s forest.

This process of cascading addressing allows for the creation of bottom-up directories. After all, the pubkey1 user can be seen as a “directory”, which lets others find the pubkey2 user. The most interesting feature of this lookup system is that it does not rely on any centralized logic. There may be many different directories, established by various users and organizations. The Wildland lookup system is built on a bottom-up principle. This should explain why the Golem Foundation team is so fond of the names relating to naturally-growing phenomena such as forests and other forms of wildlife.

4. Wildland is backend agnostic

Organizing knowledge is one thing. Storing data that provides the basis for our knowledge is another thing altogether, and it comes with its own set of problems. As Joanna explains, “We see infrastructure as a necessary evil. In the ideal, Platonic world, we would only have information.” Unfortunately, as it is right now, we have to store the information somewhere, which in our digital world means putting our files on some kind of hard drive. Hence, underneath the Forest of Knowledge, rests Wildland’s infrastructure layer.

The infrastructure layer is where the users’ containers are stored. Wildland does not rely on one specific backend. The containers can be stored in the user’s local file system, in network-attached storage, or some kind of cloud storage service. Wildland is designed in such a way as to make the containers easily movable between different infrastructures. By keeping all the meta-information about the container in the container itself, Wildland effectively “unsticks” the container from the infrastructure.

Thanks to this approach, “today my container can be stored on Amazon S3, next month on some Google Cloud server, and later somewhere else. The fact that containers are self-defined means that there is no need to update the address contained in the manifest”, Joanna explains.

5. Wildland is constantly evolving

Wildland is still in its early stages. But it’s already growing. June saw the release of the first Wildland client and in September the Wildland client 0.2 came along. The release brought new backends, adding a new SSHFS backend that allows for hosting data on a remote host via SSH, introduced several new improvements, and, amongst others, S3 backend optimization. In the short term, the team aims to improve Wildland in three key areas: make it easier to use (software, UX, adding the Ethereum-based marketplace), make it faster as well as more universal. This is possible thanks to the talented team working on Wildland. But as any open source project, Wildland is also open to the contributions of the community. You can contribute by testing and reporting any bugs, resolving issues, expanding or improving the Wildland docs - a handy guide for community contributions is available here.

6. Wildland plans to make backend leasing easy through tokenomics

As we just mentioned, among the team’s main goals is making Wildland easier to use - and one of the things this applies to is backend leasing. At the moment, in order to move her files from one cloud storage to another, a user needs to have accounts with two separate cloud providers. Setting them up is not always easy, quite often the action requires familiarizing yourself with the relevant technical documentation, and it usually involves a payment that is processed by a third party.

This problem is solved in Wildland by its lowest layer, the marketplace. The marketplace is where the contracts for storage (and further down the line data processing) will take place. It’s here that the user acquires credentials necessary to use the infrastructure offered by providers. One of the many unique features of the project is that in Wildland this transaction will be automated.

Transactions in Wildland are to be conducted using an Ethereum based smart-contract (the so-called Unified Payment System, or UPS for short). There are two parties to such a contract: a user who is looking for storage space, and a provider. Users will not interact directly with smart contracts, but will be instead using automated agents working on their behalf.

Every provider will register themselves in a smart contract. Their offer will be then cryptographically signed and listed among the offers of other providers in a publicly accessible Wildland container.

In this model, to find suitable storage for the user, the agent matches the user’s requirements specified in her manifest with offers listed in the service aggregator container. Once the agent finds an offer matching the needs of the user, it submits a transaction to the UPS smart contract with the appropriate payment. If the provider accepts the transaction, they collect the payment and publish the encrypted credentials on a blockchain. Those credentials are then used by the user to access the backend.

7. Wildland aims to bring automation to the people, thanks to hooks

In the current implementation of Wildland, a container is like a directory that is stored somewhere. In the future, Golem Foundation would like to add “hooks” to Wildland containers.

Think about the hooks as lambda functions – simple instructions performing small tasks for the user. Imagine a small Python script that gathers headlines from your favorite websites through https, downloads them onto your hard drive, and generates a PDF file that then rests in a container. With a small hook, you can turn your container into your press briefing agent.

As Joanna acknowledges, all this can be done today using a Docker container. “But to accomplish this simple task you need to set up an account on some cloud storage services, you need to have some DevOps skills, etc. In our model, all you need is a short Python script. We do not expect users to write their own scripts, of course. We want them to use scripts they have found on GitHub. Or even better, that they have downloaded from something akin to a “hook store”. What matters is that the script they have acquired will be running inside a container that is being controlled by the users themselves. In this way, we will bring automation to regular people. Automation that is controlled by the people.”

8. Wildland wants to offer multi-user use cases

Wildland architecture also allows for the future of creating decentralized and user-controlled social networking apps. Joanna explains this with the example of Facebook Events – a Facebook feature that lets users find out what’s going on in their communities and keep track of who’s going where. The feature as it is implemented on Facebook has many obvious problems relating to privacy, monetization, denial of service, etc. In Wildland, the same functionality will be possible to achieve without relying on a centralized server or even one common infrastructure. After all, Wildland users can expose their containers to other users via different backends – IPFS, S3, Google Cloud, and so on.

Joanna explains: “Users will be able to sign up for a forest set up by some social club, for example, Jazz Lovers Warsaw. The trees in this forest would represent individual users who signed up for this club. The club will list the events that made be of interest to the members of this group in a container that is accessible to all of them. We can have a simple Python script that traverses this forest and looks for which of the events listed in the container were bookmarked by various club members. In Wildland it is a simple operation, and what is important is that this whole algorithm rests in the hands of a user. No centralized entity is needed.”

9. Wildland’s team has ideas for economic sustainability

Wildland has many original features that users may find useful. The question is can this novel ecosystem be nurtured sustainably? Decentralized projects face severe governance issues. Two problems are especially important here: who should have the right to decide on questions related to the organization, and how to encourage someone who has this right to exercise it in practice.

Wildland will try to solve these problems with market measures – a combination of the already-outlined Unified Payment System, as well as the so-called User-Defined Organization.

Three key actors will interact with each other in Wildland: users, providers, and builders (developers who work on projects that make Wildland more attractive to users and providers, like e.g. apps or hooks). As previously noted, all transactions that take place in Wildland will be conducted with the use of a smart contract. In practice, this whole process would work like this: Wildland will use some kind of a stablecoin for payments. Every payment made for using the services (like file hosting or data processing) will be divided into three parts. Most of this payment will go to the provider. The rest of it will be divided into two parts.

The first of the remaining parts will be converted into GLM, Golem’s native token.The GLM will be then permanently removed from the system and the corresponding number of non-tradable Proof of Usage tokens will be generated. These tokens will be then allocated to the party that initialized the transaction. The rest of the payment will form the so-called “build fee” and will be allocated into a “build fund”.

This means that the more somebody will use Wildland’s services, the more Proof of Usage tokens they will be rewarded with, and the more decision power they will gain.

This power will allow the holders of the Proof of Usage tokens to decide on how the funds collected from the build fees are to be spent and to participate in Wildland’s User-Defined Organization. This complex process will ensure that the heaviest users will have the strongest influence on Wildland’s future development.

10. Wildland is hiring

As you may have gathered from the first nine things we’ve mentioned, Wildland is an ambitious project, run by an ambitious team. With the pace of development picking up there comes a need for expanding the team. If you’re somebody who’d like to work on an interesting project, built around cutting-edge technologies, and believe in open source projects, you may be just the right fit. You can check out current open positions here. At Golem Foundation, we strive to be an equal opportunity employer, so women and minorities are encouraged to apply. Remote work is possible, and we offer a competitive salary, including additional incentives. And if you don’t see yourself matching any of the current job descriptions but believe in our project, please send us an email with your CV attached to join@wildland.io and share your thoughts on Wildland. We are always interested in connecting with talented and motivated people who share our vision.