Stricter specifications for pagination of Collections and OrderedCollections

ActivityPub Client to Server
18

I think we’ve gone off-topic for this thread, which was about paginating Collections and being able to reliably fetch “page 14” or “items 396-400” as an ahead-of-time optimized action set by the producer (and possibly by the consumer, if standardized parameters or subpaths are developed and supported). an example use-case of which is to avoid “infinite scroll” dark patterns by always knowing how much you’ve read and how far you’ve read.

nonetheless, my take on the Update thing is that it should follow S2S Update semantics. Update should have its object inlined or embedded in its entirety, so that the “complete replacement” logic can be followed as described in the S2S Update section.

example flow:

  • Client sends C2S Update with partial replacement
  • Server makes the requested changes if possible
  • Server publishes an S2S Update in the outbox with the fully embedded or inlined object, as resulting from the C2S Update
# Before

id: <doc>
type: Document
name: "foo"
summary: "A document of some kind"

# POST /outbox HTTP/1.1

type: Update
name: "Some Update"
summary: "Rename foo to bar"
object:
  id: <doc>
  name: "bar"

# After

id: <doc>
type: Document
name: "bar"
summary: "A document of some kind"

# GET /outbox/some-update HTTP/1.1

id: </outbox/some-update>
type: Update
name: "Some Update"
summary: "Rename foo to bar"
object:
  id: <doc>
  name: "bar"
  summary: "A document of some kind"

there is maybe some use of result that can be proposed for linking to specific revisions, assuming that specific revisions are supported and tracked. but that’s yet another topic. i assume people would want to be able to Like or otherwise refer to or act upon certain revisions, so there’s certainly a lot of things that need to be figured out if one wishes to pursue that.

1 Like