# Container

A Data Container is a fundamental concept in Wildland. It roughly resembles a familiar notion of a folder or volume in traditional operating systems (although they might also represent a single file).

A container stores user data. These data are physically stored on one or more storage backends, allowing replication if needed, potentially on heterogenic storage infrastructures.

# Container Properties & Descriptors

Each container has a number of properties. They can be grouped into 3 sections:

  1. The metadata section, which includes the container paths, type (file or directory) and owner ID.
  2. The storage section, which is a list of one or more storage manifests.
  3. The container data encryption key, used by the DFS module to expose the decrypted filesystem to the user.

# Descriptor encryption

Each of these sections (including individual storage manifests) might be encrypted.

# Paths

Each container claims one or more paths within the user forest (see below), which indicates at what mount points it is to be exposed to the user. One container can be exposed under more than one path within the filesystem, e.g. /photos/My Special Event and /timeline/2022/03/13.

More than one container can claim the same path, e.g. another container can claim /photos/My Special Event or parts of the path, e.g.: /photos/My Special Event/videos.

In such case of overlapping containers, the user should be exposed to the union of the files from both containers.

# The Multi-path concept & applications

As Wildland containers can claim multiple file system paths, a traditional file system concept can be used as a common denominator to expose information from multiple sources and in muliple contexts in a consistent way.

Because more than one container can claim the same file system path, it is possible

# Concatenation of two namespaces

TODO: this section needs more design work.

  • @-suffix for containers and bridges
  • First @ character within a forest means a container or a bridge
  • Why the same symbol for both containers and bridges (b/c bridge is a special type of container, OTOH would be nice to have a visual alert that one leaves a forest?)

# Storages

A Container can have one or more storage backends defined. Wildland assumes that all the storages represent the same data.

Wildland tries to mount the firest storage, but if it fails -- for whatever reason -- it continues throught the list of storages and tries to mount the next one, and so on, until it succeeds.

The Wildland client does not check if all the storages do indeed contain the same data, nor does it try to resolve any conflicts which might arise in the case of them not containing the same data. It is assumed that the synchronizing of the storages is done externally to the core Wildland client, using such means as the Storage Syncer.