It just occured to me that we *could* use the DHT part of Kademlia if the DHT had the type:

  HashMap<ProjectId, Set<PeerId>>

So first a `lookupValue(id) -> Set<PeerId>` would be issued, and with the result, a `lookupPeer(id)`
would be issued (eg. with a random peer in the result set), and finally a connection would be established and the project
would be fetched.

Thoughts?

------- Original Message -------
On Wednesday, August 10th, 2022 at 18:28, Alexis Sellier <alexis@radicle.foundation> wrote:

So, the part I don't understand with using something like Kademlia, is
that it seems like it's designed for a case where nodes don't get to
decide what content they store, and this is what allows the optimization
of finding nodes in log time. Am I missing something?

Using the routing structure would basically mean that we have the ability to
look up IPs, given a PeerId, right? We'd still need a way for peers to
announce which projects they have, and it doesn't look like Kademlia is
designed for that (as it's deterministic with Kademlia, not arbitrary).

------- Original Message -------
On Thursday, June 30th, 2022 at 14:53, Kim Altintop <kim@eagain.io> wrote:

Yeah, that's a good point. I'm trying to think of the cost/benefit here. The advantage
of the key-per-device model is also a disadvantage in that a user needs one repository/remote
per device, ie. it makes it harder to share code with themselves, which is counter-intuitive.

I think this needs more thought, and I'm definitely not against giving users the choice here
in having an identity backed by more than one key, as long as there's an alternative path
for single-device users which doesn't impose all that complexity.

This implies that the identifier format should be future-compatible though, to support things
other than keys :)

> > Good question; the way I imagine it, you definitely would not edit the identity
> > document, you would simply add unverified[0] changes to your fork of the canonical
> > repo. When running `rad-verify` or such tooling, it would be clear that the
> > last few commits are signed, but not "approved" by the maintainer quorum.
> > This would always be the case for non-maintainer forks with changes.
> > 

> > [0]: unverified in the sense that they aren't verified by delegates, but the
> > commit can still be verified to belong to a key/identity. A better term might
> > be "un-accepted".
> > 

> > When collaborating, it's clear that there will be unverified commits passed

Thanks for the feedback, let me try to reply to these:

------- Original Message -------
On Thursday, August 4th, 2022 at 19:30, Alex Good <alex@memoryandthought.me> wrote:


> 

> 

> I'm still working on a detailed response to this, but I have a few questions I
> wanted to clarify:
> 

I've been thinking about the experience of new users coming into radicle as we build
the high-level tools and onboarding via `radicle-cli`, and I've come to the conclusion
that a lot of the stuff we're doing should be simplified. As it stands, I think the
identity system is one of the main blockers for building simple UX that will lead to
adoption. There's two core issues with the system as it stands:

1. Doesn't play well with the browser

Users should be able to onboard onto the web and sign payloads in the browser without
having to install anything radicle-specific. This isn't possible today.

2. Friction and encoding as "hidden" branch confuses users and is hard to work with

Working with identities requires specialized tooling, given that they are encoded inside

> > [[seed]]
> > name = "my-seed"
> > p2p = "rad://hyb5to4rshftx4apgmu9s6wnsp4ddmp1mz6ijh4qqey7fb8wrpawxa@pine.radicle.garden:8776"
> > git = "https://pine.radicle.garden:443"
> > api = "https://pine.radicle.garden:8777"
> 

> 

> An alternative to all of these might be to use SRV records? Or support
> some kind of service discovery API on the server itself?
> 

Little update on this. I'm going to trial the following system, loosely modeled after cargo:

# File format

For now, something like this:
```
[[seed]]
name = "my-seed"
p2p = "rad://hyb5to4rshftx4apgmu9s6wnsp4ddmp1mz6ijh4qqey7fb8wrpawxa@pine.radicle.garden:8776"
git = "https://pine.radicle.garden:443"
api = "https://pine.radicle.garden:8777"

[[seed]]
...

------- Original Message -------
On Tuesday, July 12th, 2022 at 12:08, Alex Good <alex@memoryandthought.me> wrote:


> 

> 

> On 12/07/22 07:53am, Alexis Sellier wrote:

Hey - wanted to get some thoughts on something,

Currently, seed configuration is stored in a flat file with the format:

```
<peer>@<addr>
<peer>@<addr>
etc.
```

This works fine for simple use-cases, but our use-case is a bit more complex:
our seeds have more than one component, eg. they have a git bridge and an http
api. Each of these may be configured differently. Another difference is that
we allow users to configure per-working-copy seeds that overwrite the "global"