[feature] Multi-user requirement: federation audit logs

[SoniEx2]

Is your feature request related to a problem ?

Moderation is hard. Having git blame for federation would help a lot.

Describe the solution you'd like.

We've previously described the audit log idea here: https://github.com/pixelfed/pixelfed/issues/5126

But to reiterate:

• Create table of "what, cause, when, why", primary key "what"
• Insert if not exists any relevant object ID whenever you come across it, for example:
  • user shoves URI in search query, insert [search URI], [user ID], now(), "search"
  • fetching post pulls profile, insert [actor ID], [post ID], now(), "post resolution"
  • fetching profile pulls pinned posts, insert [pinned post ID], [actor ID], now(), "actor resolution"
  • remote user boosts, insert [boost ID], null, now(), "remote push"
  • boost requires fetching post, insert [post ID], [boost ID], now(), "boost resolution"
  • etc
• If these happen to conflict, first one wins: boost fetches post fetches actor fetches pinned post (post == pinned post) -> log would contain [post ID], [boost ID], ..., "boost resolution" but NOT [post ID], [actor ID], now(), "actor resolution". (this is just standard insert if not exists behaviour.)

This feature is just for the backend and does not take into account the work required to make the audit log actually useful (i.e. relevant moderation APIs/UI).

Describe alternatives you've considered.

None.

Additional context.

We don't know if GtS is trying to support multi-user deployments or if it only supports single-user instances. This feature is only relevant for multi-user tho, so feel free to deprioritize it if it doesn't align with the project's use-case.

[NyaaaWhatsUpDoc]

while this is a cool idea, it would absolutely rip through storage space, so much would need to be stored. so much more than currently. and i'd also be worried about the performance impact of our users of small constrained devices.

[SoniEx2]

an audit log entry is smaller than a boost, and it's only stored once per what. (it can also be pruned.)

ofc, to avoid the obvious performance overhead of full sending the SQL, you could refactor the codebase to keep track of the things on the app side...

[tsmethurst]

How do you mean keep track of things on the app side?

In your proposal there's a lot of stuff that frankly just doesn't really feel like it would be used for anything. I think the only federation stuff we really need to be keeping around would be a list of which instances have dereferenced or received a post, for more thorough deletion. Aside from that I'm not sure what the benefits would be of writing something into the db every time the instance "does" something as a result of user action.

[SoniEx2]

we mean instead of full sending it with the SQL, you could carry the metadata throughout the various bits of the codebase.

one of the biggest benefits of this (= federation audit logs that tracks "object" and "cause") that you don't get with what you're suggesting is that you can investigate patterns that you otherwise couldn't.

it lets you answer questions like "why do we keep seeing fash in the [federated timeline/tags/etc]". (you'd never think to look at your own users - or their follows - for that, but the federation audit log does. we don't need to blame "the fedi"; after all, the main way federation happens is when one user follows another user.)

it gives you more insight into "how are fash instigating this wave of racism and transphobia" (which happens every couple of months yet everyone just blames Black and trans folks instead of looking at the fash).