mirror of
https://codeberg.org/forgejo/forgejo.git
synced 2024-11-10 12:15:43 +01:00
4.2 KiB
4.2 KiB
Activity for federated star action
Status
Proposal
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.
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:
- Actor & object may be dereferenced by (ap-)api
- The activity can be referenced itself (e.g. in order to express a result of the triggered action)
- Star is a special case of a Like. Star only happens in ForgeFed context. Different things should be named differnt ...
- 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- The
source
field reflects the software sending an activity. Values of may be forgejo, gitlab, ... - Knowing the sending system will it make easier to interact with:
- We know exactly how the actor can be derefernced - names maybe filled & used different (see:
7cac9806f8/routers/api/v1/activitypub/repository.go (L180)
) - We know how we can validate the given references - valid uris will be different in details (see:
7cac9806f8/models/forgefed/actor.go (L121)
)
- We know exactly how the actor can be derefernced - names maybe filled & used different (see:
- The
- 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:
- Actor & object may be dereferenced by (ap-)api
- The activity can be referenced itself (e.g. in order to express a result of the triggered action)
- 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
- The NodeInfo field reflects the software & version sending an activity. Values of may be gitea, forgejo, gitlab, ...
- Knowing the sending system will it make easier to interact with:
- We know exactly how the actor can be derefernced - names maybe filled & used different (see:
7cac9806f8/routers/api/v1/activitypub/repository.go (L180)
) - We know how we can validate the given references - valid uris will be different in details (see:
7cac9806f8/models/forgefed/actor.go (L121)
)
- We know exactly how the actor can be derefernced - names maybe filled & used different (see:
- startTime protects against The Reply Attack discussed in threat-analysis threat-analysis