Copied into https://www.notion.so/pl-strflt/Kubo-0-16-Retro-a443367e799e48b7931935a924dff529

# Kubo retro

## Kudos

- :+1: :+1: :+1: :+1: lidel: landing specs :book:
- :+1: :+1: steve: bringing order to chaos :angel:
- Thanks to Hugo for discovering all these security issues. :bug:
- Thanks to Piotr for helping us with the DX and improving our day to day. :hourglass_flowing_sand:
- Adin for being very generous with his time :timer_clock:
- Thanks to Steve for keeping us on the right path
- Thanks to Antonio for delegated routing

## What went well

- :+1: :+1: release every 6 months → ~5 weeks
- Helping other teams that rely on our software (libp2p with webtransport for example)
- Reframe
- The headcount is more than the double
- We are doing specs before the functionality, and we are adding specs for old work
- We closed a lot of long-standing loose ends (hamt sharding, cid->multihash migration)
- still have cidv1 migration
- Security posture is improving
- We're starting to become proactive instead of reactive :cool:
- Maybe due to team growth and knowledge transfer?
- Multiple good external contributions (blake3, gateway file, \_redirect file)

## What could be improved

- triming the PR backlog (especially things that are 80% done) (also consider schomatis situation)
- we have so many open issues without timely correspondence
- The bot message says "within two business days" which is completely wrong.
- we should have metrics about issues not meeting "SLA", maybe bug us in Slack
- Even changing the release cadence, we can land too few new functionality on every release because (I think) we have too much technical debt unresolved.
- Sharness (I would like to make a grant about that)
- grant would be for porting all tests to Go
- DX/UX
- "Official Kubo RPC client libraries" -- still a mess ([JS (*wip*)](https://github.com/ipfs/kubo/issues/9125), [GO (🫣)](https://github.com/ipfs/kubo/issues/9124))
- "Unofficial Kubo RPC client libraries" (e.g., [Python](https://github.com/ipfs-shipyard/py-ipfs-http-client/issues/316), [Java](https://github.com/ipfs-shipyard/java-ipfs-http-client/issues/194)) -- lacking maintenance
- ~~What is Java ?~~ kek
- MultiRepo overhead -- multiple PRs to make changes, even when you know what to do (imagine being external contributor)
- Reframe not default (on gateways ?)
- we are quite bad at estimating effort and maintenance costs (results in overcommitting and getting stretched too thin) :+1:
- The way we handle breaking changes in core libraries AND/OR have no regression tests that would guard against regressions
- case study: https://github.com/ipfs/go-cid/issues/144 (what would happen if I did not react? bit scary that we most likely have such regressions happening in other places and nobody notices + no tests to detect regressions in libs around ecosystem-wide core concepts like codecs)
- We accept third party bytes from random peers, but we rarely have any fuzzing tests
- There are user cohorts that we have very little knowledge of how they're using our products
- We prefer shiny things instead of improving and maintaining the base.
- reid: hire a TPM to do specs
- we don't have a formal threat model for IPFS, so weighing security is very ad-hoc
- we were surprised by other peoples' plans for IPFS (e.g. indexers)
- WTF is going with IPVM ?
- We should work more than one in a feature/functionality/fix.

## todo

- @Jorropo write a document about goals and milestone for a sharness removal in favor of `go test`
(Must exercise the binary end to end, use easy to use go based system, ...)
- reid: TPM for specs
- @Jorropo bootstrap threat model for Kubo then review it with the team
- A lot of ideas on where to improve things, no time to execute them.
- @Galargh kill welcome bot "two business days"
- lidel: create issue for consolidating go api clients
- add task to archive all ipfs repos in ipfs-shipyard
- check w/ lidel
- guseggert: get involved w/ ipvm wg

## learnings

- significant projects should have at least 2 people working on them full-time (for knowledge dissemination)