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
idk if this works but basically when there's a public object from a
private activity, the query joins the activity anyway because it uses
the object relation, try using the addressing relation and see what
comes out
im not sure why but apparently there's some bug somewhere? maybe some
instances are picky and want the new thing? should still be fine using
sha256 as signing tho
aode relay complains that digest is missing on fetches? idk, let's try
putting an empty digest, will aode work? will mastodon/akkoma still
work? will this fix some *keys too???
since this migration breaks all sqlite dbs, i changed the original
migration so that future ones won't panic when reaching here. note that,
if you are on sqlite, just `sqlite3 <your_db> .dump > backup.sql` and
then, after rebuilding and re-migrating db, `cat backup.sql | sqlite3 <your_db>`
