@SRAZKVT you of course were way ahead of me when you introduced incremental identifiers just above.
inodes as local identifier
i like the idea of calling these "inodes". i think they should be local to a representation of a directory tree, and possibly namespaced separately between files and directories.
you're right that we would need to have a reverse index mapping checksums to inodes. i actually think that's ok, because i want to explicitly check for whether the object database has this checksum yet, and insert it if not. i feel that allocating an inode is a useful way to mark this operation.
i also feel that operations upon inodes (like constructing views and/or overlays) are generally a different matter than checksums, so i feel this separation makes sense.
finally, if we generate a hash tree representation to send over the network, i feel it might make sense to also assign it similar inodes if only to make the point that it's a kind of database in itself.
problem: recycling
if we use something like SHA-3 or BLAKE3 for file hashing, our potential output space is variable, but an inode will need to be recycled at some point.
sharding into separate file and directory inode namespaces is probably a good idea, and perhaps we furthermore shard by checksum variant (since directory checksums are likely to be a subject of research, this is probably a good idea).
however, at some point, we might overflow. i suppose we could simply add the number of bits we take from the checksum + the number of bits for the file length together. we also don't need to do much more than increment the inode--it doesn't need to be a number-like object.
so perhaps in the protocol we specify that an inode is a k-bit string and we can just increment it and abort loudly if it overflows!