(DRAFT) Initial WIP on noosphere-name-service

[jsantell]

Initial WIP on noosphere-name-service a crate that handles both providing and querying a DHT to resolve sphere DID mapping to latest, verifiable CID.

Current status: record propagation/serving is not currently working, need to dive more into libp2p::kad's implementation.

Brief description of how it works:

• On a "server", run noosphere-name-system daemon --keyname $KEYNAME --pinned $PINNED_TOML_PATH
  • Keys must already be configured (e.g. in ~/.noosphere/keys/$KEYNAME.{public|private})
  • $PINNED_TOML_PATH is a toml file with key/value pairs to serve (see examples/pinned.toml). This TOML store is only for testing really. These values in pinned.toml were generated from a local sphere DID, and a signed UCAN auth that should be authenticated, but no verification of actual values implemented yet.
  • Currently fails to propagate value; lots of handlers at the moment purely for logging.
• In a "client", run noosphere-name-system query get $SPHERE_DID
  • $SPHERE_DID should be one of the keys being provided by the server, e.g. in $PINNED_TOML_PATH

Note libp2p requires protobufs.

• Linux apt: sudo apt install protobuf-compiler cmake
• MacOS Homebrew: brew install protobuf cmake

[jsantell]

@cdata WDYT about exposing key details in noosphere::authority? Though more UCAN integration will be needed here (in name-system, not specifically this CLI dev shell)

[cdata]

There are some generalized helpers that we use across the crates for generating and managing these keys:

noosphere/rust/noosphere/src/authority/key_material.rs

Lines 16 to 38 in 88b08e3

	pub fn generate_ed25519_key() -> Ed25519KeyMaterial {
	let private_key = Ed25519PrivateKey::new(rand::thread_rng());
	let public_key = Ed25519PublicKey::from(&private_key);
	Ed25519KeyMaterial(public_key, Some(private_key))
	}
	pub fn restore_ed25519_key(mnemonic: &str) -> Result<Ed25519KeyMaterial> {
	let mnemonic = Mnemonic::from_phrase(mnemonic, Language::English)?;
	let private_key = Ed25519PrivateKey::try_from(mnemonic.entropy())?;
	let public_key = Ed25519PublicKey::try_from(&private_key)?;
	Ok(Ed25519KeyMaterial(public_key, Some(private_key)))
	}
	pub fn ed25519_key_to_mnemonic(key_material: &Ed25519KeyMaterial) -> Result<String> {
	let private_key = &key_material.1.ok_or_else(|| {
	anyhow!(
	"A mnemonic can only be generated for the key material if a private key is configured"
	)
	})?;
	let mnemonic = Mnemonic::from_entropy(private_key.as_ref(), Language::English)?;
	Ok(mnemonic.into_phrase())
	}

I would be happy for us to expand on these. Although, I would shy away from re-exporting implementation directly from other crates unless it seems like we really need to.

[jsantell]

This TOML with pinned keys is purely for dev/testing. Maybe some existing infra in noosphere-gateway, a sqlite table, or simple files to track "pinned content" (using IPFS parlance) while running the node. Any insight here @cdata ?

The CLI was originally an example, hence this toml file being here. Probably should move it back to being an example. Depends on what the final interface looks like with the gateway. Sort of inspired by (mostly now deprecated) kubo CLI for interfacing with the DHT via low level commands for debugging/customization.

[cdata]

Yah, use SphereDb or any Store-implementing construct. They implement KeyValueStore, so you can set_key, get_key for configuration like this.

In the big picture, this data is going to come from the Sphere data structure itself, which means it will ultimately come from one of these stores (although it will be in a block, not a k/v entry).

[jsantell]

Handling in follow up PRs: #93