From e4ca79c28f3eae9e73ddd08e252ac62e07a8502c Mon Sep 17 00:00:00 2001 From: fr33domlover Date: Wed, 29 May 2019 08:31:07 +0000 Subject: [PATCH] FEDERATION.md: Write non-actor audience proposal --- FEDERATION.md | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) 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