Holochain Forum

How to provide "time of entry authoring" automatically?

In looking at mixin zomes for entry timestamping, one of the (currently) simpler options to consider is that of “trusted time”. This ideally means generating creation timestamps on the fly, according to the time at which the user specifies the event occurred.

However, I’m not currently aware of any way of doing this within a Holochain app; since I was under the impression that Iso8601 input data had to be provided from outside the zome API, due to a need to enforce deterministic behaviour for writing entries.

Is this still accurate, or is there a simple way that I can access this parameter or have it injected by the zome callback handler at the time the request is processed?

When you say “trusted” you mean “trusted authority” rather than “implicitly trusted”, right? (Although I suppose my question doesn’t matter; you still need to somehow get the timestamp either way.) So the issue is that there’s no way to call SystemTime::now() from within a zome, right? Two options come to mind, both involving node-to-node messaging and the timestamping authority writing an entry to their source chain:

Built-in source chain header timestamps

  1. Alice asks Tom (trusted timestamper) to timestamp her content’s hash via N2N messaging.
  2. Tom writes a public source chain entry containing her hash.
  3. Tom retrieves his just-published entry and header using hdk::get_entry_result() and returns both to Alice (but only if Alice needs to incorporate his timestamp into her entry; not sure if this is part of your design).

Timestamping bot

  1. Alice asks Tom to sign/timestamp her entry hash, as before.
  2. Tom’s DNA emits a signal to a service on his device listening for such signals via WebSocket. The signal consists of Alice’s entry hash.
  3. The service checks the system time and passes it (along with the hash) to a zome function that writes/publishes the timestamp and pings Alice to let her know it’s ready.

The good thing about option 2 is that it’s async. The bad thing about it is that it’s async.

This is useful, but not what I was asking (sorry, bad naming). You’re talking firstly about what I’m calling “quorum time” and secondly about what I’m calling “trusted notary”. I would love to see those patterns implemented, especially the “online countersigning” pattern (which sounds quite complex).

It looks like for the kind of trust I’m talking about (“implicit trust”, in your words), the field I’m looking for can be found in the chain headers via get_entry_result (if there’s a more efficient method that only returns the header and only for the latest entry, lmk). But I can’t get this info until after I’ve written the record, can I?

Correct. So are you looking for a timestamp that can be incorporated directly into the entry’s content?

Yep! That’s the one

Okay, yeah, you’re right — in that case it doesn’t exist until an agent commits the entry into their source chain. I just reread my earlier response… Both examples are for the ‘trusted notary’ case. Example 1 forces the trusted notary to commit an entry right then and there, so he can get the timestamp from the header, whereas example 2 gets the notary to make a call out to a timestamping daemon on his own machine.

But if you’re asking about ‘implicit trust’, then all my incredibly clever suggestions are useless :rofl: :rofl: :rofl: :rofl: I think the simple answer is, yeah, the agent would have to pass the timestamp in from her UI along with the rest of the entry data. If her instance needs do any timestamping headlessly, it could use the signal-to-timestamping-daemon (or signal-to-UI) idea as per the second trusted notary example above.

What about this flow?

  • new request hits the zome API
  • entry is constructed and written
  • entry header is read to retrieve timestamp
  • timestamp is written to a separate entry and linked to the main entry. Timestamp is part of the link tag.
  • timestamp is injected into response data as creation_time or similar
  • response data is sent; request ends

It would necessitate an extra link read to provide creation_time when reading the record later, but I think one additional DHT operation is pretty minimal- you can skip reading the entry itself if the timestamp is written to the link tag.

It’s a good MVP, IMO. In other timestamping scenarios there are just capabilities governing who gets to write the timestamps. I’m pretty sure the retrieval logic could be generic for all cases (ie. read all linked timestamps and average them).