## the case for protocol specs

@oskarth
november, 2024
pse event in chiang mai

---

## outline

- what protocol specs are, what they are not
- why write them, how to write them
- my experience
- the pse position and how pse can do specs

Note:
term sometimes overloaded, e.g. standard vs spec
we are working on protocols but don't have culture of specs
poorly understood; I have experience, so I wanted to share

---

## what is a protocol spec?

- focuses on "what" a protocol does, as opposed to "how"
- the most valuable artifact of a protocol
- (protocols can be explicit or implicit)
- especially if goal is credible neutrality
- a living thing; part of the lifecycle of protocol development

---

## examples

- all core computer, internet and crypto infrastructure
- tcp/ip, http/https, tls/ssl, unix/posix, rsa, x3dh/double ratchet...
- bitcoin bips, ethereum eips, ietf rfcs, ...
- vac rfcs, pse rfcs?

---

## some good and bad specs

- good: [tls 1.3](https://datatracker.ietf.org/doc/html/rfc8446#page-10), [eth networking](https://ethereum.github.io/consensus-specs/specs/phase0/p2p-interface/), [rln v1 (simple)](https://rfc.vac.dev/vac/32/rln-v1)
- failure modes:
- missing spec: only docs (most ~web2 things)
- not reliable (out of date)
- ambigious, ref client rules (bitcoin, torrent)
- insecure, underspecified (wep, ftp, oauth)
- complex (oauth 2.0, xmpp, http 2)

---

## why specs

- provides clear protocol requirements and security guarantees
- enables rigorous reasoning and security analysis
- supports robust development and evolution
- enables multiple implementation and modular changes
- serves as reference and communication tool
- authoritative documentation for all stakeholders

---

## what a spec is not

- a program or circuit
- documentation on how to use software
- an internet standard
- something you outsource
- something you write once
- something very difficult to write
- an academic exercise

---

## what a spec is

- a living document
- the most valuable asset of a protocol
- communication tool, framework for growth
- a cultural process, a mindset shift
- something that starts of very small
- part of the protocol lifecycle with a "contract"
- raw (editor), draft (+devs), stable (+users), deprecated, retired

---

## my experience

- whisper neglected, inconsistent implementations
- waku specified clearly, enabling
- more confidence among users, multiple implementations, papers,
- easier to evolve, onboard devs, rigorous security guarantees, modularity, ...
- vac rfc cultural onboard, part of protocol dev process, collected in one place
- many, many specs; also with pse rln-v1 spec

---

## how pse can write specs

- make it part of culture, start small, mindset shift
- don't rely on other people to do X
- write specs for own projects first
- separately, look for standards adoption (orthogonal, easier with specs in place)
- use existing knowledge (zk-evm, eip editors)
- pick some method and collect specs in one place
- eip, coss (lightweight), etc - keep it consistent, accessible and live

---

## the pse position

- not a for-profit company with goal to make money, or proprietary software
- what can pse do that other orgs can't? => credible neutral, public good protocols
- schelling point, philosophy of subtraction
- in service of real-world impact and adoption
- thought experiment: if pse disappears tomorrow, what does it leave behind?
- a fortran program and analog tv cables?
- ...or a set of protocol specs people can implement and evolve?

---

## thanks

q&a, discussion