Started work on did-simple and did-chain (#93)

All the existing DID crates seemed unnecessarily generic and
[complex](https://docs.rs/didkit/latest/didkit/trait.DIDResolver.html).
I've decided to simplify things and roll my own. Since we only intend to
support two resolvers initially (`did:key` and `did:web`) and a limited
number of use cases, I think this gives us an opportunity to strip away
a lot of cruft.

Cargo.toml

@@ -10,6 +10,8 @@ members = [
 	"apps/social/networking",
 	"apps/social/server",
 	"crates/bevy_egui_keyboard",
+	"crates/did-chain",
+	"crates/did-simple",
 	"crates/egui-picking",
 	"crates/picking-xr",
 	"crates/replicate/client",

apps/legacy_web/backend/Cargo.toml

@@ -5,6 +5,7 @@ license.workspace = true
 repository.workspace = true
 edition.workspace = true
 rust-version.workspace = true
+publish = false
 
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 

apps/legacy_web/frontend/Cargo.toml

@@ -5,6 +5,7 @@ license.workspace = true
 repository.workspace = true
 edition.workspace = true
 rust-version.workspace = true
+publish = false
 
 [dependencies]
 egui = "0.26.0"

apps/rvid/client/Cargo.toml

@@ -6,6 +6,7 @@ repository.workspace = true
 edition.workspace = true
 rust-version.workspace = true
 description = "A rust based wireless PCVR solution"
+publish = false
 
 [lib]
 crate-type = ["cdylib", "rlib"]

apps/rvid/server/Cargo.toml

@@ -6,5 +6,6 @@ repository.workspace = true
 edition.workspace = true
 rust-version.workspace = true
 description = "A rust based wireless PCVR solution"
+publish = false
 
 [dependencies]

apps/social/client/Cargo.toml

@@ -6,6 +6,7 @@ repository.workspace = true
 edition.workspace = true
 rust-version.workspace = true
 description = "A social vr demo in bevy"
+publish = false
 
 [lib]
 crate-type = ["cdylib", "rlib"]

apps/social/common/Cargo.toml

@@ -5,6 +5,7 @@ license.workspace = true
 repository.workspace = true
 edition.workspace = true
 rust-version.workspace = true
+publish = false
 
 [dependencies]
 bevy.workspace = true

apps/social/networking/Cargo.toml

@@ -5,6 +5,7 @@ license.workspace = true
 repository.workspace = true
 edition.workspace = true
 rust-version.workspace = true
+publish = false
 
 [dependencies]
 bevy = { workspace = true, features = ["serialize"] }

apps/social/server/Cargo.toml

@@ -6,6 +6,7 @@ repository.workspace = true
 edition.workspace = true
 rust-version.workspace = true
 description = "A server for the social vr bevy demo"
+publish = false
 
 [features]
 default = []

crates/bevy_egui_keyboard/Cargo.toml

@@ -5,6 +5,7 @@ license.workspace = true
 repository.workspace = true
 edition.workspace = true
 rust-version.workspace = true
+publish = false
 
 # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
 

crates/did-chain/Cargo.toml

@@ -0,0 +1,11 @@
+[package]
+name = "did-chain"
+version.workspace = true
+license.workspace = true
+repository.workspace = true
+edition.workspace = true
+rust-version.workspace = true
+description = "A chain of Decentralized Identifiers"
+
+[dependencies]
+did-simple = { version = "0.0.0", path = "../did-simple" }

crates/did-chain/src/lib.rs

@@ -0,0 +1,39 @@
+//! A crate to manipulate DID chains.
+//!
+//! For more info on what a Decentralized Identifier aka "DID" is, you can
+//! [read the spec][spec], or read the docs of the [`did_simple`] crate. The
+//! TLDR is that you can treat it like a UUID, except that it also supports
+//! signing and encrypting messages, as well as proving that you own the DID
+//! without relying on any single centralized service.
+//!
+//! This crate builds upon the concept of a DID to introduce a chain of DIDs.
+//! A did chain is a linear list of DIDs, starting with a root did. Each did in
+//! the chain signs a message linking it to the next one in the chain. You then
+//! can use the public keys of the last DID in the chain to get public keys
+//! from, which may be significantly more convenient to use than the root DID.
+//!
+//! This allows end users to mix and match did methods, giving them the ability
+//! to pick the right balance of convenience vs security for their needs. For
+//! example, a user's root did:key could have its private keys live in cold
+//! storage, and instead they do day to day signing with a DID:web that is
+//! hosted by a third party. If they ever need to change their DID:web, they
+//! can retrieve the root did and sign a message to migrate to a new child DID.
+//!
+//! [spec]: https://www.w3.org/TR/did-core/
+
+#![forbid(unsafe_code)]
+
+pub use did_simple;
+
+use did_simple::{methods::key::DidKey, methods::DidDyn};
+
+/// This is like an account UUID, it provides a unique identifier for the
+/// account. Changing it is impossible.
+#[derive(Debug)]
+pub struct DidRoot(DidKey);
+
+#[derive(Debug)]
+pub struct DidChain {
+	pub root: DidRoot,
+	pub chain: Vec<DidDyn>,
+}

crates/did-simple/Cargo.toml

@@ -0,0 +1,16 @@
+[package]
+name = "did-simple"
+version.workspace = true
+license.workspace = true
+repository.workspace = true
+edition.workspace = true
+rust-version.workspace = true
+description = "Dead simple DIDs"
+publish = false
+
+[dependencies]
+thiserror = "1.0.60"
+bytes = "1.6.0"
+
+[dev-dependencies]
+eyre = "0.6.12"

crates/did-simple/src/lib.rs

@@ -0,0 +1,33 @@
+//! A Decentralized Identifier (aka [DID][spec]), is a globally unique
+//! identifier that provides a general purpose way of looking up public keys
+//! associated with the globally unique identifier.
+//!
+//! This means that unlike a UUID, someone can prove that they own a DID, and
+//! you can encrypt messages using DIDs! This makes DIDs strictly more useful
+//! than traditional UUIDs as account identifiers and are very useful for
+//! building federated or decentralized services.
+//!
+//! Unlike traditional centralized accounts, services that use DIDs give users
+//! custody over their account identity. Authentication of users can happen
+//! without the need for a centralized service or database. Instead, whoever
+//! holds the private keys associated with a DID will be able to authenticate as
+//! the account owner.
+//!
+//! This gives users the ability to maintain the same account handles/identities
+//! across multiple separate services (or migrate homeservers in a federated
+//! system) without having to create a new, different, account or identity each
+//! time.
+//!
+//! [spec]: https://www.w3.org/TR/did-core/
+
+#![forbid(unsafe_code)]
+
+use std::str::FromStr;
+
+pub mod methods;
+pub mod uri;
+pub mod utf8bytes;
+
+pub trait Did: FromStr {
+	fn uri(&self) -> self::uri::DidUri;
+}

crates/did-simple/src/methods/key.rs

@@ -0,0 +1,8 @@
+//! An implementation of the [did:key] method.
+//!
+//! [did:key]: https://w3c-ccg.github.io/did-method-key/
+
+/// An implementation of the `did:key` method. See the [module](self) docs for more
+/// info.
+#[derive(Debug, Eq, PartialEq, Hash, Clone)]
+pub struct DidKey;

crates/did-simple/src/methods/mod.rs

@@ -0,0 +1,10 @@
+pub mod key;
+pub mod web;
+
+/// Dynamically typed did method.
+#[derive(Debug, Eq, PartialEq, Hash, Clone)]
+#[non_exhaustive]
+pub enum DidDyn {
+	Key(self::key::DidKey),
+	Web(self::web::DidWeb),
+}

crates/did-simple/src/methods/web.rs

@@ -0,0 +1,8 @@
+//! An implementation of the [did:web] method.
+//!
+//! [did:web]: https://w3c-ccg.github.io/did-method-web
+
+/// An implementation of the `did:web` method. See the [module](self) docs for more
+/// info.
+#[derive(Debug, Eq, PartialEq, Hash, Clone)]
+pub struct DidWeb;