231

DOGE Plans to Rebuild SSA Codebase in Months (www.wired.com)

submitted 3 months ago* (last edited 3 months ago) by cyrano@lemmy.dbzer0.com to c/programmer_humor@programming.dev

52 comments fedilink hide all child comments

cross-posted from: https://lemmy.world/post/27501204

you are viewing a single comment's thread
view the rest of the comments

[-] Sludgehammer@lemmy.world 35 points 3 months ago

Can't wait to hear how the blockchain will factor into this redesign.

[+] Adalast@lemmy.world -6 points 3 months ago

I mean, technically SSA data might be a legitimate use of the blockchain. I am one of the biggest opponents of the whole mess, but there are use cases for a persistent immutable data record, and social security numbers would be one of them.

[-] Vanilla_PuddinFudge@infosec.pub 33 points 3 months ago

The not-bullshit version of this already exists.

Many know it as MySQL, Postgres, etc.

Databases don't need Blockchains.

[-] dreadbeef@lemmy.dbzer0.com 1 points 3 months ago* (last edited 3 months ago)

Damn why doesn't git just use sql instead of Merkle trees I guess that's just stupid tell Linus to get to using SQLite asap!!!

But no, you're wrong. Cryptographically verifiable merkle trees are a valuable way to store changing data. Unlike your recommendations, they don't satisfy the needs of verification, which is literally a great use-case for ssns. Now I'll admit that the SSN db doesn't need to be distributed, which is the only thing a blockchain adds to that equation. But you are just flat out wrong for suggesting a sql db 😂

[-] senkora@lemmy.zip 7 points 3 months ago* (last edited 3 months ago)

You can store the Merkle trees inside of a SQLite database as extra columns attached to the data.

That way you get the benefits of a high-level query language and a robust storage layer as well as the cryptographic verification.

In fact, there is a version control system called Fossil which does exactly that:

https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

The baseline data structures for Fossil and Git are the same, modulo formatting details. Both systems manage adirected acyclic graph (DAG) of Merkle tree structured check-in objects. Check-ins are identified by a cryptographic hash of the check-in contents, and each check-in refers to its parent via the parent's hash.

The difference is that Git stores its objects as individual files in the .git folder or compressed into bespoke key/value pack-files, whereas Fossil stores its objects in a SQLite database file which provides ACID transactions and a high-level query language. This difference is more than an implementation detail. It has important practical consequences.

[…]

The SQL query capabilities of Fossil make it easier to track the changes for one particular file within a project. For example, you can easily find the complete edit history of this one document, or even the same history color-coded by committer, Both questions are simple SQL query in Fossil, with procedural code only being used to format the result for display. The same result could be obtained from Git, but because the data is in a key/value store, much more procedural code has to be written to walk the data and compute the result. And since that is a lot more work, the question is seldom asked.

[-] enumerator4829@sh.itjust.works 5 points 3 months ago

Or you know, trusted timestamps and cryptographic signatures via normal PKI. A Merkle tree isn’t worth shit legally if you can’t verify it against a trust outside of the tree.

All of the blockchain bullshit miss that part - you can create a cryptographic representation of money or contracts, but you can’t actually enforce, verify or trust anything in the real world without intermediaries. On the other hand, I can trust a certificate from a CA because there are verifiable actual real-world consequences for someone if that CA breaks legal agreements.

I’ll use a folder of actual papers, signed using a pen. Have some witnesses, make sure they have a legal stake and consequences, and you are golden.