Path Manifests

Overview

Path manifests are a simple and optional extension for Arweave gateways, they allow users to upload a small metadata transaction (the path manifest) which maps user-definable subpaths with other Arweave transaction IDs. This allows users to create logical groupings of content, for example a directory of related files, or the files and assets that make up a web application.

Why Do You Even Need Path Manifests?

When you upload data to Arweave, it’s enveloped in a transaction. This transaction has a URL identifier that’s basically a SHA-256 hash of the transaction signature. So, it’s not exactly human-friendly, nor is it something you can customize.

Here's an example of a typical directory structure for a small web application.

index.html
about.html
js/app.js
css/style.css
assets/fonts/font.woff
assets/fonts/font.ttf
assets/img/logo.png
assets/img/icon.png

Once uploaded, css/style.css will now be addressed using an ID like XEfZIr3DOFXiKZ2I3XujAsPpvryTts2dVyr6dqrrmUm, and would be accessed using https://arweave.net/XEfZIr3DOFXiKZ2I3XujAsPpvryTts2dVyr6dqrrmUm (using arweave.net as an example gateway).

Now the developer has a problem, their code is written with references to other files, and once uploaded to Arweave, those paths will break and need updating in any code that referenced them.

In our index.html we might have a reference to our CSS, like this

<link href="css/style.css" rel="stylesheet" />

This needs to be translated to this

<link href="XEfZIr3DOFXiKZ2I3XujAsPpvryTts2dVyr6dqrrmUm" rel="stylesheet" />

Or inlined, like this

<style type="text/css">
  /* Contents of css.style.css */
</style>

This works to a point, and tools can automatically generate and update these references, or inline the content into a single file, but this gets complicated when we consider runtime references to files that aren't clear just from the original application source code (e.g. Javascript creating dynamic references to files). This is also not so useful for people, as there is nothing in the URL logically grouping files together, and there are no human readable paths and URLs.

There is also the possibility that circular dependencies can be created which cannot be resolved. If index.html is wrapped in an Arweave transaction and given an ID, about.html needs updating to point to transaction ID for index.html. If index.html also references about.html we now have a circular dependency. By changing even a single byte in either index.html or about.html to reference the others transaction ID, we need to re-sign them which changes the ID.

When uploading Arweave data using 4EVERLAND, any folder can be transformed into Manifest mode. The file names and paths will be represented in the Arweave Manifest, making it easier for developers and users to reference their content using the names used on their local file system.

Please note that Manifests must be public and unencrypted data so that they can be parsed by the Arweave gateway or 4EVERLAND nodes.