Memento protocol

[hvdsomp]

When it comes to resource versioning, it seems appropriate that braid would reference RFC7089: HTTP Framework for Time-Based Access to Resource States -- Memento.

[toomim]

Yeah, that would be a good idea, thanks!

I've looked into Memento a bit, and the first big blocker is that it represents time using a computer's local time. Unfortunately, that doesn't work for synchronization over a distributed network, because time becomes relative, and you can't rely on clocks. Instead, you need to construct a partial order of events.

I other words, Memento models time like:

  o  - 4:38pm June 4rd 2023
  |
  o - 11:30am July 2nd 2023
  |
  o - 2:02pm August 1 2023
  |
  v

But for distributed sync, we need something like:

        o - x35
       / \
h3u - o   o - 7bx
       \ /
        o - 73h

In the long run, though, we'd like to be able to support all the features we need for versioning and time in HTTP. For instance, we want to support local times as time identifiers too, so this works in Braid:

        o - 11:30am July 1 2023
       / \
h3u - o   o - 8:32pm July 9 2023
       \ /
        o - 10:55am August 4 2023

There might be useful features in Memento for history representations that we don't have in Braid, and should consider merging in. What do you think?

[toomim]

^ Updated my comment above

[hvdsomp]

@toomim I do understand the difference in perspective. Before I share some ideas re how Memento could still be used in relation to braid, I have a question: While version identifiers are crucial in braid, is it safe to assume that the datetimes of these versions are available too?

[hvdsomp]

I had a look at the HTTP Resource Versioning I-D and was wondering whether the combination of two existing headers - memento-datetime and eTag - could be re-purposed to identify versions. The I-D introduces the Version header (in responses) for this purpose.

To request a version, the combination of the existing accept-datetime and a to-be-defined accept-eTag might be an alternative to the Version header (in requests).

An interesting result of this approach would be the ability to issue requests with only accept-datetime or only accept-eTag to systems that support both. Such requests could result in HTTP 300 Multiple Choices responses with, respectively:

• a choice of versions with the same memento-datetime yet different eTags
• a choice of versions with the same eTag yet different memento-datetime

I see no alternative in existing approaches to the proposed Parent header.

As a side note regarding the proposed Version header: it feels like there should be an Accept-Version for requests and a Version header for responses.

[toomim]

To your old question:

While version identifiers are crucial in braid, is it safe to assume that the datetimes of these versions are available too?

I don't think this is safe to assume. I'm aware of at least a few collaborative text editors that don't store datetime timestamps for the edits.

As for your idea of combining etag with memento-datetime, I don't see how you can combine those to get a version.

The issue with etag is that it identifies unique contents, not time. The issue with memento-datetime is that it supports only linear (clock) time. Are you suggesting that we could write a function version(etag, datetime) that gives us the same functionality as a version, supporting a DAG of time? I'm not sure how to write that function.

As a side note regarding the proposed Version header: it feels like there should be an Accept-Version for requests and a Version header for responses.

Yeah, this is a common feeling, but I haven't seen a good reason for it, and it sure seems a lot simpler and more sensible to use the same header. I'd love to hear a good reason for it.

One issue with Accept-* is that it typically specifies a ranked preference list of things that it accepts. But in this case, we are requesting a specific version. It makes sense to say "GET Version X" rather than "GET, and I accept versions X, Y, Z" when we really just want to GET X.