[gsaslis]

Yes, this is how radicle stores this data. ; )

https://app.radicle.xyz/nodes/seed.radicle.xyz/rad:z3trNYnLW...

[gsaslis]

https://docs.radicle.xyz/guides/protocol is probably a better resource (but this guide is still Work In Progress)

[est]

> Radicle’s predefined COB types are stored under the refs/cobs hierarchy. These are associated with unique namespaces, such as xyz.radicle.issue and xyz.radicle.patch, to prevent naming collisions.

This looks like an interesting approach. I have question, to avoid copy a large .git project, we have partial cloning and cloning depth. If `cobs` grows too large, how can we partially clone it? Like select issues by time range?

[account42]

> a standard way of storing project management metadata alongside version control data

Emphasis mine. Doesn't seem to be it seening as this is yet another home grown issue storage.

[9dev]

Yeah, exactly. Radicle doing it this way, Fossil another - see here why that is a problem: https://xkcd.com/927/