[PATCH 4 of 4 V2] obsolete: allow cycles

[Augie Fackler]

> On Mar 23, 2017, at 6:15 PM, Jun Wu <quark at fb.com> wrote:
> 
> Excerpts from Augie Fackler's message of 2017-03-23 17:53:39 -0400:
>> On Wed, Mar 22, 2017 at 1:42 AM, Jun Wu <quark at fb.com> wrote:
>>>> As for alternatives, a correct solution needs to refer to the marker it is
>>>> replacing. Since cycles should be rare, can we record the full "replaced
>>>> marker" data inline in the new marker? In local storage, that could be an
>>> 
>>> If "markers being replaced" are explicitly recorded, you will miss remote
>>> markers that can be possibly replaced because you don't know them at the
>>> time appending a new local marker. So you end up with some "conflict
>>> resolution" logic during exchange.
>>> 
>>> That is not very different from just using the offsets - since obsstore is
>>> append-only, new markers just "replace" old ones (I don't think there is an
>>> exception that the newly added marker is intended to be replaced by a
>>> previous one when working locally). It's simpler but has the same exchange
>>> headache.
>> 
>> I wonder: could we get away from using dates by putting some kind of
>> generation number in the marker? So if a marker would create a cycle,
>> we increment its generation number relative to the previous highest
>> value in the cycle.
> 
> The problem is you don't know if a marker will create a cycle (or should
> invalidate another marker), because remote markers are unknown. If you do
> that during exchange, it makes exchange more complex.
> 
> I think that is not very different from just using the offsets.
> 
> Basically, if the new filed which is meant to be spread globally, date is
> probably the best option. If it is not meant to be spread globally, offset
> is already a decent choice, without format change. But offsets brings up
> the exchange headache.
> 
> marmoute preferred date to offsets. And I agree because I don't have good
> idea to handle the exchange headache (or I think it's better to be fully
> automatic).
> 
>> It still means a bad actor can produce a hard-to-defeat cycle (sort
>> of), but it solves the clock skew issue.
> 
> For clocks going backwards, we can detect that, say we get
> maxdate = max(m.date for m in markers), then if we are going to write a
> marker with date < maxdate, we could warn people, and/or write 
> (date+rand(0 to 1)) as a fake date. That would at least make non-exchange
> experience always expected.

Could we default to using the current timestamp, but if there’s a member of the obsmarker chain we’re about to add to with a time ahead of our clock, we do (that time + rand(0,1)) as the time? Greg, does that alleviate most of your concern around using times?

(This has the negative that in the presence of marker cycles time is somewhat a lie, but I think the overall ergonomics seem to be about right at least as a thought experiment...)