This feels like another one of those common patterns that most apps will want in some form or another, in order to provide fields like
date_modified. It would be good to get traction on the development of this functionality to avoid many of us reinventing the wheel!
So I want to copy some things from this github issue and outline the requirements we can see emerging for this in different types of economic networks. Primarily I’m interested in knowing:
- Have others already created any of this functionality?
- Are there other types of timestamping behaviour that I’m missing?
I suspect it is best developed by a “mixin zome” that can be easily injected alongside other zomes in a DNA in order to provide the timestamping functionality as a pluggable service.
(aside:) I have also been looking for a worthwhile “mixin zome” candidate for development that has broad utility for potential HoloREA integrators. The “anchor pattern” that @artbrock told me was being used internally in some hApps was another one (we haven’t done indexes yet), but @philipbeadle wasn’t sure where to find that code (any help?) The other worthwhile avenue to explore in proofing that pattern is to get others using HoloREA zomes as mixins in their own apps. Open to all input on what to do next, but timestamping might be it.
I also think this behavior will need to be configurable as resilience / trust levels depend on the network. There are a few options that could be taken:
Trusted notary: good for trusted networks that are always available. In this case there would be a trusted autonomous agent listening on the DHT which registers timestamps when it receives new records. All other nodes use these timestamps for
Quorum time: good for untrusted networks with higher numbers of nodes. Configuration would be the number of nodes required to witness the record- each would write a timestamp, these timestamps would be averaged to get
date_modified. Configured node count is also the minimum number of nodes that need to be online for the network to operate… if fewer nodes are online, the delayed observations will throw times out.
- Countersigned time: good for smaller untrusted networks. Basically like quorum time except that we only require one other agent to be online to witness a timestamp. Also good if you’re doing offline transactions with QR codes or similar. Weakness is that partners might be able to collude by syncing clocks.
Trusted time: basically just taking people’s word for it, assign
date_createdfrom whatever creation timestamp is provided in the request.
- The 4 flavours of timestamping outlined above might be best developed as entirely separate zomes. There is no reason for all functionality to be packaged together into 1 zome with configuration options, as this would simply make the zome WASM bundle bloated with unexecuted code. But- does the timestamping method used in a DNA potentially need to be changed dynamically without every user having to update the app? Like, if you lost users and were under the threshold for quorum time, you might have to temporarily switch to countersigned time. If so, the configurable option would be needed. It’s also possible that a configurable version could be provided that simply composes methods from the other mixin zomes and wraps them in some config layer.
Suggestions & opinions:
- Zome API traits can be used to synchronise the public APIs of all mixin zomes so that they are compatible.
- The default implementations of the timestamping zomes might as well include a public API for querying record timestamps by address. Implementors who do not want a public API exposed can import standalone entry & link type definitions into their projects without importing the API function handlers, as per holo-rea/#80.
- Using the same entry & link type names for every zome is the only requirement necessary to ensure that the same helper library can be used by implementors regardless of the actual zome used. In other words, this can give us polymorphism in the behaviour of timestamp links & entries.
- The helper library API should be a pretty simple thing, something like
query_created_timestamp(Address)et al. This provides simple read / write access to timestamping info from within third-party zomes in the same DNA; where the
query_logic and the means of calling
record_depend on the “timestamping flavour” being provided. In practise, implementors would call
query_when returning record timestamps to consumers of their zome API.
- It’s likely that other stuff will be involved, I expect a signalling API standard could factor in.
record_created_timestamp(Address)may not be an exposed method; rather, the mixin zomes might expect certain events to be broadcast from the third-party zome which will trigger them to process writing the timestamps.