forgejo-contrib-federation-issues-41.md
Watch21
Star82
Fork
You've already forked federation
CodeIssues 16Pull requests 8Projects 2ActivityActions
Open
opened 2025-06-30 11:22:47 +02:00 by mahlzahn · 7 comments
mahlzahn commented 2025-06-30 11:22:47 +02:00
Collaborator
Copy link
First, I try to give an overview of what these terms mean for Forgejo:
| Term | Forgejo definition | Federation comment |
|---|---|---|
| Fork | Copy origin code, add own code, PRs to origin, no active synchronization (maybe default branch) | |
| Mirror | Copy origin code, no additions allowed, keep synchronized | |
| Migration | Copy origin code, issues/PRs, meta data, etc., do not synchronize | May be extended to move stars/watchers over |
| Follow | n/a | May be introduced to keep a synchronized, integrity-verified copy |
| Term | Forgejo definition |
|---|---|
| Watch | Be notified about activities in issues/PRs |
| Star | Express love, no other interaction |
First, I try to give an overview of what these terms mean for Forgejo: ### Repositories Term | Forgejo definition | Federation comment --- | --- | --- Fork | Copy origin code, add own code, PRs to origin, no active synchronization (maybe default branch) | Mirror | Copy origin code, no additions allowed, keep synchronized | Migration | Copy origin code, issues/PRs, meta data, etc., do not synchronize | May be extended to move stars/watchers over Follow | n/a | May be introduced to keep a synchronized, integrity-verified copy ### User actions Term | Forgejo definition --- | --- Watch | Be notified about activities in issues/PRs Star | Express love, no other interaction
mahlzahn referenced this issue from forgejo/sustainability 2025-06-30 11:24:08 +02:00 NLnet funding for next federation step ? #108
jerger commented 2025-06-30 11:28:06 +02:00
Owner
Copy link
Nice but -
fork- / mirror- / migration- / (maybe follow)-relation is sth. that happens between repos.
The watch- and stare-relation is more sth like
Nice but - fork- / mirror- / migration- / (maybe follow)-relation is sth. that happens between repos. The watch- and stare-relation is more sth like * User u1 watches repo r1 * User u1 stars repo r1
👍 1
jerger commented 2025-06-30 11:30:25 +02:00
Owner
Copy link
And related to our star discussion:
And related to our star discussion: 1. Would fork imply that stars are caried over & synchronized ? 2. Would mirror imply that stars keept synchronized? 3. I assume migration will also migrate stars.
mahlzahn commented 2025-06-30 17:57:56 +02:00
Author
Collaborator
Copy link
@jerger wrote in #41 (comment):
Find below, my opinionated thoughts on that topic.
And related to our star discussion:
- Would fork imply that stars are caried over & synchronized ?
I'd say no. A fork is an own thing that is kind of decoupled from from the origin. In particular it allows to modify the code (introduce vulnerabilities, etc.) and you don't want that your stars are kept on forks.
- Would mirror imply that stars keept synchronized?
That depends much on what we define as mirror. The current Forgejo mirror shouldn't have synchronized stars for the same reason as for forks.
In my opinion, star lists may only be federated if integrity checks are in place. Thus, the still to be defined "follow" (or other term not to be confused with "watch") may be a candidate for synchronizing code, issues?, PRs?, releases?, …, and stars? (in general, makes me realize that integrity and verification are crucial for federating code forges.)
- I assume migration will also migrate stars.
I'd say yes. A migration is usually done with the goal to remove/archive the old repo (or convert it to a mirror?). But it would need a verification from the old origin (just like now issues, PRs, releases, … are only migrated if a valid owner token was given).
There might be a necessary extra step to think about. E.g., in Mastodon, stars and follows are migrated from one account to another by moving them, means removing them from the other. You don't want that your given stars (and follows) are "multiplicating" if a repo is migrated.
@jerger wrote in https://codeberg.org/forgejo-contrib/federation/issues/41#issuecomment-5656013: Find below, my opinionated thoughts on that topic. > And related to our star discussion: > > 1. Would fork imply that stars are caried over & synchronized ? I'd say no. A fork is an own thing that is kind of decoupled from from the origin. In particular it allows to modify the code (introduce vulnerabilities, etc.) and you don't want that your stars are kept on forks. > 2. Would mirror imply that stars keept synchronized? That depends much on what we define as mirror. The current Forgejo mirror shouldn't have synchronized stars for the same reason as for forks. In my opinion, star lists may only be federated if integrity checks are in place. Thus, the still to be defined "follow" (or other term not to be confused with "watch") may be a candidate for synchronizing code, issues?, PRs?, releases?, …, and stars? (in general, makes me realize that integrity and verification are crucial for federating code forges.) > 3. I assume migration will also migrate stars. I'd say yes. A migration is usually done with the goal to remove/archive the old repo (or convert it to a mirror?). But it would need a verification from the old origin (just like now issues, PRs, releases, … are only migrated if a valid owner token was given). There might be a necessary extra step to think about. E.g., in Mastodon, stars and follows are migrated from one account to another by moving them, means removing them from the other. You don't want that your given stars (and follows) are "multiplicating" if a repo is migrated.
jerger commented 2025-07-01 09:37:55 +02:00
Owner
Copy link
I added your definition here - to keep it :-)
I added your definition here - to keep it :-) https://codeberg.org/forgejo-contrib/federation/commit/bb20c55d2a1de101e4162df644e1d802525eeb19
jerger commented 2025-07-01 09:51:16 +02:00
Owner
Copy link
@mahlzahn wrote in #41 (comment):
- Would mirror imply that stars keept synchronized?
That depends much on what we define as mirror. The current Forgejo mirror shouldn't have synchronized stars for the same reason as for forks.
We intent to use the sync of star for our mirrors - e.g. this one:
https://repo.prod.meissa.de/meissa/c4k-monitoring#development-mirrors
But I agree, sync of star might not apply to every mirror.
In my opinion, star lists may only be federated if integrity checks are in place. Thus, the still to be defined "follow" (or other term not to be confused with "watch") may be a candidate for synchronizing code, issues?, PRs?, releases?, …, and stars? (in general, makes me realize that integrity and verification are crucial for federating code forges.)
Agree on this. Do you want to add this to your definition?
- I assume migration will also migrate stars.
There might be a necessary extra step to think about. E.g., in Mastodon, stars and follows are migrated from one account to another by moving them, means removing them from the other. You don't want that your given stars (and follows) are "multiplicating" if a repo is migrated.
Why not ?
From view point of stargazer there are two copies of his given star. That might have potential for confusion (update list of stargazers stars, giving two instead of one) - we have to solve. But this confusion also applies to other items (author of doubled issues, ...)
From view point of repo ... both copies are the same.
Migrate implies the old copy will be deleted / archived. But I assume this process step might stay a manual one ...
@mahlzahn wrote in https://codeberg.org/forgejo-contrib/federation/issues/41#issuecomment-5660897: > > 2. Would mirror imply that stars keept synchronized? > > That depends much on what we define as mirror. The current Forgejo mirror shouldn't have synchronized stars for the same reason as for forks. We intent to use the sync of star for our mirrors - e.g. this one: https://repo.prod.meissa.de/meissa/c4k-monitoring#development-mirrors But I agree, sync of star might not apply to every mirror. > In my opinion, star lists may only be federated if integrity checks are in place. Thus, the still to be defined "follow" (or other term not to be confused with "watch") may be a candidate for synchronizing code, issues?, PRs?, releases?, …, and stars? (in general, makes me realize that integrity and verification are crucial for federating code forges.) Agree on this. Do you want to add this to your definition? > > 3. I assume migration will also migrate stars. > > There might be a necessary extra step to think about. E.g., in Mastodon, stars and follows are migrated from one account to another by moving them, means removing them from the other. You don't want that your given stars (and follows) are "multiplicating" if a repo is migrated. Why not ? From view point of stargazer there are two copies of his given star. That might have potential for confusion (update list of stargazers stars, giving two instead of one) - we have to solve. But this confusion also applies to other items (author of doubled issues, ...) From view point of repo ... both copies are the same. Migrate implies the old copy will be deleted / archived. But I assume this process step might stay a manual one ...
patdyn commented 2025-07-01 17:31:03 +02:00
Owner
Copy link
Let me hop into this discussion as well, i've been following it for a bit and do like the idea to clarify definitions of terms. :)
@mahlzahn wrote in #41 (comment):
First, I try to give an overview of what these terms mean for Forgejo:
Repositories
Term Forgejo definition Federation comment
Fork Copy origin code, add own code, PRs to origin, no active synchronization (maybe default branch)
Mirror Copy origin code, no additions allowed, keep synchronized
Migration Copy origin code, issues/PRs, meta data, etc., do not synchronize May be extended to move stars/watchers over
Follow n/a May be introduced to keep a synchronized, integrity-verified copyUser actions
Term Forgejo definition
Watch Be notified about activities in issues/PRs
Star Express love, no other interaction
For Mirror:
I think the Forgejo Def of Mirror is:
Create a new repo of the same name, pull or push the origin code and periodically synchronize the code one way. Depending on the direction of the mirror (push or pull) code will be pushed to remote/distant/foreign server or pulled from it. As the mirrored repository lives on its own, it can actually be modified even though this could potentially cause trouble with sync.
For Follow:
When reading "Follow" I interpret it in the fediverse way: Basically getting updates from that user in my feed.
Translating that to forgejo, given repo2 follows repo1:
Let me hop into this discussion as well, i've been following it for a bit and do like the idea to clarify definitions of terms. :) @mahlzahn wrote in https://codeberg.org/forgejo-contrib/federation/issues/41#issue-1897178: > First, I try to give an overview of what these terms mean for Forgejo: > ### Repositories > Term Forgejo definition Federation comment > Fork Copy origin code, add own code, PRs to origin, no active synchronization (maybe default branch) > Mirror Copy origin code, no additions allowed, keep synchronized > Migration Copy origin code, issues/PRs, meta data, etc., do not synchronize May be extended to move stars/watchers over > Follow n/a May be introduced to keep a synchronized, integrity-verified copy > ### User actions > Term Forgejo definition > Watch Be notified about activities in issues/PRs > Star Express love, no other interaction For Mirror: I think the Forgejo Def of Mirror is: Create a new repo of the same name, pull or push the origin code and periodically synchronize the code one way. Depending on the direction of the mirror (push or pull) code will be pushed to remote/distant/foreign server or pulled from it. As the mirrored repository lives on its own, it can actually be modified even though this could potentially cause trouble with sync. For Follow: When reading "Follow" I interpret it in the fediverse way: Basically getting updates from that user in my feed. Translating that to forgejo, given repo2 follows repo1: 1. Repo2 mirrors repo1 (commits, tags and branches) - We may need some mechanics to ensure integrity 2. Repo2 synchronizes stars, issues, comments, projects, PRs etc - Interactions on repo2 are synchronized to repo1 I think this is essentially what @mahlzahn already mentioned here
jerger commented 2025-07-07 09:56:31 +02:00
Owner
Copy link
Let me collect the discussion and considerations and propose the following semantic:
| Term | Forgejo definition |
|---|---|
| Fork | Copy origin git, add own code, PRs to origin, optional add PullMirror behavior. |
| PullMirror | Sync origin git, mirror might have an other owner than origin, no code changes intended on mirrors, ActivityPub Objects are not synchronized. |
| PushMirror | Sync origin git, mirror has the same owner than origin, no code changes intended on mirrors, keep ActivityPub Objects synchronized in all directions. |
| Migration | Copy origin git, ActivityPub Objects, do not synchronize, leave Tombstone on the origin side |
| Follow | Unclear semantic - not implemented between Repositories |
Reasons for my proposal are:
Let me collect the discussion and considerations and propose the following semantic: | Term | Forgejo definition | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Fork | Copy origin git, add own code, PRs to origin, optional add PullMirror behavior. | | PullMirror | Sync origin git, mirror might have an other owner than origin, no code changes intended on mirrors, ActivityPub Objects are not synchronized. | | PushMirror | Sync origin git, mirror has the same owner than origin, no code changes intended on mirrors, keep ActivityPub Objects synchronized in all directions. | | Migration | Copy origin git, ActivityPub Objects, do not synchronize, leave Tombstone on the origin side | | Follow | Unclear semantic - not implemented between Repositories | Reasons for my proposal are: 1. I think it is a good idea to differentiate between Pull- and PushMirror because of ownership. 2. Distinguish between git and ActivityPub seems useful. Maybe defining ActivityPub-Object subsets would be a good idea also? 3. Ownership is important to decide whether / which ActivityPub Objects (or subset of) to sync. 4. Fork: being able to have git synced automatically would be a huge help to me to maintain my forks (being able to sync just a subset of branches would be cool). 5. Push/PullMiror: "no additions allowed" - reword this to "intended" because this is not enforced.
jerger referenced this issue from a commit 2025-07-21 10:16:09 +02:00 update semantic to reflect https://codeberg.org/forgejo-contrib/federation/issues/41
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
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#41
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