Zack Owens

The library currently implements proposal pipelining, where multiple instances may be decided concurrently. Add in the option to batch multiple proposals and send these out to the replicas as a...

Add a feature-enabled default transport implementation that can be used out-of-the-box.

Last step to getting this out into Crates.io! It turns out [paxos](https://crates.io/search?q=paxos) is taken, so we need a different name. Some ideas: - paxos-rs - pax-rs - paxi

The [PigPaxos](https://arxiv.org/pdf/2003.07760.pdf) paper shows a novel idea to use a peer replica to broadcast communication to reduce the computational needs on the Paxos leader. This could be an interesting extension.

Paxos used in a WAN setting would need some additional considerations. The [WPaxos paper](https://arxiv.org/pdf/1703.08905.pdf) and [Paxi implementation](https://github.com/ailidani/paxi/tree/master/wpaxos) provide a framework for separating the object space for use in a WAN...

More examples! A replicated log would add an additional example that showcases the library. It may also be useful to evaluate publishing examples as crates themselves for consumption by other...

In most uses of Paxos, read heavy workloads do not need to traverse the entire Paxos protocol (at least Phase 2). In the [Paxos made Live](https://www.cs.utexas.edu/users/lorenzo/corsi/cs380d/papers/paper2-1.pdf) paper, the authors describe...

There should be model checking tests that run as unit tests. This can be accomplished with something like [stateright](https://github.com/stateright/stateright).

It is awkward currently to handle a state machine and in the same vein support client requests for proposals. It would be nice to have library-level features to make programming...

Add in the configuration learners/observers that do not participate in Phase 1 or Phase 2 quorum, but learn of decisions.