(webdev Tory) :emacs:

Built-in soft deletes are one of the reasons I like XTDB
---
RT @xtdb_com
news.ycombinator.com/item?id=3

"life when you don't have bitemporality" - @malcolmsparks


twitter.com/xtdb_com/status/15

1
Q.U.I.N.N.
@worldsendless isn't that an artifact of them using an immutable ledger
1+
(webdev Tory) :emacs:

@icedquinn Yep. A beautiful artifact of immutability. I have never seen them market that fact, but as someone who has gone to pains to implement soft-deletes in half a dozen PostGres systems after wishing we had it, this default with XTDB is nice.

1
Q.U.I.N.N.
@worldsendless the concept of files that grow forever give me issues. :cirno_help:
1
(webdev Tory) :emacs:

@icedquinn Yeah, I totally get that. But it seems like space concerns are going we way of hierarchical directory structures; that is, kids these days don't know anything about them.

1
Q.U.I.N.N.
@worldsendless you can avoid this with a "fractal cascade," ex. every thousand entries is put in a sub-chain (which in turn every thousand entries in that is a sub-sub-chain) which means the amount of data required to be stored grows significantly slower.

i'm not aware of anyone who does it though.
1+
🎓 Doc Freemo :jpf: 🇳🇱

@icedquinn

The reason this is generally not done is because the security of any one chain is only as large as the number of participants on that chain (depending on the type of validation done that may be PoW, PoS or whatever). Therefore the challenge is to ensure you dont partition your chains to the point that any one chain can be broken through a 51% attack. Regardless any partitioning at all of this nature will always be a trade off between some degree of security and efficiency (of which space efficiency is pat of that).

@worldsendless

1
Q.U.I.N.N.
@freemo @worldsendless they are the same chain. the fractal log is just a hash of the N-th checksum at that point in time which verifies that entire history from the point back (since any changes in the past would break the merkel dag etc)
1+
🎓 Doc Freemo :jpf: 🇳🇱

@icedquinn

Its not changes to the history im worried about. In a 51% attack you can effectively issue brand **new** transactionns on the side chain that can get validated when they shouldnt be. Though again there are solution.

@worldsendless

1
Q.U.I.N.N.
@freemo @worldsendless it's not really a side chain though. it's just a checkpoint of the master chain at reducing frequencies.

if you tried to shove new entries in the 1,000 log, anyone could still check that the master log actually hashes to that.
1+
🎓 Doc Freemo :jpf: 🇳🇱
Follow

@icedquinn

Ahh, well in that case yea that could work.

@worldsendless

· · 1 · 0 · 1
Q.U.I.N.N.
@freemo @worldsendless yeah. so NXT had the idea of prunable transactions which means the permanent log just proves some blob once existed, but that blob's data can be purged when the data is no longer important or if your node just doesn't care.

ardor brings in the idea of checkpointing side chains.

XTDB is somewhere around NXT but all entries are said prunable blocks. (although all bitemporality means is that there is a "created_at" and "valid_at" timer, which you can just add in any sql table :blobcatuguu:)
0
Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.

Resources

Developers

What is Mastodon?

qoto.org

More…

v3.5.19-qoto · Privacy policy