maidsafe-archive / crust

Reliable p2p network connections in Rust with NAT traversal. One of the most needed libraries for any server-less / decentralised projects
BSD 3-Clause "New" or "Revised" License
956 stars 126 forks source link

Remove Uid trait #1116

Closed povilasb closed 5 years ago

povilasb commented 5 years ago

Currently Crust Service is generic over Uid trait. This trait is used for service ID and spreads throughout the whole code base. To make Service use simpler we will remove the ID type parameter and use a specific ID structure instead.

Advantages

This will simplify Crust code base a lot. E.g. CrustData is generic over Uid and this requires EventLoopCore<UID> and EventLoop<UID> to be generic which are used in Crust States, so they have to be generic as well, etc. E.g. see BootstrapState

Disadvantages

Routing uses a tuple of (pub_sign_key, pub_encrypt_key) to identify peers. To satisfy Routing needs Crust would need to associate public signing key with public encryption key. So in this case Crust would be holding redundant data - public signing key.

Although, given that data signing could quite common operation in p2p networks, that might not be a big issue. Also, for users that don't need signing keys, we could provide a helper ID constructor, say:

impl PeerId {
    fn without_sign_key() -> Self {
        Self {
             pub_enc_key,
             pub_sign_key: PublicSignKey::from_bytes(&[0; 32]),
    }
}

Anyway, this is out of the scope of this issue.

API

The new proposed Service API with regard to ID management is:

/// Crust peer ID
pub struct PeerId {
    pub pub_enc_key: PublicEncryptKey,
    pub pub_sign_key: PublicSignKey,
}

pub struct Service {
    // ...
    our_uid: PeerId,
}

impl Service {
    pub fn with_config(
        event_tx: crate::CrustEventSender<UID>,
        config: Config,
        our_uid: PeerId,
    ) -> crate::Res<Self>;
}

Then Crust users would fill the values of PeerId and pass it to Crust constructor.