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!!!
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?
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
no more "impl ..." hell, each trait has associated types so that we know
it's a "Self::Link" or a "Self::Actor", but in practice they can both be
a "serde_json::Value" and thus we can change its type. also Node::Array
is now a Vec<T> rather than Vec<Node<T>> because it makes more sense.
Node is Iterable and will yield zero (Empty|Link), one (Object) or many
(Array) Ts
