FEDERATION.md: Write non-actor audience proposal

This commit is contained in:
fr33domlover 2019-05-29 08:31:07 +00:00
parent 5712b06299
commit e4ca79c28f

View file

@ -371,8 +371,92 @@ Rotate 1 key per hour. Especially if that key is Ed25519.
### (B) ActivityPub ### (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 #### (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 #### (2) Authenticated inbox forwarding
#### (3) Non-announced following #### (3) Non-announced following