i mean, it's obviously addressed to the target actor of this activity,
but it would cost nothing to put it in the `to` field... i do! added
special cases to make sure follow/accept/reject activities are at least
addressed to target actor
it shows it in quite a jank way: inside the "audience" collections you
find your id as only item. it's weird af but technically valid ap i
think? will probably be replaced with a local api extension as soon as i
read about those
use audience for followers, generator for following and replies for
total statuses count. restored followers, following and outbox as bare
links. silly AP!!!
basically relays send us a lot of announce activities to share posts
but we don't care about those activities: it's db bloat and it increases
the shares count. keep a table keeping track of followed relays and
lazily skip activities by them, just fetch. IMPORTANT relays are only
loaded at startup, so if you subscribe to a new relay restart your
server once it accepts!!!
i think because the db would end up locked, added brackets to be sure to
drop the streaming reference. also it could crash when updating records
not found, just spit a warn
note that won't reset everything to 0, just force set every post which
has a count != 0
also this is kind of a bad way to do it. at least we stream objects, but
we could have it happen all inside our db with SELECT, DISTINCT and SUM,
i just don't know how to represent it in sea_orm. an intermediate
optimization may be selecting only certain columns but it's relevant
almost only for replies
it's done with anonymous inline collections, which hold a "totalItems"
field. for replies it's perfect, for likes it's stretched ("audience",
used as a Collection) and for shares it's really stretched ("generator",
used as a Collection). also using audience and generator as collections
seems weird because they should be objects but collections are objects
so it should be fine? i haven't seen these fields used anyway so it
should be safe to "claim" it for ourselves?
for example, pleroma servers objects under /notice/abcd... but the
object id itself is different, under /objects/<uuid>. when fetching
pleroma redirects, but we get unreliable behavior. redirect so that we
can force clients to use the proper id
