diff --git a/FEDERATION.md b/FEDERATION.md
index 87bb2b5..603a150 100644
--- a/FEDERATION.md
+++ b/FEDERATION.md
@@ -371,8 +371,92 @@ Rotate 1 key per hour. Especially if that key is Ed25519.
 
 ### (B) ActivityPub
 
+The following proposals are federation features in Vervis, or plans and ideas
+not implemented yet, but they aren't specific to forges, and other kinds of
+servers can benefit from them just as much.
+
 #### (1) Non-actor audience
 
+In C2S, the client sends the server an activity (or an object to be wrapped in
+a `Create`) that includes addressing properties, and the server delivers the
+activity to the listed recipients. The recipients may be listed as URIs or as
+embedded objects, and the audience can be anything, any Object, according to
+the AS2 vocabulary spec. Not limited to actors or collections. However, there
+are 2 kinds of recipients:
+
+- Actors: Recipients that have inboxes and you HTTP deliver the activity to
+  them.
+- Non-actors: Recipients to whom you don't directly HTTP deliver, but possibly
+  you dereference them in some way and a list of more actors to deliver to.
+  Usually these non-actor recipients are Collections, and they are resolved
+  into lists of actors, and delivery to them sometimes involves inbox
+  forwarding.
+
+If the server gets just a list of URIs, some of which are on other servers, it
+has to HTTP GET them, and find out that some are actors and some are
+collections (or other non-actor objects). It may also do caching, remembering
+remote actors and collections in its database to avoid HTTP GETing them every
+time, but even then, it involves the initial GET where it fetches them and
+remembers in the DB.
+
+Observation: Very possibly, the client is *aware* which recipients are actors
+and which aren't. Especially when the non-actors are collections. So, the
+client can *hint* the server about that, so that the server doesn't even need
+to do the initial GET for recipients already known to be non-actors.
+
+There are 2 ways specified below, for making that hint. One is what Vervis
+currently does, and the other is perhaps a better way I'd like to propose as an
+alternative, and possibly switch Vervis to that better way.
+
+What Vervis currently does is to use a custom `nonActors` property, which lists
+recipients. The client uses that property to provide a list of recipients that
+are known to be non-actors. For example if the `to` property is `[x,y,z]` and
+the `nonActors` field is `[y]`, then the server can skip trying to GET the `y`
+recipient, and attempt delivery only to `x` and `z`.
+
+Another way, which is perhaps better and I'd like to propose, is to allow the
+client to specify the type of the recipient in the addressing properties
+themselves. For example, instead of this:
+
+```json
+[ "https://example.dev/users/martin"
+, "https://example.dev/users/martin/followers"
+]
+```
+
+We could do this:
+
+```json
+[ { "id":   "https://example.dev/users/martin"
+  , "type": "Person"
+  }
+, { "id":   "https://example.dev/users/martin/followers"
+  , "type": "Collection"
+  }
+]
+```
+
+The problem is:
+
+- There's no `Actor` type in ActivityPub, and if you use some custom actor type
+  that the server doesn't recognize, it will have to GET the recipient to be
+  sure.
+- There could be a custom type that is a subclass of `Collection`, and if the
+  server doesn't recognize it, it will have to GET the recipient to be sure.
+
+Since this is just a hint, and it's C2S where the client and server *possibly*
+speak the same custom properties, these problems don't make the hint useless,
+but they still make this approach inferior in achieving its goal, than the
+custom `nonActors` property. The reason I propose it is that it uses object's
+types and doesn't require any custom property. The reason Vervis doesn't use it
+is that I don't see a clear way to *really* in practice tell actors from
+non-actors. It also requires more computation and coding, to figure out which
+things are subclasses of some actor type, or collection type, and if that's
+required then RDF inference is required, therefore JSON-LD processing is
+required. While in the `nonActors` approach, which maybe feels more like a
+trick, it's as simple as computing set/list difference, which is generally
+trivial to do.
+
 #### (2) Authenticated inbox forwarding
 
 #### (3) Non-announced following