forgejo-contrib-federation-issues-42.md
Watch21
Star82
Fork
You've already forked federation
CodeIssues 16Pull requests 8Projects 2ActivityActions
Open
opened 2025-06-30 12:24:09 +02:00 by jerger · 10 comments
jerger commented 2025-06-30 12:24:09 +02:00
Owner
Copy link
Discussion around forgejo/sustainability#108
@famfo asked here: https://md.ccc.ac/PZV1EZJNSym0PZF56Qmzng?view#Decisions-for-different-steps-and-potential-implementation
Discussion around https://codeberg.org/forgejo/sustainability/pulls/108 @famfo asked here: https://md.ccc.ac/PZV1EZJNSym0PZF56Qmzng?view#Decisions-for-different-steps-and-potential-implementation
jerger commented 2025-06-30 12:31:36 +02:00
Author
Owner
Copy link
Instead of enhancing the scope by "search" we can follow the scenario user-forks-a-foreign-repo-initiated-by-distant
The needed information is transported by a http get + parameter.
Or we can follow the scenario user-forks-a-foreign-repo-initiated-by-local
In this case, the distant server shows the repoID and we can copy past it for our fork process.
Instead of enhancing the scope by "search" we can follow the scenario user-forks-a-foreign-repo-initiated-by-distant https://codeberg.org/meissa/fork-repo-usecase-variants/src/branch/main/usecase\_fork.md#user-forks-a-foreign-repo-initiated-by-distant The needed information is transported by a http get + parameter. Or we can follow the scenario user-forks-a-foreign-repo-initiated-by-local https://codeberg.org/meissa/fork-repo-usecase-variants/src/branch/main/usecase\_fork.md#user-forks-a-foreign-repo-initiated-by-local In this case, the distant server shows the repoID and we can copy past it for our fork process.
jerger changed title from ** Do we need search for fork? ** to Federated Fork: Do we need search for fork? 2025-06-30 13:00:47 +02:00
famfo commented 2025-06-30 14:44:59 +02:00
Collaborator
Copy link
I don't think that this is strictly needed but it would definitely be convenient to implement webfinger features early on for (ties into #44, I think we have opposite viewpoints on this ^^'). I think a good example here is how eg. the Mastodon frontend handles this: using the search field you can search for
@[email protected] or their URL https://example.com/users/userTo be able to fetch objects by the URL, all of them will need to redirect to their AP API endpoint when fetched using Accept: application/activity+json.
I don't think that this is strictly needed but it would definitely be convenient to implement webfinger features early on for (ties into #44, I think we have opposite viewpoints on this ^^'). I think a good example here is how eg. the Mastodon frontend handles this: using the search field you can search for - already known users, posts and hashtags - fetching objects from their handle @[email protected] or their URL https://example.com/users/user To be able to fetch objects by the URL, all of them will need to redirect to their AP API endpoint when fetched using Accept: application/activity+json.
jerger commented 2025-06-30 15:09:46 +02:00
Author
Owner
Copy link
Related work to mention:
Related work to mention: * https://codeberg.org/meissa/forgejo/pulls/24 * https://codeberg.org/forgejo-contrib/federation/src/branch/main/FederationRoadmap.md#federated-repo-search-discovery
jerger commented 2025-06-30 15:22:26 +02:00
Author
Owner
Copy link
Option "keeping search out of the Proposal":
Option "keeping search out of the Proposal": * We can implement https://codeberg.org/forgejo-contrib/federation/src/branch/main/FederationRoadmap.md#federated-repo-search-discovery independent. * Stay focused on Fork & PR * Later introduction of search & webfinger (I consider this to be two different things) is possible. Maybe introduction of webfinger will cause a migration for existing.
jerger commented 2025-06-30 15:22:43 +02:00
Author
Owner
Copy link
Option "having search in our Proposal":
Option "having search in our Proposal": * search & webfinger would be the first things to implement. * to make this user-visible we've to create a search ui. * I would consider this to be two building blocks - each of them with narrow cases ... * I fear, we will not be able to reach the "create PR" userstory.
famfo commented 2025-06-30 15:47:43 +02:00
Collaborator
Copy link
I think at least a basic search (ie. fetching objects by their URL) would still be nice to have, especially or the user-forks-a-foreign-repo-initiated-by-local scenario. This would require the following two changes:
Accept: application/activity+json header on all normal repository / users paths to redirect to the API endpointI think at least a basic search (ie. fetching objects by their URL) would still be nice to have, especially or the user-forks-a-foreign-repo-initiated-by-local scenario. This would require the following two changes: 1. when a URL is put into the search bar, try to fetch the remote object via AP and maybe display it 2. checking for the Accept: application/activity+json header on all normal repository / users paths to redirect to the API endpoint
jerger commented 2025-06-30 16:32:45 +02:00
Author
Owner
Copy link
@famfo wrote in #42 (comment):
I think at least a basic search (ie. fetching objects by their URL) would still be nice to have, especially or the user-forks-a-foreign-repo-initiated-by-local scenario. This would require the following two changes:
1. when a URL is put into the search bar, try to fetch the remote object via AP and maybe display it
I've respect for a federated search for e.g. "forgejo /sep/ [email protected]". This would mean:
We send a search activity to the distant server.
in terms of non blocking ui this would be async?
for reducing network traffic we should have an cache peristed on local?
If the distant server answers
what to do if we get an error?
we display the answer.
how do we update the async response?
2. checking for the `Accept: application/activity+json` header on all normal repository / users paths to redirect to the API endpoint
Yes. We can use this - even if we leave the search part to google search at the moment.
Btw - do you know the spec describing this kind of ID-resolution?
@famfo wrote in https://codeberg.org/forgejo-contrib/federation/issues/42#issuecomment-5658791: > I think at least a basic search (ie. fetching objects by their URL) would still be nice to have, especially or the user-forks-a-foreign-repo-initiated-by-local scenario. This would require the following two changes: > > 1. when a URL is put into the search bar, try to fetch the remote object via AP and maybe display it I've respect for a federated search for e.g. "forgejo /sep/ [email protected]". This would mean: 1. We send a search activity to the distant server. 1. in terms of non blocking ui this would be async? 2. for reducing network traffic we should have an cache peristed on local? 2. If the distant server answers 1. what to do if we get an error? 3. we display the answer. 1. how do we update the async response? > 2. checking for the Accept: application/activity+json header on all normal repository / users paths to redirect to the API endpoint Yes. We can use this - even if we leave the search part to google search at the moment. Btw - do you know the spec describing this kind of ID-resolution?
jerger commented 2025-06-30 16:34:28 +02:00
Author
Owner
Copy link
My proposal is not to drop search forever.
My proposal is not to force us, to implement it now.
We could "search" add as optional userstory and implement it if there is time left (which I do not believe in) ... or we can decouple it more and you create an additional "search" application at NLnet?
My proposal is not to drop search forever. My proposal is not to force us, to implement it now. We could "search" add as optional userstory and implement it if there is time left (which I do not believe in) ... or we can decouple it more and you create an additional "search" application at NLnet?
jerger commented 2025-07-01 09:52:24 +02:00
Author
Owner
Copy link
And I understand search is the more important thing to you.
In a volunteer area it is completly fine to vote by feet - everybody can push what he decides to be important.
But if we apply to get funding, it would be better to find a compromise and head for a common line.
I am asking myself are there reasons we can decide along or are there just opinions?
And I understand search is the more important thing to you. In a volunteer area it is completly fine to vote by feet - everybody can push what he decides to be important. But if we apply to get funding, it would be better to find a compromise and head for a common line. I am asking myself are there reasons we can decide along or are there just opinions?
jerger commented 2025-07-02 14:23:37 +02:00
Author
Owner
Copy link
Updated proposal, included your feedback & added details:
forgejo/sustainability@1840f27e78
@famfo what do you think?
Updated proposal, included your feedback & added details: https://codeberg.org/forgejo/sustainability/commit/1840f27e78c9eed09c551ba7bc5c2dccee902e38 @famfo what do you think?
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#42
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