docs(castore/why-not-git): update BLAKE3 references

Use the all-caps version, like in other places of the docs.

Change-Id: I74a21f9015ba128456f6ee0b652ad12056b4e88b
Reviewed-on: https://cl.snix.dev/c/snix/+/30329
Autosubmit: Florian Klink <flokli@flokli.de>
Tested-by: besadii
Reviewed-by: Ilan Joselevich <personal@ilanjoselevich.com>
This commit is contained in:
Florian Klink 2025-04-18 20:46:49 +02:00 committed by clbot
parent 21b5c8a7b7
commit 048e9da83d

View file

@ -28,7 +28,7 @@ Extensions of the format/changes are very hard to do right, because parsers are
not aware they might be parsing something different. not aware they might be parsing something different.
The [Snix Castore Data Model][castore-data-model] uses a canonical protobuf The [Snix Castore Data Model][castore-data-model] uses a canonical protobuf
serialization, and uses the [blake3][blake3] hash of that serialization to point serialization, and uses the [BLAKE3][] hash of that serialization to point
to other `Directory` messages. to other `Directory` messages.
It's both compact and with a wide range of libraries for encoders and decoders It's both compact and with a wide range of libraries for encoders and decoders
in many programming languages. in many programming languages.
@ -41,14 +41,14 @@ payload, and then the data itself. The hash of a blob is the literal sha1sum
over all of this - which makes it something very git specific to request for. over all of this - which makes it something very git specific to request for.
The [Snix Castore Data Model][castore-data-model] simply uses the The [Snix Castore Data Model][castore-data-model] simply uses the
[blake3][blake3] hash of the literal contents when referring to a file/blob, [BLAKE3][] hash of the literal contents when referring to a file/blob,
which makes it very easy to ask other data sources for the same data, as no which makes it very easy to ask other data sources for the same data, as no
git-specific payload is included in the hash. git-specific payload is included in the hash.
This also plays very well together with things like [iroh][iroh-discussion], This also plays very well together with things like [iroh][iroh-discussion],
which plans to provide a way to substitute (large)blobs by their blake3 hash which plans to provide a way to substitute (large)blobs by their [BLAKE3][] hash
over the IPFS network. over the IPFS network.
In addition to that, [blake3][blake3] makes it possible to do In addition to that, [BLAKE3][] makes it possible to do
[verified streaming][bao], as already described in other parts of the [verified streaming][bao], as already described in other parts of the
documentation. documentation.
@ -56,10 +56,10 @@ The git tree object format uses sha1 both for references to other trees and
hashes of blobs, which isn't really a hash function to fundamentally base hashes of blobs, which isn't really a hash function to fundamentally base
everything on in 2023. everything on in 2023.
The [migration to sha256][git-sha256] also has been dead for some years now, The [migration to sha256][git-sha256] also has been dead for some years now,
and it's unclear what a "blake3" version of this would even look like. and it's unclear what a "[BLAKE3][]" version of this would even look like.
[bao]: https://github.com/oconnor663/bao [bao]: https://github.com/oconnor663/bao
[blake3]: https://github.com/BLAKE3-team/BLAKE3 [BLAKE3]: https://github.com/BLAKE3-team/BLAKE3
[castore-data-model]: {{< relref "data-model.md" >}} [castore-data-model]: {{< relref "data-model.md" >}}
[git-sha256]: https://git-scm.com/docs/hash-function-transition/ [git-sha256]: https://git-scm.com/docs/hash-function-transition/
[iroh-discussion]: https://github.com/n0-computer/iroh/discussions/707#discussioncomment-5070197 [iroh-discussion]: https://github.com/n0-computer/iroh/discussions/707#discussioncomment-5070197