Best home for specs?

[samajammin]

Meta question - where is the best "home" to serve as the canonical spec for any given project?

Love this initiative overall but I'm not sure this repo is the best place to do it. Doesn't it make sense to have the Semaphore (#9) spec or Excubiae spec (#8) within the respective Semaphore & Excubiae repos? My hunch is that would be the default expectation of someone looking to learn about a project (though I also see benefit in having a centralized hub to browse/view specs). It also seems like a more fitting maintenance workflow (e.g. if the protocol changes, to change the spec in the same PR).

Thoughts @oskarth?

[oskarth]

Just seeing this now. Good question, it came up previously. Here's my response from chat:

• While this might make sense if you’re just looking at "this one project spec," there's a reason IETF, EIPs, etc., exist as their own thing. Imagine if every EIP had its own GH repo, process, website—it’d be chaos.
• Individual projects can die or pivot, but a neutral spec repo keeps the knowledge alive.
• A better review process means more eyes on the spec, better security, and stronger standards (like IETF, EIPs).
• Easier to get outside contributors involved when there’s a known place/process instead of reinventing the wheel every time.
• If every project keeps its own specs, best practices get siloed; a central repo keeps things in sync.
• Neutral ground—rather than feeling like internal docs buried in a repo, a dedicated spec repo signals it’s for the whole ecosystem, not just one team.
• Easier coordination—when specs live together, cross-project discussions happen more naturally. Not every spec maps 1:1 to a single project, especially as things scale.

(conversation continued a bit with Thore in DM, can also add you to chat for context)

[AtHeartEngineer]

@oskarth should you try to get WAKU specs moved here?

[oskarth]

@AtHeartEngineer which one? There are probably 50 of them :D I think most aren't related to ZK and think they got a spec process that works quite really well, culturally and technically.

RLN primitive specifically I agree belongs here; I suggest this can be discussed between people work are working on / familiar with RLN at PSE and Vac team.