class

InboxesController

Inherits Ktistec::ViewHelper < Utils::Paths < Ktistec::Controller < Reference < Object

Constants

Log = ::Log.for("inbox")
MAX_INBOX_REQUEST_BYTES = 1048576
RELAYED_ACTIVITY_TYPES = ["https://www.w3.org/ns/activitystreams#Create", "https://www.w3.org/ns/activitystreams#Like", "https://www.w3.org/ns/activitystreams#Dislike", "https://www.w3.org/ns/activitystreams#Update", "https://www.w3.org/ns/activitystreams#Undo", "https://www.w3.org/ns/activitystreams#Delete"]

Activity types that, when wrapped in an Announce, indicate a community relay (rather than a share/boost/announce of an object).

Class methods

max_inbox_fetch_time

Maximum time to spend fetching resources.

Verification and dispatch make several sequential fetches -- signer key, signer, actor, the activity, its object, its attributed-to.

Every figure below is from an analysis of the access log covering 2026-05-26 to 2026-08-04 -- 403,672 inbox POSTs, 95,144 of them 200s -- run on 2026-08-07.

4s is nowhere near the common case: 63.5% of deliveries never fetch at all (medians 0.1-1.0ms), and of all deliveries that succeed, 96.8% finish in under a second. Only a delivery that makes outbound fetches can reach 4s at all.

Below 4s is real work: a fetch against a peer has a p75 of 462ms, and the chain of sequential fetches fills the 1-2s band for 2.25% of successful deliveries.

Above 4s are our own timeouts: per-operation timeouts are 5s, and the histogram steps across 5s (36 requests in 4.5-5s, 372 in 5-5.5s, ...).

Between 2.5s and 5s there is almost nothing -- 0.44% of successful deliveries, spread evenly rather than clustered -- so the cutoff can sit anywhere in that range without splitting a class of deliveries that belong together.

The worst case observed is 45.7s. A 4s budget costs ~0.37% of successful deliveries (~5/day), which become 502s and are retried.

Source
max_inbox_fetch_time=(max_inbox_fetch_time : Time::Span)

Maximum time to spend fetching resources.

Verification and dispatch make several sequential fetches -- signer key, signer, actor, the activity, its object, its attributed-to.

Every figure below is from an analysis of the access log covering 2026-05-26 to 2026-08-04 -- 403,672 inbox POSTs, 95,144 of them 200s -- run on 2026-08-07.

4s is nowhere near the common case: 63.5% of deliveries never fetch at all (medians 0.1-1.0ms), and of all deliveries that succeed, 96.8% finish in under a second. Only a delivery that makes outbound fetches can reach 4s at all.

Below 4s is real work: a fetch against a peer has a p75 of 462ms, and the chain of sequential fetches fills the 1-2s band for 2.25% of successful deliveries.

Above 4s are our own timeouts: per-operation timeouts are 5s, and the histogram steps across 5s (36 requests in 4.5-5s, 372 in 5-5.5s, ...).

Between 2.5s and 5s there is almost nothing -- 0.44% of successful deliveries, spread evenly rather than clustered -- so the cutoff can sit anywhere in that range without splitting a class of deliveries that belong together.

The worst case observed is 45.7s. A 4s budget costs ~0.37% of successful deliveries (~5/day), which become 502s and are retried.

Source