foster/forgejo-docs
0
0
Fork 0
mirror of https://codeberg.org/forgejo/docs.git synced 2024-11-21 17:36:59 -05:00
Code Issues Activity
forgejo-docs/docs/contributor/adr/adr-how-to-trigger-activities.md
Otto Richter 64fe34712f Update contributing sections (#821) 
Rename Developer to Contributor guide
- I believe this sounds more inclusive and likely improves the diversity of contributors.
Separate translation section
clarify external resources
Add links to UI/UX and user research repos
Separate issue tracker and discussions
- I imagine this is part of the confusion for people who report bugs to the discussion tracker.
Add welcome section

Reviewed-on: https://codeberg.org/forgejo/docs/pulls/821
Reviewed-by: Gusted <gusted@noreply.codeberg.org>
Co-authored-by: Otto Richter <git@otto.splvs.net>
Co-committed-by: Otto Richter <git@otto.splvs.net>
2024-08-25 16:15:48 +00:00

3.6 KiB
Raw Blame History

title license
ADR: Trigger Activities CC-BY-SA-4.0

How to Trigger Activities

Status

Proposal

Context

While implementing the trigger of federated stars we have to handle the distribution of corresponding Like-Activities to the federated repositories.

This must be done consistently and without circularity, such that a repository starring by a user leads to exactly one added star in every federated repository.

diagram

Decision

Choices

1. Transient Federation without Constraints

In this case the star federation process would look like:

  1. Repo on an instance receives a star (regardless of whether via UI or federation)
  2. Instance federates star to all repos that are set as federated repositories.

Problem - Circularity And Inconsistency

Circular federation would lead to a infinite circular distribution of Like-Activities:

diagram

  1. Given a repo on the 3 instances A, B, C.
    Repo on instance A has set repo on instance B as federation repo.
    Repo on instance B has set repo on instance C as federation repo.
    Repo on instance C has set repo on instance A as federation repo.
  2. User stars repo on instance A via UI.
  3. Instance A sends Like-Activity to repo on instance B.
  4. Instance B creates local FederatedUser, stars the repo and sends Like-Activity to repo on instance C.
  5. Instance C creates local FederatedUser, stars the repo and sends Like-Activity to repo on instance A.
  6. Instance A creates local FederatedUser, since the Actor of the Like-Activity is the local FederatedUser created on instance C.
    Thus, the repo on instance A gets another star by this user and sends Like-Activity to the repo on instance C.
  7. The circular distribution of Like-Activities continues, since the actor is always the local FederatedUser of the sending instance.

2. Direct Federation only

diagram

In this case the star federation process would look like:

  1. Case: Repo on an instance receives a star by an authenticated user via UI/API:
    1. Repository gets starred by the authenticated User.
    2. Instance federates star to all repos that are set as federated repositories.
  2. Case: Repo on an instance receives a star via a Like-Activity:
    1. Instance creates FederatedUser and stars the repository.
    2. No further star federation to federated repos is triggered.

Discussion for option 2.

  1. pro
    1. Prevent circular communication
    2. Clear semantic also in case of "Who should authorize a digital signature"

3. Transient Federation and Remember Processed

In this case the star federation process would look like:

  1. Repo on an instance receives a star (regardless of whether via UI or federation)
  2. If this activity was not operated already in this instance, federate star to all repos that are set as federated repositories.

See also