Feedback of all kinds. A comment is *greatly* appreciated!

[rustonbsd]

Please feel free to leave your experience with this experimental crate as a comment.

Ideally you include your setup:

• OS + version
• Physical node count
• Network setup
• Nodes spawned per physical node

And then what ever you noticed. If everything works fine on your setup, that would be valuable information too.

Thank you for participating!

[zignig]

This is a comment....

Been thinking about iroh. Have some comments soon.

[rustonbsd]

Now testable via crates.io

cargo add distributed-topic-tracker to any project using iroh-gossip

and then follow the chat example

[zignig]

Dist tracker has got me thinking (always a bad sign), I think that sharing author keys and document roots will help to build an iroh web of trust. As much as the dist tracker is cool... Get some nodes onboard and work up.

[rustonbsd]

Hi @zignig, thanks for your comment :)

Dist tracker has got me thinking (always a bad sign), I think that sharing author keys and document roots will help to build an iroh web of trust. As much as the dist tracker is cool... Get some nodes onboard and work up.

Can you elaborate a little bit on what you mean exactly?

[rustonbsd]

From @rorycoughlan8 on the iroh Discord (and I believe @Gumbo64 here on github):

it works perfectly for me! Cold start varies quite a lot, most of the time around 10 to 15 seconds but sometimes it times out and goes to 30. Hot start always seems pretty quick though at like 5 seconds maybe

Thank you for the feedback! This is invaluable!

[Nuhvi]

Hey, I love the creativity in this to make due with what Mainline offers.

While extending Mainline is hard work and will always start small (handful of nodes) until major clients like Libtorrent buys in... It is not impossible and it is definitely more performant ... and if you don't expect to be Sybil attacked sooner than the adoption materializes, then it might be a good alternative.

I defined an extension, and implemented it and deployed one bootstrapping node (the usual relay.pkarr.org:6881), so if you are interested in this, maybe you can run a node as well, or just use the API and see how reliable my node serves you;

• BEP draft proposal for announcing signed peers bittorrent/bittorrent.org#174
• Example https://github.com/Nuhvi/mainline/blob/main/examples/README.md#anounceget-signed-peers-for-overlay-networks

[rustonbsd]

@Nuhvi first of all thank you for your amazing Bittorrent DHT implementation!

I have skimmed the proposal, when/if accepted this would be amazing for all sorts of use cases (see https://github.com/rustonbsd/rustpatcher where I do iroh independent record publishing).

I will read it again in more detail later today or tomorrow and run a node myself. I will share my feedback (here?) once I find the time to refactor with your proposed: announce_signed_peer, get_signed_peer.

Thank you for your comment :)

[Nuhvi]

@rustonbsd Feel free to share your feedback here, or anywhere mentioned in the contacts at nuh.dev, or find me in the Iroh discord server.

[dezren39]

thanks for this project it's very interesting to me as a backup to regular relays. i forgot about this for a minute and then was trying to find it this evening using words like iroh-pkarr iroh-dht but only found the old examples in the iroh repo. I wonder if this repo might be easier to find/understand for unfamiliar users if it is prefied with iroh-? either way thank you so much for starting this, looking forward to seeing how it goes. :-)

[teohhanhui]

In all the examples, the secret_key and signing_key seem to be the same, but:

We do NOT recommend using a signing/verifying key for encryption. Signing keys are usually long-term keys, while keys used for key exchange should rather be ephemeral. If you can help it, use a separate key for encryption.

For more information on the security of systems which use the same keys for both signing and Diffie-Hellman, see the paper On using the same key pair for Ed25519 and an X25519 based KEM.

https://docs.rs/ed25519-dalek/3.0.0-pre.6/ed25519_dalek/struct.SigningKey.html#note-2

If this is necessary and secure, perhaps it should be documented?

---

initial_secret is the shared secret, right? The naming is really confusing if that's the case. Perhaps it should just be renamed shared_secret?