Historically forges provided an ad-hoc storage for release assets (binaries, source tarbals, etc.) so they do not need to be committed to a repository. Not only were repositories not designed with that in mind, it would also have inflated them by an order of magnitude: the source code is usually a lot smaller than the release assets.
More recently forges started to provide support for existing software repositories (OCI registry, Debian, PyPI, etc.), with a protocol (mostly) compatible with the standard implementation.
It has also become a common practice for user written comments to include not only text but also binary blobs which could be images, text files or other content type.
F3 currently only supports:
- attachments
- release assets
But it should also include:
- software repositories
Even though only a minority of forges (see column H) provide support for software registries, with various levels of compatibility with the required protocols, the adoption and support is growing. There are a few listed in the Wikidata forge project so they can be used as qualifiers of a forge that supports software repositories. This represents an exhaustive inventory of what is supported at a given point in time.
All three (attachements, release assets, and software repositories) are fully represented by metadata (see release asset and, for instance the MIME type (content-type field)) and a content addressable blob.
Any thoughts on how software repositories should look like in F3?