Provide federation context collection (fixes #5283)

[Nutomic]

Adds a context field to federation data for posts and comments, which has a value like http://lemmy.ml/post/1/context or http://lemmy.ml/comment/1/context. Fetching this url gives a collection with all known comments in the given post, example post context from local testing:

{
  "@context": [
    "https://join-lemmy.org/context.json",
    "https://www.w3.org/ns/activitystreams"
  ],
  "type": "OrderedCollection",
  "id": "https://sh.itjust.works/post/41829564/context",
  "totalItems": 7,
  "orderedItems": [
    "https://sh.itjust.works/post/41829564",
    "https://discuss.tchncs.de/comment/19552175",
    "https://lemmy.ml/comment/19756281",
    "https://lemmy.ml/comment/19755913",
    "https://sh.itjust.works/comment/19668655",
    "https://lemmy.ml/comment/19756039",
    "https://sh.itjust.works/comment/19668740"
  ]
}                                                                                                                             

And comment context:

{
  "@context": [
    "https://join-lemmy.org/context.json",
    "https://www.w3.org/ns/activitystreams"
  ],
  "type": "OrderedCollection",
  "id": "https://sh.itjust.works/comment/19668655/context",
  "totalItems": 7,
  "orderedItems": [
    "https://sh.itjust.works/post/41829564",
    "https://discuss.tchncs.de/comment/19552175",
    "https://lemmy.ml/comment/19756281",
    "https://lemmy.ml/comment/19755913",
    "https://sh.itjust.works/comment/19668655",
    "https://lemmy.ml/comment/19756039",
    "https://sh.itjust.works/comment/19668740"
  ]
}

Requires #5855

[julianlam]

Hi @Nutomic! Some thoughts:

1. It might be better to order the collection items by creation time and send an OrderedCollection. However, there is no requirement to do so, since this might be unfeasible for some implementations.
2. Local Lemmy comments should also set context, as this will ease context discovery without needing to traverse upward to the root node
   • e.g. (Local-to-local)
     • http://localhost:8536/comment/19552175 is a reply to http://localhost:8536/post/1.
     • If it were retrieved via AP, context would be set to http://localhost:8536/post/1/context
   • e.g. (Local-to-remote)
     • http://localhost:8536/comment/20172636 is a reply to https://discuss.tchncs.de/post/1.
     • If it were retrieved via AP, context would mirror context from the root node (or if unavailable, a parent) if provided (https://discuss.tchncs.de/post/1/context)
3. I am assuming that http://localhost:8536/post/1 is omitted from the context collection on purpose? Again I don't think including it is a requirement, just wondering.

[Nutomic]

It might be better to order the collection items by creation time and send an OrderedCollection. However, there is no requirement to do so, since this might be unfeasible for some implementations.

Done, items are sorted by id now (ie creation time).

I am assuming that http://localhost:8536/post/1 is omitted from the context collection on purpose? Again I don't think including it is a requirement, just wondering.

Right I forgot about that, added it now.

Local Lemmy comments should also set context, as this will ease context discovery without needing to traverse upward to the root node

This is already included, added an example above. Instead of any conditionals, for http://lemmy.ml/comment/1 it always gives http://lemmy.ml/comment/1/context because posts from other platforms may not provide any context.

[julianlam]

Instead of any conditionals, for http://lemmy.ml/comment/1 it always gives http://lemmy.ml/comment/1/context because posts from other platforms may not provide any context.

I'll have to think on this because having an inherited context allows for things like ownership and potentially paves the way for reply controls.

But the simplicity of each comment providing its own context also makes sense.

[Nutomic]

I could easily change it to set post_ap_id/context for comments (eg https://discuss.tchncs.de/post/1/context. But then there is no guarantee that the url exists, because the post's instance may run an older Lemmy version or a different software, or it could provide context at a different path. Otherwise it would be necessary to permanently store the context url for each post which seems unnecessary.

[julianlam]

Thank you for your input, that makes sense. There isn't a specific recommendation for this right now so learning about the logic behind specific decisions is helpful.

Inheriting context has some prior art, some existing software does it (Akkoma and some others), but there is no guarantee that if you declare a cross-origin context that your object actually exists in it.

[Nutomic]

Actually with FEP-1b12 the community is authorative. Other instances may be missing comments (eg from instance blocks, user bans), or may have extra comments (eg if deletions didnt federate). So ideally it would serve a context url from the community instance. But that is not possible because when posting in a remote community, we dont know what the local post id will be there.

The best option I can think of is an endpoint like /context?for_post_id=https://discuss.tchncs.de/post/1. Then the json context field isnt even strictly necessary, you could just build this url yourself and fetch it. Of course its possible that the community instance runs an older Lemmy version or another software which doesnt provide any context, and then it would still be nice to get any context at all from some other instance. It seems there is no perfect solution.

[julianlam]

an endpoint like /context?for_post_id=https://discuss.tchncs.de/post/1

I think that might introduce additional complexity that would hinder adoption. The way it is implemented in this PR now is compliant with 7888: you are declaring your own context. At the end of the day I think it is an implementor decision and context inheritance would likely be a separate, optional FEP. In this case, as you say, the community is authoritative.