this is really mehhh because if it was possible to embed
following/followers collections this would be pointless but it isn't so
to avoid making multiple fetches i'm adding these fields in the first
actor document
very much ad-hoc but at least i made the ns page so it should be kind of
ok to use i think? if others want to use upub frontend and have all its
features working, this extension will be necessary, rather than some
custom whole api
before, cache would clone the underlying object every time it was
accessed. this was definitely incredibly wasteful! now it clones the
Arc, which is super cheap. the extra work necessary while fetching
things is most likely more than compensated by saved clones every time
we render stuff. there is some dumb arc creation here and there (like
for the debug page), but it's mostly my lazyness, they can probably go
and should not be that much of a big deal anyway.
TLDR things were already fast but should be EVEN FASTER!!!
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
