Implementation proposal: /outbox?view=latest API

[Jiwoon-Kim]

#2309

Implementation proposal: /outbox?view=latest API

“Preserve all activities internally, but separate the external display so that only the latest state is exposed.”
In other words, maintain the full internal event log while providing a compacted Outbox view that only shows the most recent state of each object by default.

---

💡 Proposed Design Options

1) Event Log + “Latest State View” API (Recommended)

• Store all Activities (Create, Update, Delete, Undo, etc.) in the database.
• Index by object.uri.
• Add an endpoint such as GET /outbox?view=latest or /outbox/latest that returns only the most recent Activity per object.
• Use this “latest view” for federation delivery and client display.
• Keep the full event log accessible through admin or audit interfaces.

✅ Pros: Preserves original logs while improving network efficiency.
⚠️ Cons: Must ensure referential integrity for Undo/Delete relationships.

---

2) Periodic Outbox Compaction Job

• Store all events in the DB.
• Periodically merge consecutive Create/Update events for the same object, keeping only the latest one, and flag older ones as archived.
• Hide archived entries from the default Outbox view.
• Maintain all activities internally, but when displaying in outbox:public, show only the most recent activity.uri for each object.uri.

---

Implementation Example (WordPress ActivityPub Plugin)

1. Add object_uri index to the activities table.

2. Continue storing all Activities (Create, Update, Delete, Undo, etc.).

3. Add a function get_outbox_latest(limit, page) that:

   • Groups Activities by object_uri
   • Selects only the most recent Activity per group

4. Run a background job compact_outbox() that flags older items as archived.

5. Use get_outbox_latest() for the default Outbox output and federation delivery.

   • Allow ?full_history=true to show the complete event log.

---

This approach doesn’t delete data — it’s primarily a UX and performance optimization.
It’s safer to first implement delivery-time deduplication, and later extend it with periodic Outbox compaction if needed.
Optionally, provide an admin setting to toggle between “Full History” and “Latest Only” modes for flexibility.

[pfefferle]

What do you want to achieve with that? The outbox and inbox are also used by Client Apps, so we might need to have the full stream, for them to get all changes!?

[Jiwoon-Kim]

This is purely a theoretical idea intended to keep the representation of the outbox clean.

[pfefferle]

I’d say the purpose of the outbox is to capture every change. It’s best compared to Event Sourcing, a well-known pattern in the world of microservices.

[Jiwoon-Kim]

So I guess that means it’s inevitable to store the entire stream of every change...
Of course, since posts already have revisions, the outbox data itself could be optimized —
but pagination should still be possible, right?

[pfefferle]

There’s room for optimization around post states, but not every Activity in the Outbox originates from a Post change. When I first worked on the plugin, the Outbox was just a simple query on the Posts table — but that approach couldn’t represent Activities like Accept, Follow, Reject, or Delete. We could have tried merging post revisions with other Activities, but that would have made the system unnecessarily complex — especially for C2S scenarios where external apps submit Activities that WordPress needs to process and federate.

[Jiwoon-Kim]

Hmm… leaving the Outbox aside, I think the Inbox would be much easier to manage if it supported categorization and labeling, similar to email. Of course, I’m not talking about implementing this right now — it just seems like a nice idea.