1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
// SPDX-License-Identifier: MIT OR Apache-2.0
//! Core data types used across the p2panda stack to offer distributed, secure and efficient data
//! transfer between peers.
//!
//! The main data type is a highly extensible, cryptographically secure append-only log
//! implementation. It provides all the basic features required to implement more advanced
//! distributed data types commonly required when building peer-to-peer and local-first
//! applications.
//!
//! ## Features
//!
//! - Cryptographic signatures for authorship verification and tamper-proof messages
//! - Authors can maintain one or many logs
//! - Single-writer logs which can be combined to support multi-writer collaboration
//! - Compatible with any application data and CRDT
//! - Various ordering algorithms
//! - Supports efficient, partial sync
//! - Compatible with any networking scenario (even broadcast-only, for example for packet radio)
//! - Fork-tolerant
//! - Pruning of outdated messages
//! - Highly extensible with custom features, for example prefix-deletion, ephemeral
//! "self-destructing" messages, etc.
//!
//! p2panda logs are made up of [`Operation`]s. Authors sign operations using their cryptographic
//! key pair and append them to a log. An author may have one or many logs. The precise means of
//! identifying logs is not defined by this crate (see extensions).
//!
//! A common challenge in distributed systems is how to order operations written concurrently by
//! different authors and/or processes. Operations contain information which can be used for
//! establishing order depending on one's use case:
//! - `timestamp`: UNIX timestamp describing when the operation was created.
//!
//! Custom extension fields can be defined by users of this library to introduce additional
//! functionality depending on their particular use cases. p2panda provides our own extensions
//! which are required when using our other crates offering more advanced functionality needed for
//! application building (CRDTs, access control, encryption, ephemeral data, garbage collection,
//! etc.), but it's entirely possible for users to define their own extensions as well.
//!
//! An operation is constructed from a [`Header`] and a [`Body`], the `Header` contains all
//! metadata associated with the particular operation, and the `Body` contains the actual
//! application message bytes. This allows "off-chain" handling, where the important bits in the
//! headers are transmitted via an prioritised channel and secondary information can be loaded
//! "lazily". Additionally it allows deletion of payloads without breaking the integrity of the
//! append-only log.
//!
//! ## Example
//!
//! ```
//! use p2panda_core::{Body, Header, Operation, SigningKey, Timestamp};
//!
//! // Every operation is cryptographically authenticated by an author by signing it with an
//! // Ed25519 key pair. This method generates a new private key for us which needs to be securely
//! // stored for re-use.
//! let signing_key = SigningKey::generate();
//!
//! // Operations consist of an body (with the actual application data) and a header,
//! // enhancing the data to be used in distributed networks.
//! let body = Body::new("Hello, Sloth!".as_bytes());
//! let mut header = Header {
//! version: 1,
//! verifying_key: signing_key.verifying_key(),
//! signature: None,
//! payload_size: body.size(),
//! payload_hash: Some(body.hash()),
//! timestamp: Timestamp::now(),
//! seq_num: 0,
//! backlink: None,
//! extensions: (),
//! };
//!
//! // Sign the header with the author's private key. From now on it's ready to be sent!
//! header.sign(&signing_key);
//! ```
pub use Cursor;
pub use ;
pub use ;
pub use ;
pub use ;
pub use ;
pub use PruneFlag;
pub use Timestamp;
pub use Topic;