# "Working groupathon" for new Codex design

We have two weeks to agree on a new system design for Codex that meets the requirements of Waku and Status Desktop, being usable for their specific use cases (mainly archival and file sharing). In addition, the design needs to support progressive enhancement towards real durability (eg utilising cryptoeconomic incentives).

## Design goals

The main goal of this design effort is to create a protoype for replacing [bittorrent in status-go](https://github.com/status-im/status-go/blob/develop/protocol/messenger_communities.go#L3783). We have [until Nov 15](https://roadmap.logos.co/codex/updates/2025-08-04#roadmap) to get this done. Requirements can be relaxed (eg must work on mobile devices) and assumptions can be made to meet this goal, as long as they are explicitly written.

Secondarily, using the prototype design, write milestones for a phased approach to durability. This is more of a long term design, and it should support [Status Desktop/Mobile](https://github.com/status-im/status-desktop/pull/18483) and [Waku](https://github.com/waku-org/pm/pull/328) use cases. We do not need an *exact* design for all future phases; we need a design of how we can hit our first milestone and then a possible high-level phased approach to getting to durability in the future. For this secondary goal, we should not be relaxing requirements.

### Possible strategy
Each group can do what they want, but a possible strategy could be to add many assumptions and relax as many requirements as needed to hit the first milestone. Then, the following phases would introduce less assumptions and more requirements. For example, the first milestone would likely not have repair or remote auditing in it. So an assumption would be that there are no probabilistic gurantees that the data is not lost if the uploading node goes offline. Then, there would be a future phase that adds remote auditing. And then a future phase again that adds repair, at which point the requirement for probabilistic guarantees can be met.

## Agenda

**Week 1: 18-22 August**
The main goal of the first week is for each working group to agree upon a design and create a presentation of the design to present their idea to the entire team.

1. Split off into groups and meet (create your own schedules)
2. Create a design.
3. Deliverable: **recording** of presentation of design in whatever format suits

**Week 2: 25-29 August**
The main goal of week 2 is to come up with an agreed upon design that we will start writing specs for the following week.

*Exact schedule for this week is a work in progress, as it will depend on Giuliano's availability and time zones.*

1. **Mon**
- Review recorded presentations and write any questions or discussion points in a thread in discord [async]
- discuss designs [async]
2. **Tues-Fri**
- Daily meeting (time TBD) for freeform discussion meeting to scrutinise designs
- If vote concludes earlier than friday, no further meetings needed
- Main goal: vote on a final design
- Amendments to incorporate feedback or include new ideas?

## Working groups

### Group 1 🇳🇱
- Marcin
- Ben
- Mo
- (Giuliano)
- (Balazs)

Our proposal video: https://drive.proton.me/urls/0D3VX0Q8VM#EWf9Kb5QPbXo

### Group 2 🌍
- Rahul
- Arnaud
- Eric
- Adam

## Voting criteria
Groups will vote on their preferred design after presentations. Groups should weigh their decisions based on the following:
1. Meets the requirements of the first milestone (replace bittorrent in status-go)
2. Meets requirements and design goals in future phases
4. Reuse of existing codebase
5. ability to progressively support durability
6. Design considerations
* performance
* throughput
* retrieval time
* scalability (same as above)
* fault tolerance

**Other (may be subjective):**
1. Lower design complexity
1. Higher productivity potential
1. Potential market beyond Logos (additional use cases)
1. Adheres to Logos principles (privacy, anonymity, censorship-resistance)
1. Supports a community