Number of post boosts is not displayed properly

[Servelan]

I clicked on a post to boost it, making it the eighth or ninth time it'd been boosted, then clicked the back arrow at the top near the leaf icon, and back on my feed, it shows 1 boost, which I presume is mine. I refreshed the page...still only one boost.

Expected is the total number, not just mine. If this is by design, well....

[stackblitz[bot]]

Start a new pull request in StackBlitz Codeflow.

[Servelan]

Another instance of things not being displayed correctly; I commented on this post, which was boosted by someone else, but no replies show up.

[Teqed]

Another instance of things not being displayed correctly; I commented on this post, which was boosted by someone else, but no replies show up.

This could be considered a separate issue, and there's currently a project called FediFetcher which "can pull missing remote replies to posts that are already on your server into your server." I don't know if this kind of behaviour would be in scope for Elk as just a client, but running FediFetcher can alleviate the issue.

Expected is the total number [of boosts], not just mine.

There's a good discussion of the problem and possible solutions on this thread from early June, and the feature is on Mastodon's public roadmap as MAS-132, "Synchronize boost and favourite counts for remote posts", which is in the 'Planned' but not 'In Progress' category.

For example, if you make a request to https://${exampleServer}/api/v1/statuses/${exampleStatusId} you'll get a status code 200 and a 'Status' object as response that includes:

{
    "replies_count": 0,
    "reblogs_count": 0,
    "favourites_count": 0,
    "uri": "https://${originalServer}/@${exampleUser}/${originalStatusId}",
}

The information for replies, reblogs, and favourites are included, but I assume that remote statuses are usually only fetched once by the server, so the data could become out-of-date to when it was initially posted. The current implementation seems to only show replies, reblogs and favourites which are personally known to the server, ignoring the count from the original server. Using the above solution with FediFetcher you can get the reply count to take into consideration any replies you've managed to actually retrieve, but reblogs and favourites never update and can only be viewed by accessing the status on its original server.

A client could use the "uri" field to reference the original server and original status ID and make their own request for the updated stats at the same time they retrieve the status from the home server at the cost of another request to the original server. If these requests are using default rate-limits of 300 / 5 minutes that's 1 / second from the original server before getting rate-limited, which seems like an easy limit to hit when scrolling down a home feed populated by statuses from a large instance.

Instead of the web client taking matters into its own hands to get counts for statuses, it may be more robust for the underlying homeserver (Mastodon itself) to handle the counts, throttle requests when necessary, cache the results for a time period, and provide them to all users, regardless of the web client being used.

[Servelan]

This issue also applies to surveys. I responded to this survey, then saw a response I thought I might like to respond to, changed my mind and found my vote not registered.

https://elk.zone/universeodon.com/@okayatheists/110824009926945354