←back to thread

Maybe Bluesky has "won"

(anderegg.ca)
461 points GavinAnderegg | 1 comments | 15 Nov 24 19:56 UTC | HN request time: 0s | source
Show context
Retr0id ◴[15 Nov 24 20:22 UTC] No.42150520[source]▶
> This is because the data in the network is all cryptographically signed based on what came before it. The protocol does this using the Merkle tree structure, which is also how Git stores data. The issue with this is: if you want to look at one piece of content in the system, you also need to know about everything that happened before.

This isn't quite accurate. You only need the MST blocks in the merkle path(s) back to the root, for the subset of records that you care about. For a single record, that's O(logn) blocks on average, where n is the total number of records in the repo. For a full checkout, the MST block count is ~33% of the number records in the repo, on average.

(MST = Merkle Search Tree, which is a special type of merkle tree, distinct from the one used by git - https://inria.hal.science/hal-02303490/document )

> Also, it would be great to edit posts! I believe this is tricky because of the Merkle tree structure mentioned above

It's not so tricky at the MST level, and it already happens there when you edit your bio for example. What is tricky (relatively) is figuring out how to represent post edits at the UI/UX level.

For context, I'm working on my own PDS implementation in Python, with corresponding library for working with the MST (both fairly WIP):

https://github.com/DavidBuchanan314/millipds

https://github.com/DavidBuchanan314/atmst

replies(1): >>42150602 #
adastra22 ◴[15 Nov 24 20:29 UTC] No.42150602[source]▶
Sounds like they are confusing Merkle blocks with block chain.
replies(1): >>42150643 #
1. Retr0id ◴[15 Nov 24 20:32 UTC] No.42150643[source]▶
An earlier version of the repo commit format (v2) had a "prev" field, which referenced the previous commit by hash. This is vaguely blockchain-ish in that you could follow the chain all the way back to the first commit*, but even then, you still didn't need the prior versions to verify the current version. In "repo v3", the prev field still exists but is optional, and in practice it isn't used.

*unless the repo had been "rebased"