Why filenames instead of rolenames in snapshot?

Previously, we used to allow metadata files nested inside directories, which explains the following text in the specification:

   METAFILES is an object whose format is the following:

       { METAPATH : {
             "version" : VERSION,
             ("length" : LENGTH,)
             ("hashes" : HASHES) }
         , ...
       }

   METAPATH is the file path of the metadata on the repository relative to the
   metadata base URL. For snapshot.json, these are top-level targets metadata
   and delegated targets metadata.

However, I don’t think we need METAPATH anymore. Instead, all we need is to list valid targets rolenames instead, correct?

[jku]

After implementing both client and some repo side tools, I still ask the question in the title… Even though all my work has been completely based on normal files, I’ve never had any benefit from the meta keys being filenames. Instead I have had to add code like filename = f"{role}.{ext}" in places that logically should not know about the specific file format, let alone the file extension that is used.

[lukpueh]

… do we expect a repository to host the same metadata in different data transport formats?

Probably not. It’s just something to think through. Should the client provide a setting for the “role name to metadata filename” conversion? Or should it be inferred from the root metadata payload type? Etc…

Btw. we don’t only use METAPATH in snapshot but also in timestamp, but that probably doesn’t change anything about the argument. Just something to keep in mind.

Also, in Uptane, the notion of files is altogether problematic, and as much as we can avoid details of filesystems, the better.

That makes sense, although that could also be seen as argument for something more generic like URIs, but not necessarily less specific?