4 ms·

Sorry I read the page and I found it very vague. Pretty graphics and lot of white space for not much meat. Basically, looks like the command pattern implement

by keyle 6y ago

Sorry I read the page and I found it very vague. Pretty graphics and lot of white space for not much meat. Basically, looks like the command pattern implemented with signed token for every time you read, you must mutate the 'chain' or array of information. Am I close?

owenmarshall 6y ago
C-f Merkle It took quite a bit of time to get there. https://en.m.wikipedia.org/wiki/Merkle_tree https://en.m.wikipedia.org/wiki/Merkle_tree
droptical 6y ago
Many thanks for the feedback on the site, perhaps we need to get some more dense technical details either on there directly or adding to the existing docs on the github repo. Command pattern is definitely one pattern we've seen these tamper-evident logs applied to; you can easily imagine a system where, say, config update "commands" are packaged off and written to a TE log, and then workers apply those commands to a system if and only if they are convinced that the commands were properly logged. If the admins/command-workers/auditors etc. can all prove they're looking at the same set of logged commands (which is the property that these tamper-evident logs are intended to provide), then you have a reliable and tamper-evident audit trail of all changes to your system. There are a bunch of other scenarios we think these things might be useful for too, and we're trying to explore (and help others explore) these and provide mechanisms for reasoning about the properties of such systems. [Disclaimer: I work on CT, Trillian, and other related projects]
- jacques_chester 6y ago
  > Command pattern is definitely one pattern we've seen these tamper-evident logs applied to; you can easily imagine a system where, say, config update "commands" are packaged off and written to a TE log, and then workers apply those commands to a system if and only if they are convinced that the commands were properly logged. Tip: call it LogOps and engage in an exercise-yard shiv-fight with GitOps folks. I prefer to think of both as examples of WAL or intent logs. It's a useful pattern and it's nice to have a narrowly-focused tool for it.

by keyle 6y ago

owenmarshall 6y ago

C-f Merkle It took quite a bit of time to get there. https://en.m.wikipedia.org/wiki/Merkle_tree https://en.m.wikipedia.org/wiki/Merkle_tree

droptical 6y ago

Many thanks for the feedback on the site, perhaps we need to get some more dense technical details either on there directly or adding to the existing docs on the github repo. Command pattern is definitely one pattern we've seen these tamper-evident logs applied to; you can easily imagine a system where, say, config update "commands" are packaged off and written to a TE log, and then workers apply those commands to a system if and only if they are convinced that the commands were properly logged. If the admins/command-workers/auditors etc. can all prove they're looking at the same set of logged commands (which is the property that these tamper-evident logs are intended to provide), then you have a reliable and tamper-evident audit trail of all changes to your system. There are a bunch of other scenarios we think these things might be useful for too, and we're trying to explore (and help others explore) these and provide mechanisms for reasoning about the properties of such systems. [Disclaimer: I work on CT, Trillian, and other related projects]

jacques_chester 6y ago
> Command pattern is definitely one pattern we've seen these tamper-evident logs applied to; you can easily imagine a system where, say, config update "commands" are packaged off and written to a TE log, and then workers apply those commands to a system if and only if they are convinced that the commands were properly logged. Tip: call it LogOps and engage in an exercise-yard shiv-fight with GitOps folks. I prefer to think of both as examples of WAL or intent logs. It's a useful pattern and it's nice to have a narrowly-focused tool for it.