patchii/forgejo
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix typos

Browse source
This commit is contained in:
Clemens 2024-02-07 15:03:21 +01:00 committed by Michael Jerger
parent a1ca7e958a
commit e477181e23
2 changed files with 7 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
docs/unsure-where-to-put/adr-activity-for-star.md
View file

@ -6,7 +6,7 @@ Active
## Context
While implementing the star activity we have to take several decissions which will impcat all other activities. Due to this relevance we will discuss decission with as many federation contributors as posible.
While implementing the star activity we have to take several decisions which will impact all other activities. Due to this relevance we will discuss decision with as many federation contributors as possible.
## Decision
@ -42,11 +42,11 @@ This way of expressing stars will have the following features:
1. Actor & object may be dereferenced by (ap-)api
2. The activity can be referenced itself (e.g. in order to express a result of the triggered action)
3. Star is a special case of a Like. Star only happens in ForgeFed context. Different things should be named differnt ...
3. Star is a special case of a Like. Star only happens in ForgeFed context. Different things should be named different ...
4. With the `source` given it would be more easy to distinguish the uri layout for object and actor id's and make implementation more straight forward
1. The `source` field reflects the software sending an activity. Values of may be forgejo, gitlab, ...
2. Knowing the sending system will it make easier to interact with:
1. We know exactly how the actor can be derefernced - names maybe filled & used different (see: https://codeberg.org/meissa/forgejo/src/commit/7cac9806f8247963b1cdce3f2c5f5d1bc3763fbe/routers/api/v1/activitypub/repository.go#L180)
1. The `source` field reflects the software sending an activity. Values of it may be forgejo, gitlab, ...
2. Knowing the sending system will make it easier to interact with:
1. We know exactly how the actor can be dereferenced - names may be filled & used different (see: https://codeberg.org/meissa/forgejo/src/commit/7cac9806f8247963b1cdce3f2c5f5d1bc3763fbe/routers/api/v1/activitypub/repository.go#L180)
2. We know how we can validate the given references - valid uris will be different in details (see: https://codeberg.org/meissa/forgejo/src/commit/7cac9806f8247963b1cdce3f2c5f5d1bc3763fbe/models/forgefed/actor.go#L121)
5. startTime protects against The Reply Attack discussed in [threat-analysis] [threat-analysis]

4
docs/unsure-where-to-put/adr-map-federated-person.md
View file

@ -30,7 +30,7 @@ A federated person should be able to execute local actions (as if he was a local
For being able to map the federated person reliable, the local representation has to carry a clear mapping to the original federated person.
We get actor information as `{"actor": "https://repo.prod.meissa.de/api/v1/activitypub/user-id/1",}`. To find out whether this user is available locally without dereference the federated person every time is important for performance & system resilience.
We get actor information as `{"actor": "https://repo.prod.meissa.de/api/v1/activitypub/user-id/1",}`. To find out whether this user is available locally without dereferencing the federated person every time is important for performance & system resilience.
## Decision
@ -108,7 +108,7 @@ classDiagram
namespace forgejo {
class User {
<<Aggragate Root>>
<<Aggregate Root>>
ID int64
LowerName string
Name string