Due to how federation works, the federated instance needs to accept and process the activity. Each application can define its own “optional” activity properties, but the activitypub specs define mandatory properties and some optional properties for coherence across the fediverse.

The way lemmy implements this is to use the activitypub-federation-rust library that the lemmy devs built. Through this, activities in Lemmy are sent using HTTP and have a failure retry:

It is possible that delivery fails because the target instance is temporarily unreachable. In this case the task is scheduled for retry after a certain waiting time. For each task delivery is retried up to 3 times after the initial attempt. The retry intervals are as follows:

one minute, in case of service restart
one hour, in case of instance maintenance
2.5 days, in case of major incident with rebuild from backup

In the case of votes, the activity is a “like” - some other federated applications understand this and will accept it, but others won’t. For example, peertube does not have a like activity, and I don’t believe they would handle it.

However votes are shared across instances. When a user “likes” something from another instance, Lemmy will notify that actor (the page) that the activity (a like) was emitted by another actor (you).

Hope that clarifies things. I’m still learning all this myself so if anyone can contribute or improve my answer, please do!

In theory upvotes are counted from every server. In practice, there’s been some small synchronization issues in the past where servers fail to send upvotes sometimes. It should be better now.