Include the hash of a file in its api response

[TekExplorer]

Is there an existing feature request for this?

• [X] I have searched the existing issues before opening this feature request.

Describe the feature you would like to see.

Currently, (last i checked) the file object contains the following values:

{
    "name": "configs",
    "mode": "drwxr-xr-x",
    "mode_bits": "755",
    "size": 4,
    "is_file": false,
    "is_symlink": false,
    "mimetype": "inode\/directory",
    "created_at": "2023-10-15T17:14:47+00:00",
    "modified_at": "2022-10-31T16:58:16+00:00"
},

I would like to see a sha256 or md5 hash string added to this object. this could be a good way for api users to find out if a file has changed since the last time it used the api by simply checking a local cache for the previous hash and comparing them.

It could also be a decent way to check for file renaming for those same services, by realizing that a "new file" is in fact the same file by comparing the hashes.

It could also be a good way for those same services to check if the remote download api did in fact download the correct file by, you guessed it, comparing hash strings

Describe the solution you'd like.

Add a sha256 and/or md5 hash value to the file object returned through the server files api.

The name of the value itself could be hash and could potentially be an object like:

{
    "sha256": "...",
    "md5": "...",
}

I only really need one of them (sha256?) but this makes it clear what kind of hash it is, and keeps the door open to other hashes in the future (ie. a new one comes out thats better in some way, or it becomes useful to show another type)

This could be kept behind an includes flag to avoid checking hashes unnecessarily, but I don't how how that works, nor how performant it is, so I'll leave that to whoever designs this.

Additional context to this request.

I am currently poking at creating a custom plugin/mod manager/downloader for my Featherdactyl app. This feature would help with checking if the plugin file on the server is the same one downloaded through the app. If it is, i could show an "update" button through the same service (aka modrinth or curseforge) on the file in the file manager, knowing that they did not update manually.

It may also help to ensure that the same app can check that the downloaded file was in fact correctly downloaded.

[matthewpi]

If this was going to be added it would be done via a separate endpoint per-file, not in the main response. The reasoning for this is computing checksums can take quite a long-time and should be done separately. I also dislike includes parameters, especially ones that change what content and fields are returned.

[TekExplorer]

That's perfectly acceptable to me. If its possible to get it at all (and perhaps cache it somehow?) then it makes it possible to check if files are correct. additionally, if i check only when downloading, the sha could be cached and the modified_at parameter could be used for seeing if it changed since.

then, if i dont have a cache in a different instance, i can just find out.

[devnote-dev]

I don't understand why you can't cache and compare the modified_at field as-is. It would be just as useful and doesn't require additions/changes to the API, and you can do arbitrary time comparisons if you really wanted, unlike with hashes.

[TekExplorer]

That's true. I suppose that does make this unnecessary.

Instead, could the remote download api include a hash in its response when a file is downloaded?

I believe that would be a good value add for people who care about this sort of thing, and still allows me to check hashes to ensure the correct file was downloaded to begin with.

[matthewpi]

If you are referring to downloading a file, then you should be giving the hashes to the downloader when requesting for the file to be pulled so the checksum can be properly verified rather than requesting it afterwards. This would be a lot better as files are verified right after the download (and ideally we would download them to a tmp dir, verify them, then move them to the final destination).

I don't see why you would request for a file to be downloaded, then request the checksum manually, to then verify it, so you can do what? Delete it?

---

Regardless of that, I do see the value and have thought about adding an endpoint for getting the checksum of a file, but as stated before it will be separate. You also shouldn't be using checksums to detect if a file has been updated unless you care about if the contents match another file exactly (such as verifying files against a trusted checksum). Checksums are expensive to compute, especially for large files.

[TekExplorer]

I have recently discovered a more direct use for a get hash endpoint. Turns out, Modrinth has an endpoint for finding the associated resource by file hashes! versionsFromHashes (accepts either sha1 or sha256 and i'm willing to use whatever's cheaper)

Being able to just request a hash (which can be cached until the file is changed) for each plugin/mod jar file and doing a request to modrinth would allow me to immediately see the current state of any numbers of mods/plugins; if it has an update, or displaying a contextual uninstall button.

And again, as long as the files havent changed, each subsequent request for the hash doesnt exactly need to recompute it.

To clarify, i do mean a separate endpoint as you say,

[TekExplorer]

Should i make a separate issue for a distinct hash endpoint or let it be this one?