There are a few interesting quirks in how Pleroma formats its outbox, mainly that you can't ask for newer posts - only older ones.
When connected to a Mastodon or Misskey instance, mstdn-ebooks (and FediBooks) works by starting from the oldest user posts it's seen up to that point, and then getting the newer ones until it's caught up to your latest post.
However, this won't work when using a Pleroma instance, because you can't ask for newer posts. Instead, mstdn-ebooks gets your newest post, and works its way backwards until it encounters a post it's seen before.
This is usually okay, but with one exception: Rate limiting. If you've made 50 posts since mstdn-ebooks last checked, but your server is set up to only allow downloading 40 posts in a row, it'll get the 40 newest posts, and the 10 other new posts you made won't be downloaded - ever.
This is a solvable issue, but there isn't a solution that is as easy to implement or as well functioning as the Mastodon/Misskey method. The best I can think of is "remembering" that there are still 10 posts to download, and next time mstdn-ebooks runs, downloading those 10. This has its own drawbacks, however, and is a pretty major change to implement for the sake of a single platform not implementing this particular part of the ActivityPub spec. I'd like to note that the 'prev' key is optional in the spec - Pleroma isn't failing to comply with the AP spec, just not implementing a particular optional feature that saves a lot of headaches.
This issue puts it succinctly: https://git.pleroma.social/pleroma/pleroma/issues/751
"No 'prev' property is defined, which could logically point to the 'future' page - this is a the main problem [...] the only way for this check is to request initial endpoint page [...] that results in unnecessary duplicated requests and data transfers, and complicated syncing logic."
@email@example.com's anti-chud pro-skub instance for funtimes