Action Delivery

Algorithm: Distribute Action

Input: action_token, action_type
Output: Result<()>

1. Determine recipients based on action_type:
   a. "POST" → All followers of the user
   b. "CMNT" / "REACT" → Owner of parent post
   c. "CONN" / "FLLW" → Target from action audience (aud claim)
   d. "MSG" → All conversation participants
   e. Other → No recipients (skip)

2. For each recipient instance:
   a. Construct URL: https://cl-o.{recipient_id_tag}/api/inbox
   b. POST action token as JSON: {"token": "..."}
   c. Continue on error (best-effort delivery)

3. Return success

HTTP Endpoint: POST /api/inbox

Handler Algorithm:
1. Extract action token from JSON payload
2. No authentication required (token is self-authenticating)
3. Create ActionVerifierTask with token
4. Schedule task in task scheduler (for async processing)
5. Return HTTP 202 (Accepted) immediately
   - Verification and processing happen asynchronously
   - Prevents network timeouts on slow verification

HTTP Endpoint: POST /api/inbox/sync

Handler Algorithm:
1. Extract action token from JSON payload
2. No authentication required (token is self-authenticating)
3. Process action SYNCHRONOUSLY (not queued)
4. Verify signature, check permissions, store action
5. Return HTTP 200 (OK) with result, or error response

Use Cases:
- Identity registration tokens (IDP:REG)
- Actions where sender needs immediate confirmation
- Critical federation handshakes

RetryPolicy Configuration:
  initial_wait:  10 seconds    # First retry delay
  max_wait:      12 hours      # Maximum delay between retries
  backoff_step:  50 seconds    # Backoff increment per retry

Attempt 1: Immediate
  ↓ fails
Attempt 2: 10s later (initial_wait)
  ↓ fails
Attempt 3: 60s later (10s + 50s backoff)
  ↓ fails
Attempt 4: 110s later (60s + 50s backoff)
  ↓ fails
...continues with 50s backoff steps...
  ↓
Maximum wait capped at 12 hours between attempts

On POST /api/inbox result:

1. Success (2xx):
   - Remove from delivery queue
   - Log successful delivery

2. Temporary Error (network timeout, 5xx, connection refused):
   - Keep in queue
   - Schedule retry with backoff
   - Continue retrying until max attempts

3. Permanent Error (4xx status, validation error):
   - Log error with context
   - Mark as undeliverable
   - Remove from queue (don't waste resources)

APRV Fan-out Algorithm:

1. User A creates POST action
2. User B reposts (creates APRV referencing POST)
3. On APRV creation:
   a. Fetch User B's followers
   b. For each follower:
      - Create delivery task for original POST
      - Include APRV context (who approved)
   c. Followers receive both POST and APRV