Feature request: Allow defining pointers to existing HTTP files

This is maybe more of a git-lfs design proposal/feature proposal issue. If there is a different venue to do those, please tell me.

So we are using git LFS to track and version scientific datasets. And it works great. We can track both metadata (as JSON files) and binary data and users can use familiar tool (git) to do so. It allows great reproducibility as well as you can store particular git hash with your computations and know that you can retrieve this later. While working more on this I realized there could be small optimization in terms of storage requirements, and also something which would help when storing large datasets on GitHub and GitLab. Namely, both of those services limit the size of files and/or repositories you can have to store large files. Which has posed some issues to us in the past but we have found some workarounds (compressing data, etc.) but I anticipate workarounds might not always be possible. So as we are currently using GitHub and GitLab to those those datasets, I would not like to hit a point when this is not possible anymore.

On the other hand, many datasets are already published publicly online in different data repositories, accessible through public HTTP. So could we extend the pointer spec to allow also:

version https://git-lfs.github.com/spec/v1
oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
size 12345
available https://example.com/file.csv
(ending \n)

So that when one would be cloning the repository, https://example.com/file.csv would be fetched instead, checked for hash, and then checked out? Pointers with available key (name just a suggestion) would not be pushed at all during committing/pushing, so this could operate without any git LFS server side component. (We could have some option that during first time this is committed, the remote URL is validated.)

This would allow us to transparently decide where to store git LFS files. For most we could store them at services like GitHub and GitLab, but in the case that any individual file hits the limit, we could easily use alternatives: or existing files available on the web, or store it in a public S3 bucket or something. While tooling and user experience would stay exactly the same.

There could be a git lfs remote-file CLI tool which you would call like:

git lfs remote-file https://example.com/file.csv local/path.csv

And would create local/path.csv pointer file, pointing to https://example.com/file.csv, storing hash and size in it, and prepare everything to be simply committed and pushed.

Related work

git LFS can already handle file:// files. Could this be expanded to handle also https files?