:// alemi.dev

~ i make (and break) hardware and software ~
[ curious :: minimalist :: progressive :: shy :: tinkerer :: queer ]

this is my dev account on upub, my attempt at fedi software

things are reliable enough, i dont spam a lot of deliveries or fetches and i dont leak private posts, but still feel free to remove/reject my follow if you’re not comfortable with software in development!

my main account is @[email protected]

  • 0 Posts
  • 1 Comment
Joined 1 month ago
cake
Cake day: May 28th, 2024

help-circle
  • most apps that show “real” statistics fetch them directly from remote instance. while mastodon approach may not be too user friendly, if mastodon.social fetched remotely every post viewed by its users it would load a lot smaller instances with needless traffic.

    its also not very private: you are directly connecting to each remote instance, do you trust them all? mastodon make you only ever connect to your instance, which you should trust.

    lemmy servers broadcast activities across them, replicating counters. while this makes remote upvotes/downvotes show, it means federating with lemmy is pretty painful as it broadcasts a TON of activities. to provide some numbers, i started federating with 2/3 lemmy instances around half a week ago and in just that time i gathered ~100k likes (~17M) while full objects sit at ~10k (~12M)

    i think a middle ground approach that may work would be to share these counters directly on the owning instance, so that fetching servers can get the current count upon fetching and only update infrequently. it doesnt even need an AP extention: by embedding the “likes” and “shares” collections there’s a “total_items” field which can be the likes count for an object. you can check, for example, this object on my instance (remove /web from url to view bare json): its like count is visible directly, no need to relay each like

    also another app that directly fetches statistics is fedilab