Proposal: Mark based versioning

[Liam Fitzgerald]

Versioned marks:
A versioned mark consists of a root mark %foo and a set of versions
%foo-1, %foo-2 %foo-3.

Lifecycle of versioned subscription:
- A pull-hook receives an %add poke and sends a watch to the push-hook
- The pull-hook receives its initial fact as a cage with mark %foo. It
then converts this fact to mark %foo-3 which is the mark type that is
compatible with the store.
- If the pull hook receives a fact that it cannot translate, it will
leave the subscription and begin exponential backoff, having marked
this as a broken subscription

——
~hastuc-dibtux

https://urbit.org

[joe bryan]

It seems like this could be built out of %gall's existing mark-converted subscriptions. %gall already kills the subscription if mark conversion fails; maybe the app(s) needs to be notified of the reason it was killed? The pull-hook could use that information to back off, while it's local client might just unconditionally resubscribe.

As for a mark-versioning convention, is the idea that all the versions would nest in %foo?

Thanks.

-jb

—

~master-morzod

https://urbit.org

[Liam Fitzgerald]

> As for a mark-versioning convention, is the idea that all the versions would nest in %foo?

Yes, absolutely

> It seems like this could be built out of %gall's existing mark-converted subscriptions. %gall already kills the subscription if mark conversion fails; maybe the app(s) needs to be notified of the reason it was killed? The pull-hook could use that information to back off, while it's local client might just unconditionally resubscribe.

I'm very much in favour of this given there are quite a few reasons a
subscription could be kicked (clog, manually, breach, failed mark).
Most of these have very different logic as well i.e. a kick on breach
should probably be the same as a watch nack, and a clog might want to
notify the user that this channel is being slow. Adding a 'foot' noun
to the kick sign is absolutely something we should do
——
~hastuc-dibtux

https://urbit.org

[Tacryt Socryp]

Chiming in to say that I’m also strongly in favor of attaching a “reason” for why the kick was issued.

>
> On Mar 2, 2021, at 8:02 PM, Liam Fitzgerald <liam.fi...@tlon.io> wrote:
>
> 

[Philip Monk]

I like the "all version nest in %foo" design.  It has nice ergonomics.

In this scheme, only the subscriber can downgrade.  If the publisher is ahead of the subscriber, the publisher needs to downgrade, and this has no mechanism for that.  Some applications will have subscriptions going both ways, and in that case this will only work when the versions are equal.

Of course, this is better than what's on the network now, and I wouldn't object to it being implemented.  But I think the true versioning system needs to have the subscriber request a particular version (though the publisher might respond with an older version).

> begin exponential backoff

Not generally a fan of implementing exponential backoff outside of Ames.  This isn't a leak (assuming the backoff is intermediated by nacks), but it makes you pay a repeated cost instead of a one-time cost.

On Tue, Mar 02, 2021 at 6:21 PM, Tacryt Socryp <lo...@tlon.io> wrote:

Chiming in to say that I’m also strongly in favor of attaching a “reason” for why the kick was issued.

On Mar 2, 2021, at 8:02 PM, Liam Fitzgerald <liam.fitzgerald@tlon.io> wrote:

As for a mark-versioning convention, is the idea that all the versions would nest in %foo?

Yes, absolutely

It seems like this could be built out of %gall's existing mark-converted subscriptions. %gall already kills the subscription if mark conversion fails; maybe the app(s) needs to be notified of the reason it was killed? The pull-hook could use that information to back off, while it's local client might just unconditionally resubscribe.

I'm very much in favour of this given there are quite a few reasons a subscription could be kicked (clog, manually, breach, failed mark). Most of these have very different logic as well i.e. a kick on breach should probably be the same as a watch nack, and a clog might want to notify the user that this channel is being slow. Adding a 'foot' noun to the kick sign is absolutely something we should do
——
~hastuc-dibtux

https://urbit.org

[Liam Fitzgerald]

Perhaps if the publisher is ahead, we use %watch-as and if the
subscriber is ahead, we use a manual mark conversion. Of course, this
would only work if we had the noun to describe the kick. Then, if we
can't successfully negotiate a version, we suspend the subscription
and subscribe to the remote's /version path and wait until we see a
version that we can use.
——
~hastuc-dibtux

https://urbit.org

On Thu, Mar 4, 2021 at 6:52 AM Philip Monk <phi...@tlon.io> wrote:
>
> I like the "all version nest in %foo" design. It has nice ergonomics.
>
> In this scheme, only the subscriber can downgrade. If the publisher is ahead of the subscriber, the publisher needs to downgrade, and this has no mechanism for that. Some applications will have subscriptions going both ways, and in that case this will only work when the versions are equal.
>
> Of course, this is better than what's on the network now, and I wouldn't object to it being implemented. But I think the true versioning system needs to have the subscriber request a particular version (though the publisher might respond with an older version).
>
> > begin exponential backoff
>
> Not generally a fan of implementing exponential backoff outside of Ames. This isn't a leak (assuming the backoff is intermediated by nacks), but it makes you pay a repeated cost instead of a one-time cost.
>
>
> On Tue, Mar 02, 2021 at 6:21 PM, Tacryt Socryp <lo...@tlon.io> wrote:
>>
>> Chiming in to say that I’m also strongly in favor of attaching a “reason” for why the kick was issued.
>>

>> On Mar 2, 2021, at 8:02 PM, Liam Fitzgerald <liam.fi...@tlon.io> wrote:
>>
>> As for a mark-versioning convention, is the idea that all the versions would nest in %foo?
>>
>> Yes, absolutely
>>
>> It seems like this could be built out of %gall's existing mark-converted subscriptions. %gall already kills the subscription if mark conversion fails; maybe the app(s) needs to be notified of the reason it was killed? The pull-hook could use that information to back off, while it's local client might just unconditionally resubscribe.
>>
>> I'm very much in favour of this given there are quite a few reasons a subscription could be kicked (clog, manually, breach, failed mark). Most of these have very different logic as well i.e. a kick on breach should probably be the same as a watch nack, and a clog might want to notify the user that this channel is being slow. Adding a 'foot' noun to the kick sign is absolutely something we should do
>> ——
>> ~hastuc-dibtux
>>
>> https://urbit.org
>>

>> On Wed, Mar 3, 2021 at 11:42 AM joe bryan <j...@tlon.io> wrote:
>>
>> It seems like this could be built out of %gall's existing mark-converted subscriptions. %gall already kills the subscription if mark conversion fails; maybe the app(s) needs to be notified of the reason it was killed? The pull-hook could use that information to back off, while it's local client might just unconditionally resubscribe.
>>
>> As for a mark-versioning convention, is the idea that all the versions would nest in %foo?
>>
>> Thanks.
>>
>> -jb
>>
>> —
>> ~master-morzod
>> https://urbit.org
>>