Trait Ordering 

pub trait Ordering<ID, OP, DGM>
where
    DGM: GroupMembership<ID, OP>,
{
    type State;
    type Error: Error;
    type Message: GroupMessage<ID, OP, DGM>;

    // Required methods
    fn next_control_message(
        y: Self::State,
        control_message: &ControlMessage<ID>,
        direct_messages: &[DirectMessage<ID, OP, DGM>],
    ) -> Result<(Self::State, Self::Message), Self::Error>;
    fn next_application_message(
        y: Self::State,
        group_secret_id: GroupSecretId,
        nonce: XAeadNonce,
        ciphertext: Vec<u8>,
    ) -> Result<(Self::State, Self::Message), Self::Error>;
    fn queue(
        y: Self::State,
        message: &Self::Message,
    ) -> Result<Self::State, Self::Error>;
    fn set_welcome(
        y: Self::State,
        message: &Self::Message,
    ) -> Result<Self::State, Self::Error>;
    fn next_ready_message(
        y: Self::State,
    ) -> Result<(Self::State, Option<Self::Message>), Self::Error>;
}

Available on crate features data_scheme only.

Ordering protocol for p2panda’s “data encryption” scheme.

When publishing a message peers need to make sure to provide the following informations:

1. “create” control messages do not have any dependencies as they are the first messages in a group.
2. When an “add”, “update” or “remove” control message gets published, that message needs to point at all the last known, previously processed control messages (by us and others).
3. Every application message needs to point at the control message which generated the used secret. Usually applications always use the “latest” group secret. In this case it’s enough to point at the last known control messages (similar to point 2).

When a peer processes a “welcome” message (they got added to a group) then all previously seen control and application messages can be re-processed.

Applications can choose to remove secrets from their group bundles for forward secrecy. In this case additional logic is required to “jump” over these “outdated” application messages. Ignoring these messages can take place when processing the “welcome” message.

Required Associated Types

type State

type Error: Error

type Message: GroupMessage<ID, OP, DGM>

Required Methods

fn next_control_message( y: Self::State, control_message: &ControlMessage<ID>, direct_messages: &[DirectMessage<ID, OP, DGM>], ) -> Result<(Self::State, Self::Message), Self::Error>

fn next_application_message( y: Self::State, group_secret_id: GroupSecretId, nonce: XAeadNonce, ciphertext: Vec<u8>, ) -> Result<(Self::State, Self::Message), Self::Error>

fn queue( y: Self::State, message: &Self::Message, ) -> Result<Self::State, Self::Error>

fn set_welcome( y: Self::State, message: &Self::Message, ) -> Result<Self::State, Self::Error>

fn next_ready_message( y: Self::State, ) -> Result<(Self::State, Option<Self::Message>), Self::Error>

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors

impl<DGM> Ordering<usize, MessageId, DGM> for MessageOrderer<DGM>

where DGM: Debug + Clone + GroupMembership<MemberId, MessageId> + Serialize + for<'a> Deserialize<'a>,

Available on crate features test_utils only.

type State = MessageOrdererState<DGM>

type Error = MessageOrdererError

type Message = TestMessage<DGM>