Reply-to accounts were compiled by getting the original poster + all the
mentions returned by the API. The OP now seems to be included in the
mentions, which duplicated that account in the list. I've stripped
it down so it just uses the list of mentions returned by the API now.
If the user is logged in, send their token when querying for a status.
This prevents the API returning a 404 when the status being queried
is private or direct.
I was re-using the same paths for a bunch of stuff in order to
minimise redirects (POSTing new statuses to the timeline, or performing
actions on a status), but then this breaks the behaviour of the
browser's refresh button. I've moved all those actions to their
own paths, which helps break up the code, makes the URLs more
semantic, and lets you use the refresh button without accidentally
performing an action.
This is at the expense of an additional HTTP request, but I've
tried to minimise the cost by passing through the status from the
previous action so we don't have to requery for it on the server
side.
Implemented a new page that shows a status context, though I'm
calling it a "thread" in the UI because I think that makes more
sense for users. Also moved the action element from the notification
into the event info component itself because I also want to use it
to indicate when a status is a reply.
Status routes were a bit of a mess and involved redirects,
which is only going to slow things down. I've amalgamated them
into one route and used query parameters to determine any actions
being performed.
St John Karp