Author: Akihiko Odaki <akihiko.odaki.4i@stu.hosei.ac.jp>
Copyright © 2017 Akihiko Odaki. Licensed under CC0 1.0.
This specification describes how [ActivityPub] implementation should handle [Intent Class In Activity Streams 2.0 Vocabulary].
This section is non-normative.
This draft is written to implement intent feature in Mastodon, an [ActivityPub] implementation. The author is glad to use Mastodon utilizing the protocol, and hope further development and other applications of [ActivityPub].
This section describes the status of this document at the time of its publication. Other documents may supersede this document.
This document was published by the author as a proposal for Mastodon
and other [ActivityPub] applications. Please write comments
regarding this document to the following issue in Mastodon:
URL scheme
for remote follow, share buttons · Issue #2291 ·
tootsuite/mastodon
This document is expected to be useful also for other Activity Streams applications. If you have any request to change for them, please contact the author. E-mail is the most reliable means for that, but OStatus2 is also acceptable. Send a note to @fn_aki@pawoo.net.
[Intent Class In Activity Streams 2.0 Vocabulary] defines a class named
Intent. The class does not exist in [Activity Vocabulary],
which [ActivityPub] relies on. This document extends ActivityPub to
handle the instance.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Clients of [ActivityPub] can consume intents to perform activities described with intents.
Intents MUST be described as an instance of [Intent Class In Activity
Streams 2.0 Vocabulary]. object property of the instance
MUST contain a single Activity (which MAY contain embedded objects), or
a single non-Activity object which will be wrapped in a Create Activity
by the client.
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "https://akihikodaki.github.io/activity-intent/ns#Intent",
"summary": "Mallory is going to follow someone",
"actor": "https://example.net/~mallory",
"object": {
"type": "Follow"
}
}The client then prepares the body of the POST request
which would be performed in a client to server intraction of
[ActivityPub]. The body MUST contain an object produced by the
following procedure or an equivalent. Here, the object is called as
message.
If an instance has values for some of actor,
result, origin, and instrument
property and object property is an Activity of
[ActivityPub] without those properties, or a non-Activity object, the
message MUST be an Activity. If object property is
an Activity, the property MUST be copied as the message.
Otherwise, the message MUST be a Create Acitivy of
[ActivityPub], and object property MUST be attached as its
object property.
If an instance does not have values for any of actor,
result, origin, and instrument
property, object property MUST be copied as the
message.
In case the client MUST wrap an object in a Create Activity, the client MUST follow the procedure as servers do in client to server intractions in [ActivityPub].
actor and non-Activity
object{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "https://akihikodaki.github.io/activity-intent/ns#Intent",
"summary": "Mallory is creating a note",
"actor": "https://example.net/~mallory",
"object": {
"type": "Note",
"content": "This is a note",
"published": "2015-02-10T15:04:55Z",
"to": ["https://example.org/~john/"],
"cc": ["https://example.com/~erik/followers",
"https://www.w3.org/ns/activitystreams#Public"]
}
}The above example could result in this:
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Create",
"id": "https://example.net/~mallory/87374"
"actor": "https://example.net/~mallory",
"object": {
"id": "https://example.com/~mallory/note/72",
"type": "Note",
"attributedTo": "https://example.net/~mallory",
"content": "This is a note",
"published": "2015-02-10T15:04:55Z",
"to": ["https://example.org/~john/"],
"cc": ["https://example.com/~erik/followers",
"https://www.w3.org/ns/activitystreams#Public"]
},
"published": "2015-02-10T15:04:55Z",
"to": ["https://example.org/~john/"],
"cc": ["https://example.com/~erik/followers",
"https://www.w3.org/ns/activitystreams#Public"]
}A client MAY edit properties in the message. A provider of intents MUST NOT assume an intended activity will be always performed without any change.
This section is non-normative.
Some activities MAY NOT have a clear meaning as intent objects. For example, it is quite a unclear that an intent of an intent means. Some MAY NOT be simply supported by the receiver as intent objects.
A provider of an intent SHOULD NOT assume a particular activity is supported as an intent object by any receivers. A public provider of an intent SHOULD provide a fallback in case that the receiver could not process the intent.
This section is non-normative.
The main use case of Intent class are deliveries of intents declared at locations different from those where the activity to be performed. Locations MAY NOT be physical, but they could be Web sites, offline storage media, or anything which can save representations of Activity Streams.
For example, Web sites may have a hyperlink to an intent to follow its author.
A person may pass a representation of Activity Streams to someone who met offline to make it easy for him or her to follow the person.
Intent classThis section is non-normative.
A consumer of Intent class SHOULD advertise the use of
Intent for potential providers.
This section is non-normative.
This specification does not provide any means to assure authenticity of the intent. An intent from an entity and/or through a transportation without authenticity MUST be reviewed by the actor.