forgejo-contrib-federation-issues-72.md
Watch21
Star82
Fork
You've already forked federation
CodeIssues 16Pull requests 8Projects 2ActivityActions
PublicKey table for scalability #72Open
opened 2025-11-10 21:05:07 +01:00 by 0xllx0 · 0 comments
0xllx0 commented 2025-11-10 21:05:07 +01:00
Collaborator
Copy link
Currently, the PublicKey is stored in the Actor database entry, e.g. FederationHost.
As discussed in Milestone 1, it may provide better scalability and flexibility to create a separate publickey table in the forgejo database.
One possible path forward could be to create a models/forgefed/publickey.go package file, with a struct that looks like:
type PublicKey struct {
ID int64 `xorm:"pk autoincr"`
Key sql.Null[sql.RawBytes] `xorm:"BLOB"`
}
Then, each referencing Actor type, e.g. FederationHost, could modify their PublicKey entry to reference the publickey table:
type FederationHost struct {
...
PublicKeyID int64 `xorm:"REFERENCES(publickey, id)"`
}
This would allow multiple Actor types to use the same PublicKey if the same meta-Actor owns all of those resources. For example a single organization owning multiple repositories, using the same PublicKey entry for each. Since our Repository, PatchTracker, and TicketTracker are under the same resource, a more likely situation would be an organization using the same PublicKey for their Repository, PatchTracker, and TicketTracker.
We may want to consider adding extra metadata to the PublicKey entry, such as an OwnerID that references the user table, or something similar.
Currently, the PublicKey is stored in the Actor database entry, e.g. FederationHost. As discussed in Milestone 1, it may provide better scalability and flexibility to create a separate publickey table in the forgejo database. One possible path forward could be to create a models/forgefed/publickey.go package file, with a struct that looks like: go type PublicKey struct { ID int64 `xorm:"pk autoincr"` Key sql.Null[sql.RawBytes] `xorm:"BLOB"` } Then, each referencing Actor type, e.g. FederationHost, could modify their PublicKey entry to reference the publickey table: go type FederationHost struct { ... PublicKeyID int64 `xorm:"REFERENCES(publickey, id)"` } This would allow multiple Actor types to use the same PublicKey if the same meta-Actor owns all of those resources. For example a single organization owning multiple repositories, using the same PublicKey entry for each. Since our Repository, PatchTracker, and TicketTracker are under the same resource, a more likely situation would be an organization using the same PublicKey for their Repository, PatchTracker, and TicketTracker. We may want to consider adding extra metadata to the PublicKey entry, such as an OwnerID that references the user table, or something similar.
0xllx0 added this to the Milestone 1: Enhance Signature Handling for Actors milestone 2025-11-10 21:05:07 +01:00
0xllx0 referenced this issue from forgejo/forgejo 2025-11-11 14:27:15 +01:00 feat(federation): create separate public key table #10074
0xllx0 referenced this issue 2025-11-12 10:14:55 +01:00 architecture: add FederationPublicKey table #73
jerger referenced this issue from a commit 2025-12-18 10:46:08 +01:00 architecture: add FederationPublicKey table (#73)
Sign in to join this conversation.
No Branch/Tag specified
main
feat/add-generated-threat-analysis
n0toose/admin-panel
n0toose/readme-forgefed-mention
n0toose/ap-username-changes
ap-username-changes-for-pr-9254
adr-signing-and-encryption
No results found.
Labels Clear labels No items
No labels
Milestone
Clear milestone
No items
No milestone Milestone 1: Enhance Signature Handling for Actors
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
Notifications Subscribe
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
No due date set.
Dependencies
No dependencies set.
Reference
forgejo-contrib/federation#72
WritePreview
Loading…
Add table
| Rows | | | Columns | |
CancelOK
Add a link
Url Description Hint: With a URL in your clipboard, you can paste directly into the editor to create a link.
CancelOK
CancelSave
Reference in a new issue
Repository
forgejo-contrib/federation
Title
Body
Create issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
No Yes