As outlined in [Waku's latest FURPS for Codex](https://github.com/waku-org/pm/pull/328), there are two main roles that Codex could play within a Waku network:

1. as a _message archival node_, or _cache_ in [SDS's](https://github.com/vacp2p/rfc-index/blob/main/vac/raw/sds.md) terminology, which serves as longer-term archival[^1] for messages, in the form of message bundles;
2. as a multicast channel for large content; i.e., as a location where uploaders push larger blobs which can then be downloaded by receivers asynchronously.

In Codex, _storage providers_ are responsible for providing storage in the network for other nodes to use. Two key aspects here, then, are:

1. who are the storage providers in this network;
2. why would they accept and bear the costs of keeping data around for others to download.

And, finally, with those questions in mind:

3. which sort of durability and availability guarantees can we provide.

## Durability, Availability, and Incentives - What Can we Simplify?

Incentives and the willingness to provide service are tightly coupled. Without incentives of some kind -- intrinsic or extrinsinc -- storage providers cannot be expected to spend resources downloading, storing, repairing, or serving foreign data[^3]. For the Status/Waku use cases, it is unclear where such incentives would be coming from.

**Altruistic hypothesis.** We are trying to simplify things here, so one could postulate that Codex and Waku, when operated in tandem, are likely to be a part of a larger application (e.g. logos core, or status). This means those could be bundled and ran as part of a single "application node".

Application users, then, seeing intrinsic value in the functioning of the application itself, would be incentivized to run both services. This means we would be able to draw from the pool of application users to store data.

If we simplify away the idea that nodes can act byzantine or selfish, then the problem reduces to:

1. dealing with faults/churn so that data remains in the network and does not get lost;
2. imposing some local cap on how much content a user can produce so they do not inadvertently use too much of the storage in the network.

Without incentives to keep application nodes online, however, or some smarter replica placement strategies, churn alone can be enough to make the problem intractable[^2].

**Simplifying away churn.** A further simplifying assumption we could make is that we run a fleet of storage nodes ourselves, or that nodes are stable for some reason. This will reduce the problem to that of dealing with faults, which should be tractable with the current content distribution/repair mechanisms we have in place.

Durability (and availability) guarantees under stronger assumptions are likely not achievable without significantly more complex incentive mechanisms, like reputation systems or the cryptoeconomic durability mechanisms that were part of our original roadmap, which need to be developed and thought out. If the conclusion is that we _need_ those, then this would rule out quick wins.

On first glance, therefore, it would not seem to be that we have a whole host of options when it comes to churning our something quick, unless we are willing to simplify things quite radically.

[^1]: Exactly how long is "longer-term" is still to be understood.
[^2]: https://www.usenix.org/conference/hotos-ix/high-availability-scalable-storage-dynamic-peer-networks-pick-two.
[^3]: They _could_ be expected to serve data for friends, relatives, or community memebers, but that would also reduce the pool of available nodes significantly (to the point of making the app unusable for certain users), and QoS would hinge on friend/community/relative resource and availability characteristics.