forgejo/docs/unsure-where-to-put/adr-activity-for-star.md
2024-02-10 15:19:26 +01:00

4.2 KiB

Activity for federated star action

Status

Active

Context

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

We decided to use "2. Like Activity while source information comes from NodeInfo"

Choices

1. Star Activity derived from AP Like with additional source information

# edn notation
{@context [
    "as":    "https://www.w3.org/ns/activitystreams#",
    "forge": "https://forgefed.org/ns#",],
  ::as/id "https://repo.prod.meissa.de/api/v1/activitypub/user-id/1/outbox/12345",
  ::as/type "Star",
  ::forge/source "forgejo",
  ::as/actor "https://repo.prod.meissa.de/api/v1/activitypub/user-id/1",
  ::as/object "https://codeberg.org/api/v1/activitypub/repository-id/12"
}
# json notation
{"id": "https://repo.prod.meissa.de/api/v1/activitypub/user-id/1/outbox/12345",
  "type": "Star",
  "source": "forgejo",
  "actor": "https://repo.prod.meissa.de/api/v1/activitypub/user-id/1",
  "object": "https://codeberg.org/api/v1/activitypub/repository-id/1",
  "startTime": "2014-12-31T23:00:00-08:00",
}

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 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 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: 7cac9806f8/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: 7cac9806f8/models/forgefed/actor.go (L121))
  5. startTime protects against The Reply Attack discussed in threat-analysis threat-analysis

2. Like Activity while source information comes from NodeInfo

# NodeInfo
{
  "version": "2.1",
  "software": {
    "name": "gitea",
    "version": "1.20.0+dev-2539-g5840cc6d3",
  },
  "protocols": [
    "activitypub"
  ],
}

# Like Activity
{"id": "https://repo.prod.meissa.de/api/v1/activitypub/user-id/1/outbox/12345",
  "type": "Like",
  "actor": "https://repo.prod.meissa.de/api/v1/activitypub/user-id/1",
  "object": "https://codeberg.org/api/v1/activitypub/repository-id/1",
  "startTime": "2014-12-31T23:00:00-08:00"
}

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. With NodeInfo 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 NodeInfo field reflects the software & version sending an activity. Values of may be gitea, 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: 7cac9806f8/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: 7cac9806f8/models/forgefed/actor.go (L121))
  4. startTime protects against The Reply Attack discussed in threat-analysis threat-analysis

See also