mirror of
https://codeberg.org/forgejo/docs.git
synced 2024-11-21 17:36:59 -05:00
64fe34712f
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>
87 lines
3.6 KiB
Markdown
87 lines
3.6 KiB
Markdown
---
|
|
title: 'ADR: Trigger Activities'
|
|
license: 'CC-BY-SA-4.0'
|
|
---
|
|
|
|
# How to Trigger Activities
|
|
|
|
- [How to Trigger Activities](#how-to-trigger-activities)
|
|
- [Status](#status)
|
|
- [Context](#context)
|
|
- [Decision](#decision)
|
|
- [Choices](#choices)
|
|
- [1. Transient Federation without Constraints](#1-transient-federation-without-constraints)
|
|
- [Problem - Circularity And Inconsistency](#problem---circularity-and-inconsistency)
|
|
- [2. Direct Federation only](#2-direct-federation-only)
|
|
- [Discussion for option 2.](#discussion-for-option-2)
|
|
- [3. Transient Federation and Remember Processed](#3-transient-federation-and-remember-processed)
|
|
- [See also](#see-also)
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
## 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:
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
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
|