I am concerned that Mastodon’s unary-vote system (favorites), and Lemmy’s binary-vote system (upvotes with downvotes) are mutually exclusive.
In a unary-vote system, a post’s vote count generally has little use beyond expressing the post’s absolute popularity/engagement, whereas, in a binary vote system, a post’s vote count can be used to gauge opinions, such as its level of quality, trust, or agreement. This difference in usage makes me concerned that the votes federated from Mastodon will water down the votes originating from Lemmy.
Currently, I can think of two possible solutions to this:
- Lemmy de-federates any votes originating from Mastodon (might be tricky as it would rely on all instances following suit)
- Add an option for the user to toggle within their settings allowing them to toggle off non-binary votes.
Well ActivityPub isn’t 1:1 interoperable all the time. Like you’re not going to see the upvotes/downvotes of a Lemmy post when viewing from Mastodon. Which this makes sense, since how would Mastodon even know how to handle that data, and it opens up all sorts of compatibility problems. What does interoperate is the post and comment content which is the important part. Also that you’re able to post/comment to other user posted content even if you can’t see all of that ActivityPub’s application data.
It will be interoperable up to the base spec (assuming, of course, that both services adhere to the base spec).
If both Mastodon, and Lemmy adhere to the spec, then they can interoperate. If Lemmy’s upvotes are federated as ActivityPub like activities, and Mastodon intereperets like activities as favorites, then there should be no issue. Downvotes will certainly not federate as Mastodon doesn’t use them, and they don’t exist in the base spec.
Likes federate as well. See Section 6.8 of the ActivityPub spec.