Merge upstream changes

[ClearlyClaire]

A lot of upstream changes, the most disruptive being:

• Dropped support for OStatus and Atom feeds
• Added an anti-spam feature that auto-silences and auto-report remote accounts posting very similar (according to the Nilsimsa Hash algorithm) unsolicited (as in, mentioning at least one local user who do not follow them, and not in reply to a message mentioning them) messages. It is currently not optional. It can be disabled from the admin settings.
• Started signing every fetch with the representative account (that is, the contact account if it is defined, the first non-suspended local account in the database otherwise) a dedicated instance actor
• Added an option to disable reverse proxy caches and only serve toots if there is a valid signature (it is unadvisable to enable that option right now, as no Mastodon release currently signs queries)

[cwebber]

@cwebber The "who is calling me" approach you are describing is the basis of all API authentication (API keys) as well as all website logins (username/password, session cookie) in the world. I am very confused why you think this is different. We've been authenticating inbox deliveries using this approach since the start of ActivityPub.

There's the source of misunderstanding: I'm saying that "who is calling me" is a broken model. "Who said this thing" is another thing entirely; that's verifying the authenticity of messages. Authentication != authorization, though I know that prevailing paradigms conflate the two. You can see oauth bearer tokens, for instance, as authority without authentication (even if authentication was used to obtain them, and it isn't always).

That's the problem: a move from authentication to verify who is saying things to authentication as a form of authorization. I know it isn't obvious that this is a risk, and while there is academic'ish literature out there that explains it, I need to distill what risks we are facing here for an AP-implementor audience (we've done a bit more to explain the general concepts in this episode of Libre Lounge but it isn't "targeted" at the risks to moving to this model for authorization on the fediverse specifically).

Anyway, I'm off to write.

EDIT: Another source of confusion is that the words "authorization" and "authentication" sound so damn similar in english, leaving me to even mix up the two while trying to explain things in this post. Fixed.

[ClearlyClaire]

Upstream now signs fetch requests with a dedicated actor not representing an user in particular, and the anti-spam can be disabled from the admin interface.

Therefore, I am ready to merge this into glitch-soc.

The code for requiring authentication for fetches is here and can be enabled, but its use is not encouraged nor documented. I don't think having it in changes anything wrt. our ability to switch to an ocap-based approach when that starts being sufficiently well specified.