federated-star #1680
No reviewers
Labels
No labels
arch
amd64
arch
arm6
arch
arm64
arch
arm7
arch
riscv64
backport/v1.19
backport/v1.20
backport/v1.21/forgejo
backport/v7.0/forgejo
backport/v8.0/forgejo
breaking
bug
bug
confirmed
bug
duplicate
bug
needs-more-info
bug
new-report
bug
reported-upstream
codeberg
database
CockroachDB
database
MySQL
database
PostgreSQL
database
SQLite
dependency-upgrade
dependency
ACT
dependency
alpine
dependency
asciinema-player
dependency
bleve
dependency
cache
dependency
certmagic
dependency
chart.js
dependency
Chi
dependency
Chroma
dependency
citation.js
dependency
codespell
dependency
css-loader
dependency
devcontainers
dependency
dropzone
dependency
editorconfig-checker
dependency
elasticsearch
dependency
enmime
dependency
F3
dependency
ForgeFed
dependency
garage
dependency
Git
dependency
git-backporting
dependency
Gitea
dependency
gitignore
dependency
go-ap
dependency
go-enry
dependency
go-gitlab
dependency
Go-org
dependency
go-rpmutils
dependency
go-sql-driver mysql
dependency
go-swagger
dependency
go-version
dependency
go-webauthn
dependency
gocron
dependency
Golang
dependency
goldmark
dependency
goquery
dependency
Goth
dependency
grpc-go
dependency
happy-dom
dependency
Helm
dependency
image-spec
dependency
jsonschema
dependency
KaTeX
dependency
lint
dependency
MariaDB
dependency
Mermaid
dependency
minio-go
dependency
misspell
dependency
Monaco
dependency
PDFobject
dependency
playwright
dependency
postcss
dependency
postcss-plugins
dependency
pprof
dependency
prometheus client_golang
dependency
protobuf
dependency
relative-time-element
dependency
renovate
dependency
reply
dependency
ssh
dependency
swagger-ui
dependency
tailwind
dependency
temporal-polyfill
dependency
terminal-to-html
dependency
tests-only
dependency
text-expander-element
dependency
urfave
dependency
vfsgen
dependency
vite
dependency
Woodpecker CI
dependency
x tools
dependency
XORM
Discussion
duplicate
enhancement/feature
forgejo/accessibility
forgejo/actions
forgejo/api
forgejo/branding
forgejo/ci
forgejo/documentation
forgejo/email
forgejo/federation
forgejo/furnace cleanup
forgejo/internationalization
forgejo/moderation
forgejo/privacy
forgejo/release
forgejo/scaling
forgejo/security
forgejo/ui
Gain
High
Gain
Nice to have
Gain
Undefined
Gain
Very High
good first issue
issue
closed
issue
do-not-exist-yet
issue
open
manual test
Manually tested during feature freeze
OS
FreeBSD
OS
Linux
OS
MacOS
OS
Windows
regression
release blocker
Release Cycle
Feature Freeze
release-blocker
v7.0
release-blocker
v7.0.1
release-blocker
v7.0.2
release-blocker
v7.0.3
release-blocker
v7.0.4
release-blocker
v8.0.0
run-end-to-end-tests
test
manual
test
needed
test
needs-help
test
not-needed
test
present
untested
valuable code
worth a release-note
User Research - Accessibility
User Research - bug
User Research - Config (instance)
User Research - Dashboard
User Research - documentation
User Research - Errors
User Research - feature
User Research - federation
User Research - Filters
User Research - governance
User Research - Labels
User Research - Moderation
User Research - Needs Input
User Research - Notifications
User Research - release
User Research - Repo creation
User Research - Repo Units
User Research - security
User Research - Settings (in-app)
User Research - testing
User Research - UI
User Research - UX
No milestone
No project
No assignees
9 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: forgejo/forgejo#1680
Loading…
Reference in a new issue
No description provided.
Delete branch "meissa/forgejo:forgejo-federated-star"
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?
Now you are able to federate the star action with repositories following your fork / mirror repository.
Doing so it will be no longer important at which instance of your honoring work the users express they like it.
All repository instances now are building a community of staring :-)
To test this feature you need to
setting.Federation.Enabled = trueEvery new star on your mirror instance now will federate the star action to your origin also.
At https://domaindrivenarchitecture.org/posts/2024-06-05-howto-federated-stars/ you can find a small howto for this feature.
TODOs:
(/) provide first prototype
(/) use NodeInfo instead of source attribute
(/) cache NodeInfo localy & add some threat mitigations (DOS-by-Rate, Replay-*, SlowLories)
(/) find a better mapping for federated users (externalLoginUser ?)
(/) UI star triggers a federated Like Activity (in case of mirrored repos?)
(/) Do a first MergeRequest
(/) Provide a feature-usage howto
Expect this in a followup MR
(-) introduce signature-handling
(-) implement Unlike
Architecture, security & decisions:
The documentation will eventually go somewhere in https://codeberg.org/forgejo/docs but it is fine to have it here while this is in draft stage.
46b621388fto8f6f7c405c@ -0,0 +35,4 @@// "200":// "$ref": "#/responses/ActivityPub"// TODO: Mabe we should use F3 Repo instead?Is there somewhere a good example how to create a F3 repository (or other actor)?
f3 is not ready to be used
What do you think would be better?
I think anything involving federation and repositories is too soon. inbox / outbox need to exist before that.
Heads up: Forgejo is being rebased on Gitea today (that's a weekly occurrence). It means you will need to cherry-pick your commits on top of the newer base branch for this PR and maybe resolve conflicts. You can do that on your own time, you do not need to do that today. It can be in a week or a month and you can keep working in the meantime.
Ideally Gitea would be a package that can be upgraded as any other Go package. But it is not designed in this way and the weekly rebase is the equivalent of such an upgrade, only it is more work.
If you need help doing that, feel free to reach out in the development chatroom.
will do this on upcoming fr :-)
42fe6e6d4cto1efabebc4b@ -0,0 +33,4 @@// Source identifies the system generated this Activity. Exact one value has to be specified.Source SourceType `jsonld:"source,omitempty"`}make gernerate-swagger breaks here ...
maybe ap.Actifity is not accessible by reflection ? It is also not a
swagger:model...d5c53fc35dto9057e71b2aI'm preparing Forgejo's monthly report, would you like to add a short paragraph about your work here?
Shure - we can prepare a short paragraph on Friday. Would this fit in your timeline?
Sure: even if the report is posted before it can be amended a few days later. I look forward to reading it!
@dachary here you can find some lines reporting our activities: https://codeberg.org/meissa/forgejo/src/branch/forgejo-federated-star/docs/unsure-where-to-put/blog.md
@ -0,0 +91,4 @@// Is the ActorData Struct valid?actor.PanicIfInvalid()@earl-warren At this point in code we have an valid, normalized actor-id.
If the actor does not exist in our forgejo instance, we will create a user out of the actors information. In order to keep the mapping to the original person we tend to store this actor-id in to the users website field (later on an additional field
person-idwould be a good idea).So the question is, how can we search for an actor-id stored in the users website field?
With a database query I suppose? But that's going to be slow because there is no index.
You could store the ID in the login_name field which is only used for external authentication sources. There is an index there.
Does that help?
3399546ddato69660af9fb0cffda6e1cto03b5cee1a392a80674a0to83463f0934b88e369978to35dd9c327a99d8d6485cto6fbe1d5ac2439b8b08b4to249ca24cb66d87b1426ato2d4faad15b4680f86c14to53ba45cf6a7eef7df629to9752ed8033d68b9ee5fbto1ac23e2817Could you please cherry-pick your commit(s) on top of the
forgejobranch? You will also need to change the target branch of this PR to beforgejo. You can do that by editing the title of this PR: it will show a drop down menu, under the title input area, that allows you to do select the target branch.This is the first and last time you will need to do that, Forgejo is now using the development workflow common to most Free Software projects, with a single development branch.
juhu, will do this the next days :-)
.. done :-)
7566195fd0to086c66b06a@ -0,0 +178,4 @@Passwd: password,MustChangePassword: false,LoginName: loginName,Type: user.UserTypeRemoteUser,Ref: #2465 (comment)
@ -0,0 +10,4 @@type FederatedUser struct {ID int64 `xorm:"pk autoincr"`UserID int64 `xorm:"NOT NULL"`ExternalID string `xorm:"TEXT UNIQUE(federation_mapping) NOT NULL"`That is the place, where the remote-id is stored :-)
WIP: forgejo-federated-starto forgejo-federated-starI assume this PR has many different layers and does not need to be merged altogether. Could you please extract in a separate PR the smallest possible independent subset so that I can start reviewing it independently? That would greatly help speed up the process and get things moving.
Hmm .. I am not completely sure but let's try :-)
Might work. Will such a separation help you?
How can I keep authorship informations? Cherrypick and deleting files will lead to many conflicts I assume ...
Do you have an better idea?
Splitting everything as you describe could help but it is a lot of work. I'm suggesting something simpler. Just extract one PR out of this one. Get it merged, rebase and iterate.
h759bkyo4 referenced this pull request from forgejo/website2024-05-30 12:46:07 +00:00
Very impressive work 👍
This doesn't appear to have code I could review (i18n/ui).
It is nice and small 👍
Can you please add an integration test to demonstrate it works as it should?
Can you give this PR a title that reflects its purpose?
As of today there is an environment for end-to-end testing where the integration test you just added can be repeated between two live instances instead of using a mock. If you have suggestions on how to do that, I'll follow them. Otherwise I'll figure it out, it should not be that difficult.
The CI failure is unrelated to your PR, you just need to rebase/merge the latest development branch to resolve it.
You will need this otherwise the settings form is a noop.
The end-to-end scenario passes with this PR https://code.forgejo.org/forgejo/end-to-end/pulls/196
Nice work :-)
If we follow this way down, we should expose federated objects also by api, I assume.
How do you plan to inject test-data &-config?
E.g. the federation test needs setting
federation=trueandrepository&userbeing present or absent.forgejo-federated-starto federated-starI reworked PR title & description. This is the original PR - so I collect here the description for the whole feature.
I do not understand the question? The test script runs with Forgejo instances where
[federation].ENABLED=trueand they create the user, repository and click on the star.For current test the setup is completely fine. But for future tests it might be good to know how you plan to adjust data.
How can I add a specific, lets say, user to the TWO_HOST ?
The CI failure is unrelated, you should merge the current development branch to get rid of it.
Using the API with something similar to
$TWO_CURL api_json --data '{"name":"test","auto_init":true}' $TWO_HOST_PORT/api/v1/user/repos. It has an admin token and can do whatever you want.For the record, I merged instead of squash merging. That's a mistake and I would normally not try to fix it. Except in this case it landed over 500 commits in the development branch and that's a little too much noise, it makes the history very difficult to read. So I fixed my mistake as follows:
forgejoc01b10a593git merge --squash wip-federatedwherewip-federatedis1be80cfdbcdd0cabdaa4tofeat(federated-star) star repositories via ActivityPub (#1680)forgejoforgejo