IMO some things that would help tremendously and that would be good to prioritize, ways:

* Of having a persistent identifier that is decoupled from your server. Whether this looks like the current #VC and #DID proposals is less important than that the decoupling takes place.

* Of sharing and pooling moderation, load, storage, privacy, and security resources (see my previous discussion of #APAF/#ActivityPubApplicationFirewall or #APRL).

Well. To start with you could install it on top of _any_ (HTTP-based) #ActivityPub based system and it could manage a lot of the elements of initial handshakes for the various systems. This makes it significantly easier to build AP systems.

Also having a common rules language (or set thereof) and ability to set standards is really powerful.

You can provide it as a service almost trivially.

You could also set multiple AP servers behind one #APAF system, sharing rules and setup.

Well, rather than having my instance deal with it first, #APAF is the first to see the message and the first to interact with it. It implements a series of security rules and can ascertain a few different things to give it a more nuanced decision process:

1. It could read the person's profile and posts
2. It could see if anyone on the server is following them already.
3. It could look at how many such requests this individual has made
4. It could look at the user's history of interactions

So Alice on server A (SA) receives a follow request from Bob on server B (SB).

Right now it goes to your local service and one of a few outcomes generally happen (along with a few additional error cases):

1. It is automatically approved.
2. It is automatically rejected by either your preferences or by personal or server blocklist.
3. It is given to you to to accept or reject.

What could #APAF do for us here?

As a thought experiment, let's imagine a WAF for #ActivityPub. We'll all it #APAF for Activity Pub Application Firewall or, "AP as F" if you prefer.

This is not an ActivityPub service. Instead this works like a layer—think reverse proxy—that you set in front of your ActivityPub system. It understands the APIs used by AP systems, can read your local information, and can enforce rules.

It can also annotate messages.