@ardumont I'm tentatively assigning this to you as I think the code is yours, but feel free to reassign as needed!

Well, there are other scenarios: like us being forced to remove content for legal reasons. But note that I'm not arguing against the path-based approach. The risk exists only for path encoded using *integers*, because they're by construction relative to the object you traverse. You can have paths that contain the full-step information (e.g., a file/directory name, or a commit identifier), and those paths would be resolvable even if you lose access to intermediate objects. The problem with those kind of paths is that they are much longer than the integer-based ones. That robustness-v-compactness trade-off is the though one I was referring to.

It just occurred to me that this works (in the sense that the paths will be resolvable) only if we have all the objects in the path from the snapshot down to the pointed object, which is not something we can guarantee in general — e.g., we might have archived a repository which had missing objects in the first place.
It is all contextual information which would not make it impossible to see the final object you're pointing too. But this issue calls into question the robustness of integer-based paths for our purposes here. For instance, an fpath based on actual file/directory names will always be displayable, one based on integers will not be.
Though trade-off…

(tagging as General, while we discuss it)

Thanks for this feature request! Below you can find some additional background on what's needed to make it real.

So, good news at last! The CLA is ready, here it is: L3 . (It misses a preamble, but it's pretty short anyway without one.)
@s : Can you have a look and sign it (using your legal name) ?
Happy to answer any question you might have !

done by @olasd as part of Debian regular ingestion

Thanks!

@anlambert can you post here one example per object-type that we can use for this task?

while we're at archive.s.o homepage fiddling, it might also make sense to switch the api and browse icons, so that browse appears first
(yeah, i know, left-to-right reader bias :-P)

closing, now that all sub-tasks have been completed

OK, fair enough, I'm closing this then.
Still, please minimize the amount of documentation content that is duplicated in that help page w.r.t. docs.s.o, because keeping them in sync will become a pain soon. For instance, for identifiers, examples are fine, but for anything more in depth we should point to the detailed page on docs.s.o.

heh, nice hack :)