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
basically now object.as_actor() or object.as_collection() returns an
option which is full with a self ref only if the type is correct, so
that we can assume flexible json behavior from anything implementing our
apb traits, and we don't need to rely anymore on knowing the underlying
type
also little import refactor
this happens because we're paginating with just an offset, meaning that
when new activities get inserted that offset "gets shifted forward" and
we receive again some activities we saw already. this should get fixed
for good on the backend, but for now discarding them here makes it
usable
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