From e1f27a950cc5b8102c51d247dfd78f9a45270202 Mon Sep 17 00:00:00 2001 From: Michael Jerger Date: Thu, 18 Jan 2024 20:01:22 +0100 Subject: [PATCH] improve english .. --- docs/unsure-where-to-put/adr-map-federated-person.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/unsure-where-to-put/adr-map-federated-person.md b/docs/unsure-where-to-put/adr-map-federated-person.md index af8b2257c9..2056269f1e 100644 --- a/docs/unsure-where-to-put/adr-map-federated-person.md +++ b/docs/unsure-where-to-put/adr-map-federated-person.md @@ -17,13 +17,13 @@ Still in discussion ## Context -While implementing federation we have to represent federated persons to a local instance. +While implementing federation we have to represent federated persons on a local instance. -A federated person should be able to execute local actions (as it was a local user) without too many code changes. +A federated person should be able to execute local actions (as if he was a local user), ideally without too many code changes. 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",}`. Find out whether this user is available locally without dereference the federated person 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 dereference the federated person every time is important for performance & system resilience. ## Decision