Kickstarting roadmap planning
Signed-off-by: Kim Altintop <kim@eagain.st>
---
Here's some bulletpoints about what I think should come next, not necessarily in
order of priority. For the giggles, let's see if we can flesh this out
collaboratively (yes, I have included that this should be a cob next time :)).
TODO.md | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 TODO.md
diff --git a/TODO.md b/TODO.md
new file mode 100644
index 00000000..8a680a20
--- /dev/null+++ b/TODO.md
@@ -0,0 +1,68 @@
+## Networking++* [ ] Grafting++ * [x] Interrogation+ * [ ] Request-Pull++ > Explicit initiation of mutual replication, replaces "rere"++ * [ ] Sync mode++ > TBD: user-initiated, at startup, other indicators++* [ ] NAT Traversal++ * [ ] Hole Punching++ > Requires coordination when NAT is endpoint-dependent. Coordinator nodes+ > could be designated though a DHT, but latency and churn are problematic.+ > Maybe Chord?++* [ ] Provider Cache++ > Remember `Have`s in a _k_-bucket structure acc. to local subscription and/or+ > hash value. Can answer `Want` from from cache; can locate providers based on+ > distance metric. Unclear how to perform liveness check when protocol is+ > stateful (TLS handshake).++* [ ] Gossip Membership Groups++ > Prefer peers with similar interests. Pubsub protocols (eg. gossipsub,+ > episub) are suitable for single-root routing trees, which is not quite what+ > we're after; in pubsub terms, we would have the URN as the topic, while+ > every tracking peer forms a sub-topic (to which others interested in URN may+ > or may not be subscribed). Maybe SCRIBE (Pastry) anycast?++## Replication++* [ ] Stabilization+* [ ] Optimization++ * [ ] Avoid `ls-refs` in fetch step by intercepting ACKs++ > Do not use `gitoxide`s `fetch` function, but v2 payloads directly. Will+ > require `gitoxide` to export more things.++## Identities++* [ ] Simplify verification by requiring history to be linear+* [ ] Extension points for cobs (TBD)+* [ ] Quorum overrides for personal ids++ > Cross-signing from multiple devices is inconvenient for personal ids.+ > Macaroons could be issued which allow to confirm a change using only one+ > second factor (HSM, password manager, ..).++## Collaborative Objects++* [ ] Turn this document into a CRDT+* [ ] Patches+* [ ] ACLs+* ...++## Tools & Infrastructure++* [ ] AppArch MVP+* [ ] Instrumentation (metrics)+* ...
--
2.34.1
In general, this looks good at a high-level :)
On Sun Dec 19, 2021 at 12:04 PM GMT, Kim Altintop wrote:
> Kickstarting roadmap planning>> Signed-off-by: Kim Altintop <kim@eagain.st>> --->> Here's some bulletpoints about what I think should come next, not> necessarily in> order of priority. For the giggles, let's see if we can flesh this out> collaboratively (yes, I have included that this should be a cob next> time :)).>>> TODO.md | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++> 1 file changed, 68 insertions(+)> create mode 100644 TODO.md>> diff --git a/TODO.md b/TODO.md> new file mode 100644> index 00000000..8a680a20> --- /dev/null> +++ b/TODO.md> @@ -0,0 +1,68 @@> +## Networking> +> +* [ ] Grafting> +> + * [x] Interrogation> + * [ ] Request-Pull> +> + > Explicit initiation of mutual replication, replaces "rere"> +> + * [ ] Sync mode> +> + > TBD: user-initiated, at startup, other indicators> +> +* [ ] NAT Traversal> +> + * [ ] Hole Punching> +> + > Requires coordination when NAT is endpoint-dependent. Coordinator> nodes> + > could be designated though a DHT, but latency and churn are> problematic.> + > Maybe Chord?> +> +* [ ] Provider Cache> +> + > Remember `Have`s in a _k_-bucket structure acc. to local> subscription and/or> + > hash value. Can answer `Want` from from cache; can locate providers> based on> + > distance metric. Unclear how to perform liveness check when protocol> is> + > stateful (TLS handshake).
typo:
---
- from from cache
+ from cache
---
> +> +* [ ] Gossip Membership Groups> +> + > Prefer peers with similar interests. Pubsub protocols (eg.> gossipsub,> + > episub) are suitable for single-root routing trees, which is not> quite what> + > we're after; in pubsub terms, we would have the URN as the topic,> while> + > every tracking peer forms a sub-topic (to which others interested in> URN may> + > or may not be subscribed). Maybe SCRIBE (Pastry) anycast?
Dropping a link for Pastry/SCRIBE
https://en.wikipedia.org/wiki/Pastry_(DHT) :)
> +> +## Replication> +> +* [ ] Stabilization> +* [ ] Optimization> +> + * [ ] Avoid `ls-refs` in fetch step by intercepting ACKs> +> + > Do not use `gitoxide`s `fetch` function, but v2 payloads directly.> Will> + > require `gitoxide` to export more things.> +> +## Identities> +> +* [ ] Simplify verification by requiring history to be linear> +* [ ] Extension points for cobs (TBD)
What do you mean by this?
> +* [ ] Quorum overrides for personal ids> +> + > Cross-signing from multiple devices is inconvenient for personal> ids.> + > Macaroons could be issued which allow to confirm a change using only> one> + > second factor (HSM, password manager, ..).> +> +## Collaborative Objects> +> +* [ ] Turn this document into a CRDT> +* [ ] Patches> +* [ ] ACLs> +* ...> +> +## Tools & Infrastructure> +> +* [ ] AppArch MVP
I'm wondering about the scope of "MVP" here. Currently, Alex is
working on the MVPeer which is, hopefully, enough to spin up local
setups and a seed node of our own for collaborating. But is that it?
Or should we include other portions of the AppArch RFC, such as git
daemon or CLIaaS? Maybe some of these are stretch goals and fall lower
in priority :)
> +* [ ] Instrumentation (metrics)> +* ...> --> 2.34.1
On 20/12/21 08:40am, Fintan Halpenny wrote:
> In general, this looks good at a high-level :)>> On Sun Dec 19, 2021 at 12:04 PM GMT, Kim Altintop wrote:> > Kickstarting roadmap planning> >> > Signed-off-by: Kim Altintop <kim@eagain.st>> > ---> >> > Here's some bulletpoints about what I think should come next, not> > necessarily in> > order of priority. For the giggles, let's see if we can flesh this out> > collaboratively (yes, I have included that this should be a cob next> > time :)).> >> >> > TODO.md | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++> > 1 file changed, 68 insertions(+)> > create mode 100644 TODO.md> >> > diff --git a/TODO.md b/TODO.md> > new file mode 100644> > index 00000000..8a680a20> > --- /dev/null> > +++ b/TODO.md> > @@ -0,0 +1,68 @@> > +## Networking> > +> > +* [ ] Grafting> > +> > + * [x] Interrogation> > + * [ ] Request-Pull> > +> > + > Explicit initiation of mutual replication, replaces "rere"> > +> > + * [ ] Sync mode> > +> > + > TBD: user-initiated, at startup, other indicators> > +> > +* [ ] NAT Traversal> > +> > + * [ ] Hole Punching> > +> > + > Requires coordination when NAT is endpoint-dependent. Coordinator> > nodes> > + > could be designated though a DHT, but latency and churn are> > problematic.> > + > Maybe Chord?> > +> > +* [ ] Provider Cache> > +> > + > Remember `Have`s in a _k_-bucket structure acc. to local> > subscription and/or> > + > hash value. Can answer `Want` from from cache; can locate providers> > based on> > + > distance metric. Unclear how to perform liveness check when protocol> > is> > + > stateful (TLS handshake).>> typo:> ---> - from from cache> + from cache> --->> > +> > +* [ ] Gossip Membership Groups> > +> > + > Prefer peers with similar interests. Pubsub protocols (eg.> > gossipsub,> > + > episub) are suitable for single-root routing trees, which is not> > quite what> > + > we're after; in pubsub terms, we would have the URN as the topic,> > while> > + > every tracking peer forms a sub-topic (to which others interested in> > URN may> > + > or may not be subscribed). Maybe SCRIBE (Pastry) anycast?>> Dropping a link for Pastry/SCRIBE> https://en.wikipedia.org/wiki/Pastry_(DHT) :)>> > +> > +## Replication> > +> > +* [ ] Stabilization> > +* [ ] Optimization> > +> > + * [ ] Avoid `ls-refs` in fetch step by intercepting ACKs> > +> > + > Do not use `gitoxide`s `fetch` function, but v2 payloads directly.> > Will> > + > require `gitoxide` to export more things.> > +> > +## Identities> > +> > +* [ ] Simplify verification by requiring history to be linear> > +* [ ] Extension points for cobs (TBD)>> What do you mean by this?>> > +* [ ] Quorum overrides for personal ids> > +> > + > Cross-signing from multiple devices is inconvenient for personal> > ids.> > + > Macaroons could be issued which allow to confirm a change using only> > one> > + > second factor (HSM, password manager, ..).> > +> > +## Collaborative Objects> > +> > +* [ ] Turn this document into a CRDT> > +* [ ] Patches> > +* [ ] ACLs> > +* ...> > +> > +## Tools & Infrastructure> > +> > +* [ ] AppArch MVP>> I'm wondering about the scope of "MVP" here. Currently, Alex is> working on the MVPeer which is, hopefully, enough to spin up local> setups and a seed node of our own for collaborating. But is that it?> Or should we include other portions of the AppArch RFC, such as git> daemon or CLIaaS? Maybe some of these are stretch goals and fall lower> in priority :)
To me an "MVP" here means something which is actually usable by people
who have little to no technical knowledge beyond a good grasp of git
remotes. That means that we can't be asking people to `cargo install`
things and we can't be asking people to fiddle around systemd units etc.
etc. It also means that the tooling we provide needs to be able to
produce useful messages about what is going on so that users know what
to do to fix things. To my mind then that means a few things (some of
which we have already agreed on, some of which we haven't).
- Packages for the major distros (and HomeBrew?) which install systemd
units for the peer to peer node and the git daemon, as well as the
client tooling.
- A simple way to configure "custodial peers" - particular seed nodes users
choose to host their work. We currently have no way of knowing what
those are. We could use the bootstrap nodes the p2p node is
configured with but I think this is undesirable becase a) it conflates
two separate network roles and b) it requires fiddling with systemd
unit files to configure. I think therefore we will need to decide
somewhere to store this information, an RPC to modify it, and CLI
tooling for users to talk to it.
- An implementation of the git daemon which uses the aforementioned
request-pull RPC to ensure that the project is pushed to custodial
peers. This should provide feedback to the user via their terminal as
to what is happening, which requires the request-pull RPC to provide
progress information which the git daemon can push down the pipe to
the user. Ultimately we want to be able to say things like "we tried
to push to this peer you configured but they didn't answer".
- An implementation of `git clone` for radicle URNs. This will require
taking the waiting room from the `daemon` and putting it somewhere
else.
I've nearly finished a version of `git push` which uses the "announce"
API. Most of this is just plumbing and fighting with rust async.
I think it's reasonable to suggest that by the end of 2022 users could
just do `yay -S radible-bins` and `git clone ssh://127.0.0.1:1234/<URN>`
to get a hold of a project and then `git push origin ...` to push
changes.
The thing I know least about here is packaging, probably I am
underestimating how difficult that is.
> > +* [ ] Instrumentation (metrics)> > +* ...> > --> > 2.34.1>
On Mon Dec 20, 2021 at 12:43 PM GMT, Alex Good wrote:
> On 20/12/21 08:40am, Fintan Halpenny wrote:> > In general, this looks good at a high-level :)> >> > On Sun Dec 19, 2021 at 12:04 PM GMT, Kim Altintop wrote:> > > Kickstarting roadmap planning> > >> > > Signed-off-by: Kim Altintop <kim@eagain.st>> > > ---> > >> > > Here's some bulletpoints about what I think should come next, not> > > necessarily in> > > order of priority. For the giggles, let's see if we can flesh this out> > > collaboratively (yes, I have included that this should be a cob next> > > time :)).> > >> > >> > > TODO.md | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++> > > 1 file changed, 68 insertions(+)> > > create mode 100644 TODO.md> > >> > > diff --git a/TODO.md b/TODO.md> > > new file mode 100644> > > index 00000000..8a680a20> > > --- /dev/null> > > +++ b/TODO.md> > > @@ -0,0 +1,68 @@> > > +## Networking> > > +> > > +* [ ] Grafting> > > +> > > + * [x] Interrogation> > > + * [ ] Request-Pull> > > +> > > + > Explicit initiation of mutual replication, replaces "rere"> > > +> > > + * [ ] Sync mode> > > +> > > + > TBD: user-initiated, at startup, other indicators> > > +> > > +* [ ] NAT Traversal> > > +> > > + * [ ] Hole Punching> > > +> > > + > Requires coordination when NAT is endpoint-dependent. Coordinator> > > nodes> > > + > could be designated though a DHT, but latency and churn are> > > problematic.> > > + > Maybe Chord?> > > +> > > +* [ ] Provider Cache> > > +> > > + > Remember `Have`s in a _k_-bucket structure acc. to local> > > subscription and/or> > > + > hash value. Can answer `Want` from from cache; can locate providers> > > based on> > > + > distance metric. Unclear how to perform liveness check when protocol> > > is> > > + > stateful (TLS handshake).> >> > typo:> > ---> > - from from cache> > + from cache> > ---> >> > > +> > > +* [ ] Gossip Membership Groups> > > +> > > + > Prefer peers with similar interests. Pubsub protocols (eg.> > > gossipsub,> > > + > episub) are suitable for single-root routing trees, which is not> > > quite what> > > + > we're after; in pubsub terms, we would have the URN as the topic,> > > while> > > + > every tracking peer forms a sub-topic (to which others interested in> > > URN may> > > + > or may not be subscribed). Maybe SCRIBE (Pastry) anycast?> >> > Dropping a link for Pastry/SCRIBE> > https://en.wikipedia.org/wiki/Pastry_(DHT) :)> >> > > +> > > +## Replication> > > +> > > +* [ ] Stabilization> > > +* [ ] Optimization> > > +> > > + * [ ] Avoid `ls-refs` in fetch step by intercepting ACKs> > > +> > > + > Do not use `gitoxide`s `fetch` function, but v2 payloads directly.> > > Will> > > + > require `gitoxide` to export more things.> > > +> > > +## Identities> > > +> > > +* [ ] Simplify verification by requiring history to be linear> > > +* [ ] Extension points for cobs (TBD)> >> > What do you mean by this?> >> > > +* [ ] Quorum overrides for personal ids> > > +> > > + > Cross-signing from multiple devices is inconvenient for personal> > > ids.> > > + > Macaroons could be issued which allow to confirm a change using only> > > one> > > + > second factor (HSM, password manager, ..).> > > +> > > +## Collaborative Objects> > > +> > > +* [ ] Turn this document into a CRDT> > > +* [ ] Patches> > > +* [ ] ACLs> > > +* ...> > > +> > > +## Tools & Infrastructure> > > +> > > +* [ ] AppArch MVP> >> > I'm wondering about the scope of "MVP" here. Currently, Alex is> > working on the MVPeer which is, hopefully, enough to spin up local> > setups and a seed node of our own for collaborating. But is that it?> > Or should we include other portions of the AppArch RFC, such as git> > daemon or CLIaaS? Maybe some of these are stretch goals and fall lower> > in priority :)>> To me an "MVP" here means something which is actually usable by people> who have little to no technical knowledge beyond a good grasp of git> remotes. That means that we can't be asking people to `cargo install`> things and we can't be asking people to fiddle around systemd units etc.> etc. It also means that the tooling we provide needs to be able to> produce useful messages about what is going on so that users know what> to do to fix things. To my mind then that means a few things (some of> which we have already agreed on, some of which we haven't).
I'll play the devil's advocate here and say that this sounds more like
a Most Polished Product. Your list of criteria would be great to have
but I don't think they're the minimal set for viableness. The way I
would view this is that we would aim somewhere a bit lower than those
criteria as the minimal and then work towards polishing those parts to
get to the fuller experience you're describing.
> - Packages for the major distros (and HomeBrew?) which install systemd> units for the peer to peer node and the git daemon, as well as the> client tooling.
Perhaps we could create a list of distros we'd like to initially
target, then a secondary list, and then Windows lolol. Those kind of
tasks might attract some people to contribute as well :)
> - A simple way to configure "custodial peers" - particular seed nodes> users> choose to host their work. We currently have no way of knowing what> those are. We could use the bootstrap nodes the p2p node is> configured with but I think this is undesirable becase a) it conflates> two separate network roles and b) it requires fiddling with systemd> unit files to configure. I think therefore we will need to decide> somewhere to store this information, an RPC to modify it, and CLI> tooling for users to talk to it.
Just to clarify what you mean, is this referring to functionality
similar to Upstream adding seeds on their network page? Or am I
missing the point? :)
> - An implementation of the git daemon which uses the aforementioned> request-pull RPC to ensure that the project is pushed to custodial> peers. This should provide feedback to the user via their terminal as> to what is happening, which requires the request-pull RPC to provide> progress information which the git daemon can push down the pipe to> the user. Ultimately we want to be able to say things like "we tried> to push to this peer you configured but they didn't answer".> - An implementation of `git clone` for radicle URNs. This will require> taking the waiting room from the `daemon` and putting it somewhere> else.
Ya, this makes sense to me.
> I've nearly finished a version of `git push` which uses the "announce"> API. Most of this is just plumbing and fighting with rust async.> I think it's reasonable to suggest that by the end of 2022 users could> just do `yay -S radible-bins` and `git clone ssh://127.0.0.1:1234/<URN>`> to get a hold of a project and then `git push origin ...` to push> changes.>> The thing I know least about here is packaging, probably I am> underestimating how difficult that is.>> > > +* [ ] Instrumentation (metrics)> > > +* ...> > > --> > > 2.34.1> >
On Mon, 20 Dec 2021 06:43:13 -0600 Alex Good <alex@memoryandthought.me> wrote:
> - Packages for the major distros (and HomeBrew?) which install systemd> units for the peer to peer node and the git daemon, as well as the> client tooling.
This could create quite some maintenance burden. Getting packages into the
distros proper typically requires some effort and reputation, while providing
packages outside the distro typically requires to set up some kind of
"repository", which tends to be a major pain in the neck (at least for debian
packages it is).
Perhaps we should focus on systems we use ourselves (ie. PKGSRC, Nix, MacPorts),
and see if someone steps up for other formats?
> - A simple way to configure "custodial peers" - particular seed nodes users> choose to host their work. We currently have no way of knowing what> those are. We could use the bootstrap nodes the p2p node is> configured with but I think this is undesirable becase a) it conflates> two separate network roles and b) it requires fiddling with systemd> unit files to configure. I think therefore we will need to decide> somewhere to store this information, an RPC to modify it, and CLI> tooling for users to talk to it.
Interesting. I'm not sure I agree with a), but how about GIT_DIR/config?
On Mon, 20 Dec 2021 08:40:17 +0000 "Fintan Halpenny" <fintan.halpenny@gmail.com> wrote:
> > +* [ ] Extension points for cobs (TBD)>> What do you mean by this?
I'd expect that we will want more granular "roles" once we figured out ACLs.
For example, we may want to allow some buildbot to append CI results to a patch,
yet the operator of the bot should be able to rotate keys at their leisure. So
this could be a variant of a top-level identity kind (although it doesn't
necessarily need to be discoverable), or some kind of second-level identity, or
some kind of macaroon.
Is there a high level objective we want to achieve this year? @kim the
work you're outlining seems to me to suggest that one high level
objective would be to have the networking and replication be reliable
and efficient enough that anyone can use it, does that sound right?
Another goal I've been thinking about with the AppArch stuff, and the
packaging is that we should aim for using link to be about as easy as
using SSH. You have to install some packages and secure a key, but you
don't need to know anything about the protocol operation
or how the project is built etc. unless you have unusual requirements. I
guess the identities stuff falls under this goal as well.
Is thinking in terms of these higher level goals useful or should we
stick with more concrete and tactical ones? What are other goals we
might consider?
On 03/01/22 10:53am, Kim Altintop wrote:
> On Mon, 20 Dec 2021 06:43:13 -0600 Alex Good <alex@memoryandthought.me> wrote:> > - Packages for the major distros (and HomeBrew?) which install systemd> > units for the peer to peer node and the git daemon, as well as the> > client tooling.>> This could create quite some maintenance burden. Getting packages into the> distros proper typically requires some effort and reputation, while providing> packages outside the distro typically requires to set up some kind of> "repository", which tends to be a major pain in the neck (at least for debian> packages it is).>> Perhaps we should focus on systems we use ourselves (ie. PKGSRC, Nix, MacPorts),> and see if someone steps up for other formats?
This probably makes sense. Hopefully we can get someone to step up. Most
of the Linux users I know use Ubuntue, it would be great if they can
just `apt install` and not think about anything else.
>>> > - A simple way to configure "custodial peers" - particular seed nodes users> > choose to host their work. We currently have no way of knowing what> > those are. We could use the bootstrap nodes the p2p node is> > configured with but I think this is undesirable becase a) it conflates> > two separate network roles and b) it requires fiddling with systemd> > unit files to configure. I think therefore we will need to decide> > somewhere to store this information, an RPC to modify it, and CLI> > tooling for users to talk to it.>> Interesting. I'm not sure I agree with a), but how about GIT_DIR/config?
Yeah `GIT_DIR/config` makes sense. As to a), my thinking was that we may
want to provide IPFS style public bootstrap peers which are baked into
default installations of link. These peers would not be tracking any
projects - just providing a way for people to join the hyparview
cluster. Announcing changes to them is obviously useful but if we have
some kind of request-pull API then things become a little bit tricky. I
would like to provide the user with some guarantees about what happens
when they `push` to the local git server - namely that all custodial
peers will have a `request-pull` sent to them and we will report an
error if one of the custodial peers fails to replicate. This raises a
problem if we have a non-tracking bootstrap node, we would need some way
of determining which nodes are ones we can safely ignore a replication
failure from.
On Mon Jan 3, 2022 at 10:26 AM GMT, Kim Altintop wrote:
> On Mon, 20 Dec 2021 08:40:17 +0000 "Fintan Halpenny"> <fintan.halpenny@gmail.com> wrote:> > > +* [ ] Extension points for cobs (TBD)> >> > What do you mean by this?>> I'd expect that we will want more granular "roles" once we figured out> ACLs.> For example, we may want to allow some buildbot to append CI results to> a patch,> yet the operator of the bot should be able to rotate keys at their> leisure. So> this could be a variant of a top-level identity kind (although it> doesn't> necessarily need to be discoverable), or some kind of second-level> identity, or> some kind of macaroon.
Ah, I see that makes sense +1
On Mon, 03 Jan 2022 17:57:53 +0000 Alex Good <alex@memoryandthought.me> wrote:
> On 03/01/22 10:53am, Kim Altintop wrote:> > On Mon, 20 Dec 2021 06:43:13 -0600 Alex Good <alex@memoryandthought.me> wrote:> > > - Packages for the major distros (and HomeBrew?) which install systemd> > > units for the peer to peer node and the git daemon, as well as the> > > client tooling.> >> > This could create quite some maintenance burden. Getting packages into the> > distros proper typically requires some effort and reputation, while providing> > packages outside the distro typically requires to set up some kind of> > "repository", which tends to be a major pain in the neck (at least for debian> > packages it is).> >> > Perhaps we should focus on systems we use ourselves (ie. PKGSRC, Nix, MacPorts),> > and see if someone steps up for other formats?>> This probably makes sense. Hopefully we can get someone to step up. Most> of the Linux users I know use Ubuntue, it would be great if they can> just `apt install` and not think about anything else.
Yes deb packages are probably the most widely used, but that's where the pain
starts: creating binary debs isn't that hard, but then you need to provide a
repository, manage signing keys etc. We could maybe look into hosting a PPA on
launchpad, but I'm not sure if they implemented some anti-pain measures in
recent years. It used to work by having to manually upload a signed .dsc.
> > > - A simple way to configure "custodial peers" - particular seed nodes users> > > choose to host their work. We currently have no way of knowing what> > > those are. We could use the bootstrap nodes the p2p node is> > > configured with but I think this is undesirable becase a) it conflates> > > two separate network roles and b) it requires fiddling with systemd> > > unit files to configure. I think therefore we will need to decide> > > somewhere to store this information, an RPC to modify it, and CLI> > > tooling for users to talk to it.> >> > Interesting. I'm not sure I agree with a), but how about GIT_DIR/config?>> Yeah `GIT_DIR/config` makes sense. As to a), my thinking was that we may> want to provide IPFS style public bootstrap peers which are baked into> default installations of link. These peers would not be tracking any> projects - just providing a way for people to join the hyparview> cluster. Announcing changes to them is obviously useful but if we have> some kind of request-pull API then things become a little bit tricky. I> would like to provide the user with some guarantees about what happens> when they `push` to the local git server - namely that all custodial> peers will have a `request-pull` sent to them and we will report an> error if one of the custodial peers fails to replicate. This raises a> problem if we have a non-tracking bootstrap node, we would need some way> of determining which nodes are ones we can safely ignore a replication> failure from.
I understand, yes, but I think the moment you have custodial peers you'd want to
prefer them for bootstrapping as well. Which might simplify the problem to
modifying an override configuration. Sure that doesn't distinguish peers which
will replicate you from those who don't, but I think it's a bit iffy to expect
availability of any peer, custodial or not. I'd design a "ensure data has left
my machine" feature to just report success when a certain replication factor is
reached, not where specifically the data went.
On Mon, 03 Jan 2022 17:49:18 +0000 Alex Good <alex@memoryandthought.me> wrote:
> Is there a high level objective we want to achieve this year? @kim the> work you're outlining seems to me to suggest that one high level> objective would be to have the networking and replication be reliable> and efficient enough that anyone can use it, does that sound right?>> Another goal I've been thinking about with the AppArch stuff, and the> packaging is that we should aim for using link to be about as easy as> using SSH. You have to install some packages and secure a key, but you> don't need to know anything about the protocol operation> or how the project is built etc. unless you have unusual requirements. I> guess the identities stuff falls under this goal as well.>> Is thinking in terms of these higher level goals useful or should we> stick with more concrete and tactical ones? What are other goals we> might consider?
I have, in general, some difficulties with high level objectives a la "Every DAO
in the world should be on Radicle" when I don't really know what this entails.
So I like to work backwards from things which need to be done at some point,
which are much easier to find.
That said, I'd like to focus on stabilising networking and replication, yes, and
some _basic_ infra for installing, configuring and orchestrating the different
executables. I'm not interested in making this very polished for end users,
because I'm **much** more interested in developing collaborative objects and
associated tooling. Maybe there is only one high level objective then, which is
"self-host radicle-link".
Kickstarting roadmap planning
Signed-off-by: Kim Altintop <kim@eagain.st>
---
As per RTC session. Range-diff didn't look so useful this time...
TODO.md | 128 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 128 insertions(+)
create mode 100644 TODO.md
diff --git a/TODO.md b/TODO.md
new file mode 100644
index 00000000..e06ed2d9
--- /dev/null+++ b/TODO.md
@@ -0,0 +1,128 @@
+## Objectives++* [x] 2021+* [ ] 2022++ Self-host `radicle-link` on `radicle-link`.++ * Exchange code+ * Find projects+ * Manage patches+ * Task tracking++## Networking++* [ ] Grafting++ > Mutual synchronisation++ * [x] Interrogation+ * [ ] Request-Pull++ > Explicit initiation of mutual replication, replaces "rere"++ * [ ] Sync mode++ > TBD: user-initiated, at startup, other indicators++* [ ] Provider Cache++ > Remember `Have`s in a _k_-bucket structure acc. to local subscription and/or+ > hash value. Can answer `Want` from cache; can locate providers based on+ > distance metric. Unclear how to perform liveness check when protocol is+ > stateful (TLS handshake).++* [ ] NAT Traversal++ * [ ] Hole Punching++ > Requires coordination when NAT is endpoint-dependent. Coordinator nodes+ > could be designated though a DHT, but latency and churn are problematic.+ > Maybe Chord?++* [ ] Gossip Membership Groups++ > Prefer peers with similar interests. Pubsub protocols (eg. gossipsub,+ > episub) are suitable for single-root routing trees, which is not quite what+ > we're after; in pubsub terms, we would have the URN as the topic, while+ > every tracking peer forms a sub-topic (to which others interested in URN may+ > or may not be subscribed). Maybe SCRIBE (Pastry) anycast? Look at Matrix+ > "pinecone"?++## Replication++* [ ] Stabilization++ * [ ] Prune refs+ * [ ] Avoid `ls-refs` in fetch step++ > Would fail the entire fetch if tips mentioned in `signed_refs` are missing++ * [ ] Transactional tracking updates+ * [ ] Scheduling of subsequent pulls++ > Relevant only for newly discovered identities for which a tracking+ > relationship already exists++ * [ ] Single-pass validation++## Identities++* [ ] Simplify verification by requiring history to be linear+* [ ] Simplify initialising a multisig identity (initial revision requires only+ one signature)+* [ ] Quorum overrides for personal ids++ > Cross-signing from multiple devices is inconvenient for personal ids.+ > Macaroons could be issued which allow to confirm a change using only one+ > second factor (HSM, password manager, ..). Or maybe just make the quorum+ > threshold configurable.++* [ ] Extension points for cobs (TBD)++## Collaborative Objects++* [ ] Tasks++ > Turn this document into a CRDT.++* [ ] Patches++ > Track code and comment on it.++ * [ ] Leaderless verifiable multi maintainer (fearless also)++* [ ] To ACL or to not ACL? Moderate or restrict?+* [ ] Discovery of cobs from untracked peers++ > Indexing cob (cob-of-cobs)? Interrogation API?++## Tools & Infrastructure++* [ ] AppArch MVP++ * [ ] Packaging+ * [ ] systemd / launchd configs+ * [ ] linkd++ * [ ] "Announce" RPC+ * [ ] RPC triggering request-pull (single or multiple peers)++ > May provide timer file, which people may or may not activate++ * [ ] RPC triggering clone of URN+ * [ ] macOS socket activation+ * [ ] Configure / override bootstrap peers++ > Do we need to distinguish between bootstrap and custodial peers?++ * [ ] git daemon++ * [ ] Clone-through of URN (experimental)++* [ ] Instrumentation (metrics)+* [ ] git maintenance++ - git config+ - delta islands?+ - systemd/launchd timers
--
2.34.1
On Wed, 05 Jan 2022 09:57:16 +0000 "Fintan Halpenny" <fintan.halpenny@gmail.com> wrote:
> > +* [ ] Patches> > +> > + > Track code and comment on it.> > +> > + * [ ] Leaderless verifiable multi maintainer (fearless also)> > +> > +* [ ] To ACL or to not ACL? Moderate or restrict?> > +* [ ] Discovery of cobs from untracked peers> > +> > + > Indexing cob (cob-of-cobs)? Interrogation API?>> Does this include tooling for working with these patches? Like some> kind of TUI for creating and replying to patches, for example?
I guess so. What would be the simplest way? I suppose a fancy ncurses thing
would be out of scope, but perhaps a command-oriented thing like the `gh` CLI
would do? When it comes to editing strucured data, this just launches a "wizard"
style sequence where you get dropped into $EDITOR for text entry. `gh` is
infuriatingly dumb and slow due to making HTTP calls all the time, but we can
only improve on this.
> > +## Tools & Infrastructure> > +> > +* [ ] AppArch MVP> > +> > + * [ ] Packaging> > + * [ ] systemd / launchd configs> > + * [ ] linkd> > +> > + * [ ] "Announce" RPC> > + * [ ] RPC triggering request-pull (single or multiple peers)> > +> > + > May provide timer file, which people may or may not activate> > +> > + * [ ] RPC triggering clone of URN> > + * [ ] macOS socket activation> > + * [ ] Configure / override bootstrap peers> > +> > + > Do we need to distinguish between bootstrap and custodial peers?> > +> > + * [ ] git daemon> > +> > + * [ ] Clone-through of URN (experimental)> > +> > +* [ ] Instrumentation (metrics)> > +* [ ] git maintenance> > +> > + - git config> > + - delta islands?> > + - systemd/launchd timers>> We forgot to include the integration of the new tracking changes in> rad-identities here :)
Should we account for "chore" tasks separately? Like, there might also be
`link-storage`, using `link-git` in more places, ...
> + > Look at Matrix "pinecone"?
So I did read through the wiki at https://github.com/matrix-org/pinecone/wiki,
but I'm not sure I can make sense of it. It seems like a somewhat complicated
way of arranging peers by the lexicographic order of their public keys, but it's
neither obvious nor expanded upon what problem this is supposed to solve...
On Thu Jan 6, 2022 at 8:50 PM GMT, Kim Altintop wrote:
> On Wed, 05 Jan 2022 09:57:16 +0000 "Fintan Halpenny"> <fintan.halpenny@gmail.com> wrote:> > > +* [ ] Patches> > > +> > > + > Track code and comment on it.> > > +> > > + * [ ] Leaderless verifiable multi maintainer (fearless also)> > > +> > > +* [ ] To ACL or to not ACL? Moderate or restrict?> > > +* [ ] Discovery of cobs from untracked peers> > > +> > > + > Indexing cob (cob-of-cobs)? Interrogation API?> >> > Does this include tooling for working with these patches? Like some> > kind of TUI for creating and replying to patches, for example?>> I guess so. What would be the simplest way? I suppose a fancy ncurses> thing> would be out of scope, but perhaps a command-oriented thing like the> `gh` CLI> would do? When it comes to editing strucured data, this just launches a> "wizard"> style sequence where you get dropped into $EDITOR for text entry. `gh`> is> infuriatingly dumb and slow due to making HTTP calls all the time, but> we can> only improve on this.
I've actually never used the `gh` client, so I can't really
compare. But a little terminal wizard sounds good to me!
> > > +## Tools & Infrastructure> > > +> > > +* [ ] AppArch MVP> > > +> > > + * [ ] Packaging> > > + * [ ] systemd / launchd configs> > > + * [ ] linkd> > > +> > > + * [ ] "Announce" RPC> > > + * [ ] RPC triggering request-pull (single or multiple peers)> > > +> > > + > May provide timer file, which people may or may not activate> > > +> > > + * [ ] RPC triggering clone of URN> > > + * [ ] macOS socket activation> > > + * [ ] Configure / override bootstrap peers> > > +> > > + > Do we need to distinguish between bootstrap and custodial peers?> > > +> > > + * [ ] git daemon> > > +> > > + * [ ] Clone-through of URN (experimental)> > > +> > > +* [ ] Instrumentation (metrics)> > > +* [ ] git maintenance> > > +> > > + - git config> > > + - delta islands?> > > + - systemd/launchd timers> >> > We forgot to include the integration of the new tracking changes in> > rad-identities here :)>> Should we account for "chore" tasks separately? Like, there might also> be> `link-storage`, using `link-git` in more places, ...
I thought I'd mention it since we also mention tracking in the
replication improvements. But chore tasks might also be useful to have
down somewhere in case we want to tune out a little after a long,
arduous task :D
On 07/01/22 10:20am, Fintan Halpenny wrote:
> On Thu Jan 6, 2022 at 8:50 PM GMT, Kim Altintop wrote:> > On Wed, 05 Jan 2022 09:57:16 +0000 "Fintan Halpenny"> > <fintan.halpenny@gmail.com> wrote:> > > > +* [ ] Patches> > > > +> > > > + > Track code and comment on it.> > > > +> > > > + * [ ] Leaderless verifiable multi maintainer (fearless also)> > > > +> > > > +* [ ] To ACL or to not ACL? Moderate or restrict?> > > > +* [ ] Discovery of cobs from untracked peers> > > > +> > > > + > Indexing cob (cob-of-cobs)? Interrogation API?> > >> > > Does this include tooling for working with these patches? Like some> > > kind of TUI for creating and replying to patches, for example?> >> > I guess so. What would be the simplest way? I suppose a fancy ncurses> > thing> > would be out of scope, but perhaps a command-oriented thing like the> > `gh` CLI> > would do? When it comes to editing strucured data, this just launches a> > "wizard"> > style sequence where you get dropped into $EDITOR for text entry. `gh`> > is> > infuriatingly dumb and slow due to making HTTP calls all the time, but> > we can> > only improve on this.>> I've actually never used the `gh` client, so I can't really> compare. But a little terminal wizard sounds good to me!
I have in mind that the natural place to do this is in an editor plugin.
I use Neovim so my plan was to build a Neovim plugin. A lot of the
concepts should carry over to VSCode as well I think.
> > > > +## Tools & Infrastructure> > > > +> > > > +* [ ] AppArch MVP> > > > +> > > > + * [ ] Packaging> > > > + * [ ] systemd / launchd configs> > > > + * [ ] linkd> > > > +> > > > + * [ ] "Announce" RPC> > > > + * [ ] RPC triggering request-pull (single or multiple peers)> > > > +> > > > + > May provide timer file, which people may or may not activate> > > > +> > > > + * [ ] RPC triggering clone of URN> > > > + * [ ] macOS socket activation> > > > + * [ ] Configure / override bootstrap peers> > > > +> > > > + > Do we need to distinguish between bootstrap and custodial peers?> > > > +> > > > + * [ ] git daemon> > > > +> > > > + * [ ] Clone-through of URN (experimental)> > > > +> > > > +* [ ] Instrumentation (metrics)> > > > +* [ ] git maintenance> > > > +> > > > + - git config> > > > + - delta islands?> > > > + - systemd/launchd timers> > >> > > We forgot to include the integration of the new tracking changes in> > > rad-identities here :)> >> > Should we account for "chore" tasks separately? Like, there might also> > be> > `link-storage`, using `link-git` in more places, ...>> I thought I'd mention it since we also mention tracking in the> replication improvements. But chore tasks might also be useful to have> down somewhere in case we want to tune out a little after a long,> arduous task :D
Turn this document into a tasks cob 🙂
On Fri, 07 Jan 2022 12:45:26 +0000 Alex Good <alex@memoryandthought.me> wrote:
> On 07/01/22 10:20am, Fintan Halpenny wrote:> > On Thu Jan 6, 2022 at 8:50 PM GMT, Kim Altintop wrote:> > > On Wed, 05 Jan 2022 09:57:16 +0000 "Fintan Halpenny"> > > <fintan.halpenny@gmail.com> wrote:> > > > Does this include tooling for working with these patches? Like some> > > > kind of TUI for creating and replying to patches, for example?> > >> > > I guess so. What would be the simplest way? I suppose a fancy ncurses> > > thing> > > would be out of scope, but perhaps a command-oriented thing like the> > > `gh` CLI> > > would do? When it comes to editing strucured data, this just launches a> > > "wizard"> > > style sequence where you get dropped into $EDITOR for text entry. `gh`> > > is> > > infuriatingly dumb and slow due to making HTTP calls all the time, but> > > we can> > > only improve on this.> >> > I've actually never used the `gh` client, so I can't really> > compare. But a little terminal wizard sounds good to me!>> I have in mind that the natural place to do this is in an editor plugin.> I use Neovim so my plan was to build a Neovim plugin. A lot of the> concepts should carry over to VSCode as well I think.
I have zero clue about editor plugins, be it vi derivatives, VSCode, or emacs.
Are we positive that we'd be able and willing to shoulder the maintenance
burden?
On 07/01/22 02:26pm, Kim Altintop wrote:
> On Fri, 07 Jan 2022 12:45:26 +0000 Alex Good <alex@memoryandthought.me> wrote:> > On 07/01/22 10:20am, Fintan Halpenny wrote:> > > On Thu Jan 6, 2022 at 8:50 PM GMT, Kim Altintop wrote:> > > > On Wed, 05 Jan 2022 09:57:16 +0000 "Fintan Halpenny"> > > > <fintan.halpenny@gmail.com> wrote:> > > > > Does this include tooling for working with these patches? Like some> > > > > kind of TUI for creating and replying to patches, for example?> > > >> > > > I guess so. What would be the simplest way? I suppose a fancy ncurses> > > > thing> > > > would be out of scope, but perhaps a command-oriented thing like the> > > > `gh` CLI> > > > would do? When it comes to editing strucured data, this just launches a> > > > "wizard"> > > > style sequence where you get dropped into $EDITOR for text entry. `gh`> > > > is> > > > infuriatingly dumb and slow due to making HTTP calls all the time, but> > > > we can> > > > only improve on this.> > >> > > I've actually never used the `gh` client, so I can't really> > > compare. But a little terminal wizard sounds good to me!> >> > I have in mind that the natural place to do this is in an editor plugin.> > I use Neovim so my plan was to build a Neovim plugin. A lot of the> > concepts should carry over to VSCode as well I think.>> I have zero clue about editor plugins, be it vi derivatives, VSCode, or emacs.> Are we positive that we'd be able and willing to shoulder the maintenance> burden?
Not at all positive. This is something I want to do anyway so probably
the best approach here is for me to build this on my own time and then
report back on what's actually involved and if there are any
generalizable components that we might consider maintaining.
Plan out 2022 objectives.
Signed-off-by: Kim Altintop <kim@eagain.st>
---
Final call for comments!
Range-diff against v4:
1: 35c5965d ! 1: 97c87c12 Roadmap
@@ Metadata
Author: Kim Altintop <kim@eagain.st>
## Commit message ##
- Roadmap
+ Road Plan
- Kickstarting roadmap planning
+ Plan out 2022 objectives.
Signed-off-by: Kim Altintop <kim@eagain.st>
@@ TODO.md (new)
+
+## Networking
+
-+* [ ] Grafting
-+
-+ > Mutual synchronisation
-+
-+ * [x] Interrogation
-+ * [ ] Request-Pull
-+
-+ > Explicit initiation of mutual replication, replaces "rere"
-+
-+ * [ ] Sync mode
-+
-+ > TBD: user-initiated, at startup, other indicators
-+
+* [ ] Provider Cache
+
+ > Remember `Have`s in a _k_-bucket structure acc. to local subscription and/or
@@ TODO.md (new)
+
+ * [ ] Single-pass validation
+
++* [ ] Grafting
++
++ > Mutual synchronisation
++
++ * [x] Interrogation
++ * [ ] [RFC 701](https://lists.sr.ht/~radicle-link/dev/%3C20220106191802.13292-1-kim%40eagain.st%3E)
++ * [ ] Finalise
++ * [ ] Implement
++
+## Identities
+
+* [ ] Simplify verification by requiring history to be linear
-+* [ ] Simplify initialising a multisig identity (initial revision requires only
-+ one signature)
++* [ ] Simplify initialising a multisig identity
++
++ > Verification may allow the initial revision to have only one signature,
++ > regardless of the number of delegations.
++
+* [ ] Quorum overrides for personal ids
+
+ > Cross-signing from multiple devices is inconvenient for personal ids.
@@ TODO.md (new)
+ * [ ] linkd
+
+ * [ ] "Announce" RPC
-+ * [ ] RPC triggering request-pull (single or multiple peers)
++ * [ ] RPC triggering RFC701-style sync (single or multiple peers)
+
+ > May provide timer file, which people may or may not activate
+
@@ TODO.md (new)
+
+## Miscellanea
+
-+* [ ] Integrate new tracking in `link-identities`
++* [ ] Integrate new tracking in `rad-identities`
+* [ ] Extract networking into crate
+* [ ] Extract storage into crate
+* [ ] Implement storage in terms of `link-git`
TODO.md | 137 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 137 insertions(+)
create mode 100644 TODO.md
diff --git a/TODO.md b/TODO.md
new file mode 100644
index 00000000..6731f894
--- /dev/null+++ b/TODO.md
@@ -0,0 +1,137 @@
+## Objectives++* [x] 2021+* [ ] 2022++ Self-host `radicle-link` on `radicle-link`.++ * Exchange code+ * Find projects+ * Manage patches+ * Task tracking++## Networking++* [ ] Provider Cache++ > Remember `Have`s in a _k_-bucket structure acc. to local subscription and/or+ > hash value. Can answer `Want` from cache; can locate providers based on+ > distance metric. Unclear how to perform liveness check when protocol is+ > stateful (TLS handshake).++* [ ] NAT Traversal++ * [ ] Hole Punching++ > Requires coordination when NAT is endpoint-dependent. Coordinator nodes+ > could be designated though a DHT, but latency and churn are problematic.+ > Maybe Chord?++* [ ] Gossip Membership Groups++ > Prefer peers with similar interests. Pubsub protocols (eg. gossipsub,+ > episub) are suitable for single-root routing trees, which is not quite what+ > we're after; in pubsub terms, we would have the URN as the topic, while+ > every tracking peer forms a sub-topic (to which others interested in URN may+ > or may not be subscribed). Maybe SCRIBE (Pastry) anycast? Look at Matrix+ > "pinecone"?++## Replication++* [ ] Stabilization++ * [ ] Prune refs+ * [ ] Avoid `ls-refs` in fetch step++ > Would fail the entire fetch if tips mentioned in `signed_refs` are missing++ * [ ] Transactional tracking updates+ * [ ] Scheduling of subsequent pulls++ > Relevant only for newly discovered identities for which a tracking+ > relationship already exists++ * [ ] Single-pass validation++* [ ] Grafting++ > Mutual synchronisation++ * [x] Interrogation+ * [ ] [RFC 701](https://lists.sr.ht/~radicle-link/dev/%3C20220106191802.13292-1-kim%40eagain.st%3E)+ * [ ] Finalise+ * [ ] Implement++## Identities++* [ ] Simplify verification by requiring history to be linear+* [ ] Simplify initialising a multisig identity++ > Verification may allow the initial revision to have only one signature,+ > regardless of the number of delegations.++* [ ] Quorum overrides for personal ids++ > Cross-signing from multiple devices is inconvenient for personal ids.+ > Macaroons could be issued which allow to confirm a change using only one+ > second factor (HSM, password manager, ..). Or maybe just make the quorum+ > threshold configurable.++* [ ] Extension points for cobs (TBD)++## Collaborative Objects++* [ ] Tasks++ > Turn this document into a CRDT.++* [ ] Patches++ > Track code and comment on it.++ * [ ] Leaderless verifiable multi maintainer (fearless also)++* [ ] To ACL or to not ACL? Moderate or restrict?+* [ ] Discovery of cobs from untracked peers++ > Indexing cob (cob-of-cobs)? Interrogation API?++* [ ] CLI+* [ ] Editor Plugin?++## Tools & Infrastructure++* [ ] AppArch MVP++ * [ ] Packaging+ * [ ] systemd / launchd configs+ * [ ] linkd++ * [ ] "Announce" RPC+ * [ ] RPC triggering RFC701-style sync (single or multiple peers)++ > May provide timer file, which people may or may not activate++ * [ ] RPC triggering clone of URN+ * [ ] macOS socket activation+ * [ ] Configure / override bootstrap peers++ > Do we need to distinguish between bootstrap and custodial peers?++ * [ ] git daemon++ * [ ] Clone-through of URN (experimental)++* [ ] Instrumentation (metrics)+* [ ] git maintenance++ - git config+ - delta islands?+ - systemd/launchd timers++## Miscellanea++* [ ] Integrate new tracking in `rad-identities`+* [ ] Extract networking into crate+* [ ] Extract storage into crate+* [ ] Implement storage in terms of `link-git`
--
2.34.1
Oh, one thing did come to mind. So the tracking configuration isn't
being used in replication yet, for filtering purposes. Should we plan
to have this as part of the replication section?
Plan out 2022 objectives.
Signed-off-by: Kim Altintop <kim@eagain.st>
---
Range-diff against v5:
1: 97c87c12 ! 1: 0d3e951b Road Plan
@@ TODO.md (new)
+ > Would fail the entire fetch if tips mentioned in `signed_refs` are missing
+
+ * [ ] Transactional tracking updates
++ * [ ] Honour tracking configuration
+ * [ ] Scheduling of subsequent pulls
+
+ > Relevant only for newly discovered identities for which a tracking
TODO.md | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 138 insertions(+)
create mode 100644 TODO.md
diff --git a/TODO.md b/TODO.md
new file mode 100644
index 00000000..61205f06
--- /dev/null+++ b/TODO.md
@@ -0,0 +1,138 @@
+## Objectives++* [x] 2021+* [ ] 2022++ Self-host `radicle-link` on `radicle-link`.++ * Exchange code+ * Find projects+ * Manage patches+ * Task tracking++## Networking++* [ ] Provider Cache++ > Remember `Have`s in a _k_-bucket structure acc. to local subscription and/or+ > hash value. Can answer `Want` from cache; can locate providers based on+ > distance metric. Unclear how to perform liveness check when protocol is+ > stateful (TLS handshake).++* [ ] NAT Traversal++ * [ ] Hole Punching++ > Requires coordination when NAT is endpoint-dependent. Coordinator nodes+ > could be designated though a DHT, but latency and churn are problematic.+ > Maybe Chord?++* [ ] Gossip Membership Groups++ > Prefer peers with similar interests. Pubsub protocols (eg. gossipsub,+ > episub) are suitable for single-root routing trees, which is not quite what+ > we're after; in pubsub terms, we would have the URN as the topic, while+ > every tracking peer forms a sub-topic (to which others interested in URN may+ > or may not be subscribed). Maybe SCRIBE (Pastry) anycast? Look at Matrix+ > "pinecone"?++## Replication++* [ ] Stabilization++ * [ ] Prune refs+ * [ ] Avoid `ls-refs` in fetch step++ > Would fail the entire fetch if tips mentioned in `signed_refs` are missing++ * [ ] Transactional tracking updates+ * [ ] Honour tracking configuration+ * [ ] Scheduling of subsequent pulls++ > Relevant only for newly discovered identities for which a tracking+ > relationship already exists++ * [ ] Single-pass validation++* [ ] Grafting++ > Mutual synchronisation++ * [x] Interrogation+ * [ ] [RFC 701](https://lists.sr.ht/~radicle-link/dev/%3C20220106191802.13292-1-kim%40eagain.st%3E)+ * [ ] Finalise+ * [ ] Implement++## Identities++* [ ] Simplify verification by requiring history to be linear+* [ ] Simplify initialising a multisig identity++ > Verification may allow the initial revision to have only one signature,+ > regardless of the number of delegations.++* [ ] Quorum overrides for personal ids++ > Cross-signing from multiple devices is inconvenient for personal ids.+ > Macaroons could be issued which allow to confirm a change using only one+ > second factor (HSM, password manager, ..). Or maybe just make the quorum+ > threshold configurable.++* [ ] Extension points for cobs (TBD)++## Collaborative Objects++* [ ] Tasks++ > Turn this document into a CRDT.++* [ ] Patches++ > Track code and comment on it.++ * [ ] Leaderless verifiable multi maintainer (fearless also)++* [ ] To ACL or to not ACL? Moderate or restrict?+* [ ] Discovery of cobs from untracked peers++ > Indexing cob (cob-of-cobs)? Interrogation API?++* [ ] CLI+* [ ] Editor Plugin?++## Tools & Infrastructure++* [ ] AppArch MVP++ * [ ] Packaging+ * [ ] systemd / launchd configs+ * [ ] linkd++ * [ ] "Announce" RPC+ * [ ] RPC triggering RFC701-style sync (single or multiple peers)++ > May provide timer file, which people may or may not activate++ * [ ] RPC triggering clone of URN+ * [ ] macOS socket activation+ * [ ] Configure / override bootstrap peers++ > Do we need to distinguish between bootstrap and custodial peers?++ * [ ] git daemon++ * [ ] Clone-through of URN (experimental)++* [ ] Instrumentation (metrics)+* [ ] git maintenance++ - git config+ - delta islands?+ - systemd/launchd timers++## Miscellanea++* [ ] Integrate new tracking in `rad-identities`+* [ ] Extract networking into crate+* [ ] Extract storage into crate+* [ ] Implement storage in terms of `link-git`
--
2.34.1