FEP-7628: Move actor

Standards Fediverse Enhancement Proposals
, ,
22

Perhaps the elephant in the room is bluesky, which uses a DNS-based system to advertise/discover a DID-anchored actor object. While Bluesky worked with Namecheap to make a turnkey system for using a DNS you control as your “handle” for your bluesky DID, I think @erlend mentioned in another thread that his team is working on just such a turnkey approach for connecting the DNS namespace with an ActivityPub actor with automated webfinger setup and headless services from one or more AP implementations allowing this kind of detached identity.

1 Like
23

Implementations SHOULD signal their support for this specification by including "https://w3id.org/fep/7628" in the @context array of their Actors, as this will clearly signal that the ABSENCE of a movedTo or copiedTo property indicates a currently-active Actor.

this is greatly misusing @context and also doesn’t even seem to be necessary at all?

1 Like
24

I think a practical drawback of this is that it’s incompatible with RDF-based signatures because the exact @context URL wouldn’t be secured by the signature, allowing an adversary-in-the-middle to falsify the intended semantics by adding the @context URL or replacing one with another semantically-equivalent representation.

25

TBH i’m not wed to it, I thought it would be a simple way of explicitly stating support for this convention so that the absence of as:Tombstone could be taken as definitive statement of non-deactivation. How else do you know that an Actor is hosted by an implementation that doesn’t signal de-activation in some other way? I’m honestly open to alternatives…

Sorry, not sure I follow. Are you saying that _checking for the @context URL is an unreliable proxy for the RDF expansion, or are you saying that the requirement to include a specific URL in @context breaks signing and verifying? The former I know (and, as above, opted for anyways to accomodate the “polyglot truce”), while the latter… I don’t understand (ELI5, i’m not actually very smart about this stuff)

26

declaring a jsonld context doesn’t make any sort of statement, though – it’s purely a mechanism to provide syntactic sugar for translating terms into IRIs and vice-versa. you’re not supposed to derive any additional information from it – not even schema stuff, but especially not predicate logic. for that, you should use a standard triple/property. something like active: true would work, where active is a shorthand term for some other IRI, which is what you should actually put in @context:

{
  "@context":
  [
    "https://www.w3.org/ns/activitystreams",
    {
      "active": "https://w3id.org/fep/e965/active"
    }
  ],
  "id": "https://example.com/some-actor",
  "type": "Person",
  "inbox": "https://example.com/some-inbox"
  "active": true
}

remember, without the @context declaration, this is what the equivalent statement would look like:

{
  // ...
  "https://w3id.org/fep/e965/active": true,
  // ...
}

keep in mind that the purpose of @context is to solve cases where some other predicate might share the same shorthand term. take the following example of “active” meaning that the actor is not disabled at a service level, as well as “active” meaning that the actor is currently online and connected, as well as “active” meaning that the actor is performing physical exercise. this is what it would look like without LD awareness:

{
  // ...
  "active1": true.
  "active2": true,
  "active3": false,
  // ...
}

now, who’s to say which sense of the word gets mapped to definition 1, 2, 3? it actually comes down to whoever sets the @context. this context mapping can be provided by the producer, or the consumer can set their own context mapping based on what they understand (after expanding the producer’s document according to the producer’s content mapping).

in unambiguous terms, i.e. JSON-LD expanded form, this is what it could look like:

{
  "https://w3id.org/fep/e965/active": {"@value": true},
  "https://social.example/vocabs/userProfile#active": {"@value": true},
  "https://health.example/active": {"@value": false}
}

compacting this expanded form document requires that you provide some context document to compact against. it is within that context document that you end up disambiguating each sense of “active”. but the terms / property names that you choose are completely arbitrary. you could call them active1, active2, active3, or you could call them accountIsActive, currentlyOnline, physicallyFit – the beauty is that we don’t have to agree.

2 Likes
27

This is a bigger change, but maybe unavoidable and obviously more explicit. I’ll have a think on it! The lazy alternative is just to drop the whole concept of certainty; even if "active": true were included in the FEP, I would probably make it a SHOULD anyways, because an implementation not declaring each user active but otherwise using movedTo, copiedTo and as:Tombstone appropriately should probably be considered conformant (enough) without also adding this…

28

In a technical sense, I meant the former. But I believe that giving an adversary control over the recipients’ interpretation of the message even in the slightest without making the verification fail is a vulnerability, so I phrased it as “incompatible” in a practical sense.

2 Likes
29

Update: I removed the whole @context-check aspect and didn’t replace it with a more explicit "active":true for now-- on reflection I thought that would make more sense as a separate FEP anyways, since the main goal here was to retro-spec existing implementations without requiring new work of them, while making implementation of compatibility portability mechanisms more testable and thus easier for the rest of implementations to join suit in implementing.

Appreciate the ELI5ing, @tesaguri and @trwnh ! it takes a village :muscle:

2 Likes