The current threat model for F3 is that of any archive found in the wild: it is up to the software using it to be careful about what it contains. As for the integrity of the F3 archive as a whole, there are two cases I can think of:
- The F3 archive is stored in a repository that provides authorship verification. For instance, the F3 archive can be stored in a git repository and the commit signing a particular change can be verified to match a given OpenPGP public key.
- The F3 hierarchy is bundled into a known archive format such as tar and the file is associated with a SHA256 and/or a cryptographic signature that can be traced by to a trusted author.
In both cases I do not think this is something that needs to be represented as part of F3.
In the context of F3 being used as a backend for Federation, for instance to represent an intermediary state when processing a Forgefed message received via ActivityPub, it is also up to the server and client to figure out if they can trust each other and to which extent. For instance, if an issue comment is received from a forge that supports F3, the client may elect to obtain the full thread in which this comment is included using F3, as long as it can establish that this server can be trusted or not. Maybe it can be trusted for incoming ActivityPub message. But maybe it cannot be trusted to pull F3 data out of it.
The ActivityPub side of the threat model also saw recent development as part of the Forgejo project.
My immediate conclusion is that there is no need for F3 to do more than what it currently does. Except maybe document why and how it is not responsible for embedding digital signatures and other forms of integrity cheks.
Thoughts?