Expected server layout

In a TUF-protected Composer repository, we expect two URLs to be exposed:

https://repo.url/metadata
https://repo.url/targets

(These paths currently aren't configurable, but we could add that feature.)

The metadata directory is expected to contain the metadata used by TUF (like timestamp.json, snapshot.json, and so forth). This is NOT the same thing as the metadata that comprises the Composer package repository metadata (such as packages.json and its various minions). So, from here on out, I'll refer to "TUF metadata" and "Composer metadata" as distinct things.

I won't discuss the contents of the metadata directory; truth is, the plugin doesn't directly use it at all. That stuff is used only by the PHP-TUF library itself. We merely point PHP-TUF at the TUF metadata, and let it do its magic. Presumably, this directory would be generated by Rugged (or whatever the server-side implementation of TUF is).

The targets directory, on the other hand, should contain the Composer metadata files that have actually been signed by TUF. (For example, we'd expect https://repo.url/targets/packages.json to be a file we can download and check against TUF.)

BUT! You do not have to keep all distribution ZIP files for every version of every package in the targets directory. The truth about TUF seems to be that any given target is really just an identifier for a particular set of hashes embedded in a Merkle tree. The actual data being validated by those hashes could come from any ol' place.

So why, you're asking, does the Composer metadata need to be in a particular directory on the server? The answer is due to the way Composer works: it expects its metadata to be in a particular layout, and that's that – there's not much we can do to override that, apart from changing the base URL from which it downloads its metadata. Actual packages, on the other hand, are downloaded from the open Internet, so we have more leeway there.

To summarize this information, then, a TUF-protected Composer repository should look like this:

/
  metadata/
    ...TUF-generated metadata files...
  targets/
    packages.json
    ...Additional Packagist metadata files, all signed by TUF...

Remember, the server doesn't need to be physically laid out this way; the plugin, and Composer itself, merely expects this logical layout to exist.