How we are using Wildland internally

It’s true, we do eat our own dog food. We have never shied away from the fact that we are building Wildland for ourselves and people like us. That is people who want to have control over their data, who would like to interact with it with the tools of their choice, and who are wary of being dependent on service providers. People who find the concept of files something worth preserving, and who see great value in the ability of copying, sharing, and deleting information on their own, without the involvement of third parties. So you may be wondering now how we are using Wildland internally. The answer is, for business and pleasure, of course.

Wildland as a knowledge management platform

We are using Wildland to help us organize the knowledge we have acquired during the developmental process. The Pandora forest (which we made available in read-only mode to the public with the release of the Wildland client) serves as our online repository for memos, research and progress reports, and other documents which we’ve been using internally to help us with Wildland’s development.

Superficially it may look as if Pandora is just a shared cloud bucket to which all members of the Wildland team have full (read-and-write) access. But it’s so much more than that.

First of all, Wildland uses a novel infrastructure-independent addressing system. All backends are exposed to users as one unified file system, with the infrastructure part omitted from the address. This means that if we decided to move Pandora to a different storage option (as we in fact did before opening it up to the public) we wouldn’t have to update the addresses to reflect the new data resting place. This feature allows for easy data migration and makes us less dependent on any particular storage provider or type of infrastructure.

Secondly, with Wildland we can utilize multi-categorization to manage our data. If you start browsing the Pandora forest (instructions on how you can do it are available here you will easily notice that you can gain access to data available therein through many different paths.

Let’s say for example that you would like to check what Piotr from our team has been doing lately. You can go to /persons/piotr and you will be able to see that there’s a container with his report on the current status of the macOS client dated June 30th 2021. The same report can be accessed through other paths as well. Since this is a report concerned with the client you will also find it under /clients/macos. The report has been also categorized by time, which means that you can find it under /timeline/2021/06/30. As Piotr’s report describes the current status of the project he is working on, it’s also available at /status, and being relevant to other people working on the macOS client, it can be accessed at /teams/macos-client as well. (You can find all categories under which the report has been labeled by examining the container’s manifest).

This system of multi-categorization allows for comprehensive data management that is unmatched by any other storage solution. We will write more about this feature in a separate post.

Wildland after hours

Wildland is not a dull “all work and no play” platform. You can use it just as well outside your professional workflows, and here at Golem Foundation we also utilize it for sharing non-work-related content. The Café forest serves as our “after-hours” media swap hangout.

Café differs from Pandora in two crucial ways. Firstly, it’s not publically accessible. The Café forest is owned by a group user cafe, and the user manifest is encrypted to a selected group of pubkeys (each Wildland user corresponds to a cryptographic key pair and is identified by a hash of its public key), which means that only users who have been added by the Café admin to the cafe group user can access it. In effect, this makes Café a shared private space, which only accepted members can enter (or in this case mount, browse and publish to).

Secondly, unlike Pandora, the Café does not offer users a shared storage bucket for publishing their files. This means that when users want to publish something to the Café forest, they have to do so using their own private storage. Thanks to the availability of several storage templates that cover the most popular cloud backend options, this is relatively easy, however. For example, a user might create a container that is stored in their Dropbox bucket, fill it with files they would like to share with other cafe group members, and publish it to the Café forest so that others can access it.

What do we share with each other in Café? Well, all that is shared in the Café stays in the Café, so I can only say that it’s interesting, fun, and not indexed by search engines. :-)