From Kim Altintop to ~radicle-link/discuss
> It just occured to me that we *could* use the DHT part of Kademlia if the DHT had the type: > > HashMap<ProjectId, Set<PeerId>> Yes this has been dubbed “provider cache” on various occasions, borrowing ipfs jargon.
From Kim Altintop to ~radicle-link/discuss
Sorry you feel edgy. But "wow" is the only response I have recognising the
pattern: something is not going quite like we wanted, some complaints are made,
some symptoms are observed, some explanations are brought forward. But then,
instead of scrutinising that -- and, most importantly, taking into account the
path that led here -- a shortcut is taken.
The term for that is "jumping to conclusions", I believe, and it has hurt the
Radicle project on more than one occasion.
I can start from the top, though:
> == The gossip network
From Kim Altintop to ~radicle-link/discuss
This is the depth of your understanding? Wow.
From Kim Altintop to ~radicle-link/dev
Although I think it would generally be preferable to promote explicit signoff and nudge people away from trusting random names from the internet, I believe what you want is to pick the merge base (i.e. most recent common commit).
From Kim Altintop to ~radicle-link/discuss
> Why would they require weaker schemes?
ed25519 is not very widely supported on key fobs f.ex.
From Kim Altintop to ~radicle-link/discuss
Also: blockchains
From Kim Altintop to ~radicle-link/dev
Also: blockchains
From Kim Altintop to ~radicle-link/dev
> Why would they require weaker schemes?
ed25519 is not very widely supported on key fobs f.ex.
From Kim Altintop to ~radicle-link/dev
> Anyone have any insight?
- stabilise replication-v3
- refrain from using feature flags
- use a sane build tool
From Kim Altintop to ~radicle-link/dev
> +pub async fn clone() {}
This function summarises Rust.