p2panda_stream/lib.rs
1// SPDX-License-Identifier: MIT OR Apache-2.0
2
3#![cfg_attr(docsrs, feature(doc_cfg))]
4
5//! Interfaces to implement and compose event processors on top of data streams with some p2panda
6//! implementations out-of-the-box, wrapping existing p2panda crates for causal message ordering,
7//! log validation, access control and group encryption CRDTs which might come in handy for some
8//! peer-to-peer applications.
9//!
10//! Developers can "stack up" different stream processors on top of each other and layer them based
11//! on the application's needs. Each processor will formulate requirements (in the form of a Rust
12//! trait) to the underlying data type; you either "bring your own" or use our `Operation` data type
13//! which has most requirements implemented.
14//!
15//! In p2panda we clearly separate the "event delivery" layer from the "event processing" one. This
16//! part of the stack doesn't care what transport was used (pidgeon carriers, usb sticks, internet
17//! protocol, LoRa, etc.). Ideally the application should just work fine independent of how the data
18//! was delivered, the only part which really matters is how the event stream was _processed_.
19//!
20//! This stream processor design can be nicely combined with a Pub/Sub system (like `p2panda-net`),
21//! scoped and stateful stream controllers (in `p2panda` Node API) and storage backends supporting
22//! atomic transactions (`p2panda-store`).
23//!
24//! ## Single-Threaded Design
25//!
26//! Processors are meant to only be executed within a single thread and do not allow `Send` or
27//! `Sync` types. Users need to make sure to run this code in a "local" tokio runtime.
28#[cfg(feature = "ingest")]
29pub mod ingest;
30#[cfg(feature = "log_prune")]
31pub mod log_prune;
32#[cfg(feature = "orderer")]
33pub mod orderer;
34mod processors;
35#[cfg(test)]
36mod test_utils;
37
38pub use processors::*;