(/discuss got dropped from CC here)

On Fri, 08 Apr 2022 04:55:01 -0700 Alex Good <alex@memoryandthought.me> wrote:
> On 08/04/22 11:12am, Kim Altintop wrote:
> > On Fri, 08 Apr 2022 09:58:10 +0100 "Fintan Halpenny" <fintan.halpenny@gmail.com> wrote:
> > > > +In both cases notifications are sent as a best effort and applications MUST NOT
> > > > +assume that the current on-disk state matches the notification.
> > >
> > > Would it at least be useful to say what the "change" action was,
> > > ie. `created`, `updated`, `deleted`? I would imagine that the
> > > `created` and `deleted` are important details, since `created` means
> > > that there is something new to look at in the state and `deleted`
> > > means that looking at the state MAY result in a reference missing, so
> > > perhaps could lead to an error if looked up.
> >
> > I mean... it may be considered incidental that both types of events are
> > technically ref updates. On the other hand, even if they weren't, I think we
> > could maintain the impression that they are.
> >
> > Which is to say:
> >
> >     'rad:git:' urn [/path/to/ref] SP old-oid SP new-oid LF
> >
> > (where oid can be the zero oid)
> >
> > might be something we would be able to support going forward.
>
> Yeah it seems almost everyone thinks that _just_ the URN is a bit too
> restrictive.
>
> My only possible concern would be if we moved away from using refs to
> store tracking config for some reason (tracking config is not replicated
> after all so there's no reason we couldn't) then this format would be
> kind of weird to implement. So maybe we use the `<urn> <old> <new>` for
> changes to a replicated identity and just `<urn>` for tracking changes?

What was the motivation for tracking changes to be events, actually? If you have
a large number of them (such as on a seed node), then iterating through the
whole set whenever you get a change notification might be prohibitive.

Since the hash here describes the configuration _blob_, I don't see a
compatibility issue. Maybe using the URN path is not so great, how about:

    urn SP peer-id SP old-oid SP new-oid LF