1.8 KiB
Federated following
Inboxes/outboxes
https://github.com/go-gitea/gitea/issues/14186 has an in-depth overview of what needs to happen for this
let's start with something basic and worry about unit tests and moderation later
inboxes: POST request comes in add to database check which kind of request it is use callbacks or something to run the proper handing function if it's a follow request: use the user_model create follow function add an accept activity to the outbox
outboxes: (done, needs to be tested) function to add to outbox add to database Check the to field (C2S) for which actor to forward this to (technically there are to, bto, cc, bcc, and audience but that's too much for now) do a POST request with httpsigs using the activitypub.client stuff
Remote users
Use the existing users table.
https://github.com/go-gitea/gitea/issues/9045
I think we will also need to implement WebFinger because this is the de-facto standard for resolving a username like @ta180m@git.exozy.me into the actor IRI like https://git.exozy.me/api/v1/activitypub/user/ta180m
Also, for the federated following UI, I propose that if no user is logged into the current instance, there should be a popup box for the user to type in their own instance, and then the remote user should be rendered on their own instance.
Since user table already has two types column, one is LoginType which could be NoType, Plain, LDAP, SMTP, PAM, DLDAP, OAuth2,SSPI. Another column is UserType which could be Individual or Organization. We can have a new value for LoginType if reuse user table. Federate, but we need another table to store extra information. Maybe external_login_user table. And every external Gitea instance could be added as a record in login_source A login_source could also be disabled from Admin UI.