-
Notifications
You must be signed in to change notification settings - Fork 87
/
Copy pathActivityPump.html
627 lines (597 loc) · 30.8 KB
/
ActivityPump.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
<!DOCTYPE html>
<html>
<head>
<title>ActivityPump</title>
<meta charset='utf-8'>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
async class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "unofficial",
shortName: "activitypump",
editors: [
{ name: "Owen Shepherd",
url: "http://owenshepherd.net/",
mailto: "owen.shepherd@e43.eu" },
],
localBiblio: {
"ActivityStreams": {
title: "ActivityStreams 2.0",
href: "http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2.html",
authors: [
"J. Snell",
],
status: "Editors Draft",
publisher: "ActivityStreams Working Group",
},
"RFC7033": {
title: "WebFinger",
href: "http://www.ietf.org/rfc/rfc7033.txt",
authors: [
"P. Jones",
"G. Salgueiro",
"M. Jones",
"J. Smarr",
],
status: "RFC",
publisher: "IETF",
},
// Informative
"RFC4287": {
title: "The Atom Syndication Format",
href: "http://www.ietf.org/rfc/rfc4287.txt",
authors: [
"M. Nottingham",
"R. Sayre",
],
status: "RFC",
publisher: "IETF"
},
"PUSH": {
title: "PubSubHubub",
href: "https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html",
authors: [
"B. Fitzpatrick",
"B. Slatkin",
"M. Atkins",
"J. Genestoux",
],
status: "Working Draft",
},
"Salmon": {
title: "The Salmon Protocol",
href: "http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-salmon-00.html",
authors: [
"J. Panzer",
],
status: "Published",
}
},
};
</script>
</head>
<body>
<section id='abstract'>
<p>The ActivityPump protocol is a social networking protocol based upon
the ActivityStreams 2.0 data format. It is based upon experience gained from
implementing and working with the OStatus and Pump.io protocols.</p>
</section>
<section id='sotd'>
<p>This document is a proposed submission to the W3C Social working
group</p>
</section>
<section class='informative'>
<h2>Background</h2>
<p>The ActivityPump specification takes knowledge that has been learned
through previous experimentation with standards for federated social
networking, such as OStatus, and applies them to produce a simpler and yet
more powerful whole. Where appropriate, it attempts to build upon other
existing protocols, but it replaces them where appropriate.</p>
<section>
<h2>Building Blocks</h2>
<p>The two core building blocks selected for the protocol are HTTP
([[!RFC2616]]) and [[!ActivityStreams]]; the former for its' ubiquity
and the latter for its' obvious application, expressiveness and
simplity. On top of this, WebFinger ([[!RFC7033]]) was selected for user
discovery and <b>TODO</b> for authentication.</p>
<p>Other building blocks were examined and discarded:</p>
<section>
<h2>PubSubHubub</h2>
<p>[[PUSH]] is a widely deployed protocol for the exchange of
notifications from a publisher to subscribers. Widely deployed,
[[PUSH]] can already be used to follow, in real time, the public
activity of millions of blogs.</p>
<p>However, [[PUSH]] was designed for a publishing and subscription
model in which all content is public, and while it is possible to
extend it to support non-public content, in doing so it becomes a very
different protocol. In addition, setting up [[PUSH]] subscriptions
becomes an additional "moving part" in the subscription machinery.</p>
<p>[[PUSH]] is not incompatible with ActivityPump in general, but by
the time the machinery to support private message delivery has been
added to the protocol, it becomes duplicative to additionally
implement [[PUSH]] for public message delivery; therefore, it is left
as an extension which implementations may implement at their leisure</p>
</section>
<section>
<h2>Salmon</h2>
<p>[[Salmon]] is a protocol for delivering responses to a post to the
original post's author. It was developed for Google Buzz as a method
of conveying comments posted on that platform back to the blog from
which the post originated.</p>
<p>It was used in the same fashion by OStatus in order to support
replies in conversations; in this regard delivering them to recipients
which may not subscribe to the post's author.</p>
<p>While Salmon works for this purpose, it is itself highly complex.
In addition, it is built upon ATOM [[RFC4287]], while this
specification is built upon [[!JSON]], and it invents its' own
authentication system which is both orthogonal to that used by the
rest of the protocol and highly complex. Finally, ActivityPump's
general post delivery mechanism provides the same functionality while
adding no additional complexity.</p>
</section>
</section>
<section id="Overview">
<h2>Overview</h2>
<p>The ActivityPump protocol is broadly based on the distribution of
<i>activities</i>, described using [[!ActivityStreams]]; these activities
are produced in response to a user performing an action. Most activities
are purely responsive in nature - they are produced as a response to a
user <i>having</i> done something. In addition, certain actions posted
by a user to their <a href="#outbox">outbox</a> may trigger certain
operations on the user's behalf. Finally, actions may have side effects
as they propogate throughout the social graph. As an example of this:</p>
<ol>
<li>A user posts the <code>like</code> activity to their outbox. This
activity causes the user's server to perform an action on behalf of
the user; in particular, it adds the specified object to the collection
of objects the user has liked.</li>
<li>A consequence of the above action (per
<a href="#notification"></a>) is that ths server hosting
the liked object will be notified of the operation, and will normally
add the activity to the list of "likes" the object has received</li>
<li>Finally, the server receiving the like will distribute this activity
to everyone it distributed the original object to</li>
</ol>
</section>
<section id="specification-profiles">
<h2>Specification Profiles</h2>
<p>This specification defines two closely related and interacting
protocols:</p>
<dl>
<dt>A client to server protocol, or "Social API"</dt>
<dd>This protocol permits a client to act <i>on behalf</i> of a user.
For example, this protocol is used by a mobile phone application to
interact with the user's social stream</dd>
<dt>A server to server protocol, or "Federation Protocol"</dt>
<dd>This protocol is used to distribute activities between users on
different servers, tying them into one social graph.</dd>
</dl>
<p>All servers claiming conformance to this specification are required to
implement the former protocol, and may optionally implement the latter.
This gives three conformance classes:</p>
<dl>
<dt>ActivityPump conformant Client</dt>
<dd>This designation applies to any implementation of the entirety
of the client portion of the client to server protocol</dd>
<dt>ActivityPump conformant Server</dt>
<dd>This designation applies to any implementation of the entirety
of the server portion of the client to server protocol</dd>
<dt>ActivityPump conformant Federated Server</dt>
<dd>This designation applies to any implementation of the entirety of
the server portion of both the client to server and federation
protocols</dd>
</dl>
<p>It is called out whenever a portion of the specification only applies
to implementation of the federation protocol. In addition, whenever
requirements are specified, it is called out whether they apply to the
client or server (for the client-to-server protocol) or which of a pair of
servers in the server-to-server protocol.</p>
</section>
</section>
<section id="obj">
<h2>Objects</h2>
<p>Objects are the core concept around which both [[!ActivityStreams]] and
ActivityPump are built. Objects can be divided into three main categories:
<a href="#activities">Activities</a>, <a href="#content-objects">Content
Objects</a> and <a href="#actors">Actors</a>, plus a small collection of
objects which do not fit into the previous categories such as
<a href="#groups">groups</a></p>
<p>Servers MUST validate the content they receive to avoid content spoofing
attacks. In particular, servers MUST NOT trust client submitted content, and
federated servers also MUST NOT trust content received from a server other than the content's
origin. Servers MUST validate such against its' originating server.</p>
<div class="informative">
As an example, if example.com receives the activity
<pre class="format">
{"verb": "like",
"actor": "https://example.net/~mallory",
"object": {
"@id": "https://example.org/~alice/note/23",
"author": "https://example.org/~alice",
"content": "I'm a goat"
}
}
</pre>
it should dereference the <code>id</code> both to ensure that it exists
and is a valid object, and that it is not misrepresenting the object
(In this example, Mallory is likely spoofing an object allegedly posted
by Alice)
</div>
<section id="obj-id">
<h2>Object Idenitifers</h2>
<p>All Objects in [[!ActivityStreams]] should have unique global identifiers.
ActivityPump extends this requirement; all objects distributed by the
ActivityPump protocol MUST have unique global identifiers; these identifiers
must fall into one of the following groups:</p>
<ol>
<li>HTTPS URIs with their authority belonging to that of their originating
server.</li>
<li>acct: account URIs with their authority belonging to their originating
server. This URI is only valid for objects of the <i>person</i> type. </li>
<li>An ID explicitly specified as the JSON <code>null</code> object, which
implies an anonymous object (a part of its' parent context)</li>
</ol>
<p>A server receiving an object with no specified <code>id</code> should
allocate an object ID in the user's namespace and attach it to the posted
object</p>
<p>All objects must have the following properties:</p>
<dl>
<dt>id</dt><dd>The objects' unique global identifier</dd>
<dt>self</dt><dd>For objects with an <code>acct</code> URI scheme, the
URI of a dereferencable document (see <a href="#obj-uri"></a>)</dd>
<dt>@type</dt><dd>The type of the object</dd>
</dl>
</section>
<section id="obj-uri">
<h2>Dereferencable Object URIs</h2>
<p>As illustrated by the example in the previous section, it is sometimes
necessary to dereference an object in order to retrieve its' contents. It
is therefore first necessary to identify the URI to dereference. The
procedure for doing this depends upon which of the URI groups defined in
the previous section the ID belongs to</p>
<ol>
<li>If the object's ID is a HTTPS URI, it must be directly dereferencable</li>
<li>If the object posesses a URI with the <code>acct</code> scheme, it
must contain a <code>self</code> property with the dereferencable URI.
If the dereferencer does not posess the object, then it should perform
[[!RFC7033]] discovery on the URI to find a link with the <code>self</code>
relation and <code>application/activitystreams+json</code> media type</li>
<li>Objects with a <code>null</code> ID have no authority and are not
dereferencable (their content is a part of their parent object)</li>
</ol>
</section>
<section id="obj-methods">
<h2>Methods on objects</h2>
<p>There are several common operations upon social social objects, which
are expressed using standard HTTP methods applied to the Object's
<a href="#obj-uri">dereferencable URI</a>. To avoid conflict with existing
standards (and hence support "multiprotocol" server implemnetations),
the scope of requests which servers are required to honor as defined in
this specification is limited as follows:</p>
<ul>
<li>Notwithstanding the following, the <code>DELETE</code> method will
always be honored as specified in <a href="#method-delete"></a></li>
<li>All non-idempotent operations shall have a request body.</li>
<li>For all operations with a request body, it MUST have the media type
<code>application/activitystreams+json</code>, or where explicitly
permitted the <code>multipart/related</code> media type with a root part
of type <code>application/activitystreams+json</code></li>
<li>Servers MAY use HTTP content notification as defined in [[!RFC7231]]
to select the type of data to return in response to a request. For
requests without a body, an <code>Accept</code> header MUST be
specified, and the behavior defined by this specification ONLY applies
if content negotion results in the selection of the
<code>application/activitystreams+json</code> media type. For requests
with a body, the client MAY omit the <code>Accept</code> header, in
which case the server MUST provide successful responses as defined by this
specification</li>
</ul>
<p>Servers MAY implement other behavior for requests which do not comply
with the above requirements (for example, servers may implement additional
legacy protocols, or may use the same URI for both HTML and
ActivityStreams representations of a resource)</p>
<p>Servers MAY require authorization as specified in
<a href="#authorization"></a>, and may additionally implement their own
authentication rules. Servers SHOULD fail requests which do not pass their
authorization or authentication checks with the appropriate HTTP error
code, or the 404 Not Found error code where the existence of the object
is considered private.</p>
<section id="method-get">
<h2>The <code>GET</code> method</h2>
<p>The GET method shall return an up-to-date version of the object</p>
</section>
<section id="method-put">
<h2>The <code>PUT</code> method</h2>
<p><b>This method requires <a href="#authorization-user">user authorization</a></b></p>
<p>The PUT method may be used by a client to update the version of the
object stored on the server.</p>
<p>The server MUST insert an activity with the <code>updated</code> verb
and this object as its' <code>object</code> into the actor's
<a href="#outbox">feed</a></p>
</section>
<section id="method-delete">
<h2>The <code>DELETE</code> method</h2>
<p><b>This method requires <a href="#authorization-user">user authorization</a></b></p>
<p>The <code>DELETE</code> method may be used by a client to delete the
object. If successful, all requests to the URI which would have
previously been successful SHOULD return the 410 Gone response code</p>
</section>
<section id="method-notify">
<h2>The <code>NOTIFY</code> method</h2>
<p><b>This method is only applicable to federated implementations</b></p>
<p><b>This method requires <a href="#authorization-origin">origin authorization</a></b></p>
<p>The <code>NOTIFY</code> method is used in cross-server communication in
order to perform accurate cross server notification and delivery as
documented in <a href="#notification"></a></p>
</section>
</section>
</section>
<section id="actors">
<h2>Actors</h2>
<p>Actors in ActivityPump are represented by any URI on which discovery may
be done per [[!RFC7033]]. When entered directly into a user interface (for
example on a login form), it is desirable to support simplified naming. For
this purpose cases, ID normalization SHOULD be performed as follows:</p>
<ol>
<li>If the entered ID is a valid URI, then it is to be used directly</li>
<li>If the entered ID is in the form which would be valid as an E-Mail
address, per [[!RFC5322]] section 3.4.1, then the ID shall be
interpreted by taking the entered value and using it as the path
component of a URI with the <code>acct</code> scheme.</li>
<li>If the entered ID is in the form which would be a valid DNS name as
defined in [[!RFC1034]], then it shall be interpreted as a
<acct>https</acct> URI whereby the hostname portion is the entered value
and the path portion is empty.</li>
<li>Otherwise, the entered value should be considered invalid</li>
</ol>
<p>Once the actor's URI has been identified, it should be dereferenced as per
<a href="#obj-dereference"></a></p>
<section id="actor-objects">
<h2><i>Actor</i> objects</h2>
<p>Actor objects are ActivityStrems objects which are subclasses of the
<code>actor</code> type. Actor objects MUST have, in addition to the
properties mandated by <a href="#obj-id"></a>, the following properties:</p>
<dl>
<dt>url</dt><dd>A link to the actor's "profile web page", if it is not
equal to the value of <code>id</code></dd>
<dt>following</dt><dd>An [[!ActivityStreams]] collection of the actors
that this actor is following</dd>
<dt>followers</dt><dd>An [[!ActivityStreams]] collection of the actors
that follow this actor</dd>
<dt>inbox</dt><dd>A reference to an [[!ActivityStreams]] collection comprising of all the
messages received by the actor; see <a href="#inbox"></a></dd>
<dt>outbox</dt><dd>An [[!ActivityStreams]] collection comprising of all the messages
produced by the actor; see <a href="#outbox"></a>
</dl>
<p>Implementations should, in addition, provide the following properties:</p>
<dl>
<dt>preferredUsername</dt><dd>A short username which may be used to
refer to the actor, with no uniqueness guarantees</dd>
<dt>displayName</dt><dd>The preferred "nickname" or "display name" of
the actor</dd>
<dt>summary</dt><dd>A quick summary or bio by the user about themself</dd>
<dt>icon</dt><dd>A media link to the user's profile picture (this may
be a thumbnail)</dd>
</dl>
<pre class="example">
{
"@type": "person",
"@id": "https://johnsmith.example.com/",
"following": "https://johnsmith.example.com/following.json",
"followers": "https://johnsmith.example.com/followers.json",
"inbox": "https://johnsmith.example.com/inbox.json",
"outbox": "https://johnsmith.example.com/feed.json",
"preferredUsername": "johnsmith",
"displayName": "John Smith",
"summary": "Just an example guy",
"icon": [
"https://johnsmith.example.com/image/165987aklre4"
]
}
</pre>
</section>
</section>
<section id="authorization">
<h2>Authorization</h2>
<p><b>This is a stub, to be expanded. OAuth 2.0 is an open question.</b></p>
<p>ActivityPump uses authorization for two purposes; first, to
authenticate clients to servers, and secondly in federated implementations
to authenticate servers to each other. These methods are based upon the
OAuth 2.0 authorization framework as specified in [[!RFC6749]]. </p>
<section id="authorization-user">
<h2>User Authentication</h2>
<p>User authentication is used in order to identify clients acting on
behalf of an <a href="#actors">actor</a> their origin server, and for
federated implementations to other servers. There are two types of
authentication permitted for this:</p>
<section id="authorization-user-bearer">
<h2>Bearer Authorization</h2>
<p>For clients which only need to interact with the user's origin server,
or communicating with a non-federated server, clients may use OAuth 2.0
bearer tokens</p>
</section>
<section id="authorization-user-jws">
<h2>JSON Web Signature authorization</h2>
<p><b>This method is only mandatory for federated implementations</b></p>
<p>For clients which need to interact with servers beyond the user's
origin server, clients MUST support use of OAuth 2.0 with JSON Web
Signatures</p>
</section>
</section>
<section id="authorization-origin">
<h2>Origin Authorization</h2>
<p><b>This method is only applicable to federated implementations</b></p>
<p>A server performing an operation on behalf of an actor (e.g. delivery
to a recipient) must authenticate itself with the 3rd party server as
such. One method for doing so is defined in this specification.</p>
<section id="authorization-origin-jws">
<h2>JSON Web Signature authorization</h2>
<p>Servers MUST support use of OAuth 2.0 with JSON Web Signatures</p>
</section>
</section>
</section>
<section id="collections">
<h2>Collections and Streams</h2>
<p>[[!ActivityStreams]] defines the collection concept; ActivityPump defines several
collections with special behavior. Additionally, it defines a subset of
collections termed <a href="#streams">streams</a>. </p>
<section id="followers">
<h2>Followers Collection</h2>
<p>Every <a href="#actors">actor</a> MUST have a followers collection.
This is the default recipient list for otherwise unaddressed activities,
and additionally is used as a distribution target for any activities
addressed to the <a href="#public"></a></p>
</section>
<section id="following">
<h2>Following Collection</h2>
<p>Every actor MAY have a following collection. This is a list of everybody
that the actor has followed</p>
</section>
<section id="favorites">
<h2>Favorites Collection</h2>
<p>Every actor MAY have a favorites collection. This is a list of every
object that the actor has favorited (See <a href="#activity-favorite"></a>)
</p>
</section>
<section id="streams">
<h2>Streams</h2>
<p>The streams nomencluture is applied to any collection comprosed purely of
activities. These objects should be so declared using the <code>objectTypes</code>
property:</p>
<pre class="formatted">
{
"id": "https://example.com/~alice/my-stream",
"objectType": "collection",
"objectTypes": ["activity"]
"items": [ ... ]
}
</pre>
<p>Streams are always presented in reverse chronological order</p>
<section id="outbox">
<h2>Outbox</h2>
<p>The <code>outbox</code> stream contains every object that the user
has ever published, subject to the ability of the requestor to retrieve
the object (That is, the contents of the outbox are filtered by the
permissions of the person reading it)</p>
<p>A client may submit an [[!ActivityStreams]] activity to the server
using a HTTP POST request to the dereferencable URI of the outbox collection.
In this case, the request's Content-Type MUST
be <code>application/activitystreams+json</code>, and the request MUST be authenticated
with credentials authorized to act on behalf of the user to whom the
outbox belongs. Such submitted activities will be added to the front of
the feed retrieved by GET requests to the same endpoint.</p>
</section>
<section id="inbox">
<h2>Inbox</h2>
<p>The <code>inbox</code> stream contains all objects received by the user.
The inbox MUST be filtered acording to the requestors' permission; this
MAY include allowing read access only to the owning user</p>
<p>A server may submit a HTTP POST to the <a href="#obj-dereference">
dereferencable URI</a> of the <code>inbox</code> endpoint. This request
MUST be authenticated with the credentials of the user identified by the
<code>actor</code> stanza of the activity being delivered. The request
MUST be of the [[!ActivityStreams]] content type; it MUST be a single activity.</p>
<p>The server MUST perform de-duplication of activities, whereby it
discards repeats of already delivered activities (this can occur if an
activity is addressed both to a user's followers, and a specific user
which happens to follow said user, and the server has failed to
de-duplicate the recipients list, for example). Such deduplication MUST
be performed by comparing the <code>id</code> of the activities and
dropping any activities already seen.</p>
</section>
</section>
</section>
<section id="notification-and-delivery">
<h2>Notification and Delivery</h2>
<p>Notification and Delivery are two closely related acts. Notifications are
sent to <i>objects</i> and are used to perform updates on the
social graph, whilst delivery is the act of inserting an activity into a
recipient <i>agent's</i> inbox</p>
<section id="delivery">
<h2>Delivery</h2>
<p>Activity distribution and access control is per the audience targetting
properties from the [[!ActivityStreams]] specification. For each entry in the
addressing properties of an object, the server shall</p>
<ol>
<li>If the entry is a collection, then the server MUST dereference the
collection (with the user's credentials) and add each person in the
collection to the list of recipients for the message. Servers MUST
limit the number of layers of indirections through collections which
will be performed, which MAY be one.
<li>If the entry is not a collection, then the server MUST perform
discovery on the object (which may not be of person
<code>objectType</code>) to discover its' activity-inbox address
<li>Once the complete list of recipients has been determined, the
server MUST then deliver the activity to each recipient. For a federated
implementation, this must be done by performing a HTTP POST, with prohom
authorization as the submitting user, of the submitted activity body to
the URI of the <a href="#inbox">inbox</a> collection of each recipient
</ol>
<p>For federated servers performing delivery to a 3rd partry server,
delivery SHOULD be performed asynchronously to completion of
the original activity submission request, and SHOULD additionally retry
delivery to recipients if it fails due to network error</p>
<p>If no recipients are specified, the user's preferred default audience
should be applied. The default value for the default audience is
implementation specific but MAY be the user's
<a href="#followers">followers</a> collection</p>
<p>In addition to delivery to recipients, the server MUST also perform
notification as specified by <a href="#notification"></a></p>
</section>
<section id="notification">
<h2>Notification</h2>
<p>When a user creates an activity (by submitting it to their
<a href="#outbox">outbox</a>), the server should perform <i>notification</i>.
Notification is the process of propogating awareness of the new activity to
the activity's origin server such that the origin can act upon the activity
(for example, notification that a user has liked an object is used to update
the objects' like count) and distribute the activity to ensure that it is
propogated to the whole social graph which received the original object.</p>
<p>Notifications shall be sent to each of the following objects:</p>
<ul>
<li>The Objects specified by the activity's "object" and "target" properties</li>
<li>Any Objects specified in the activuty object's "inReplyTo" property</li>
</ul>
<p>Servers may perform notification to local objects as they choose.
Federated servers MUST notify remote objects using the
<a href="#method-notify">NOTIFY</a> method except by agreement with the
3rd party server.</p>
<p>An object notified of an activity MUST <a href="#delivery">deliver</a>
that activity to all <a href="#object-recipient">recipients of the object</a>
and in addition notify all <a href="#activity-share">share activities</a>
of the object.</p>
</section>
<section id="public-addressing">
<h2>Public Addressing</h2>
<p>In addition to [[!ActivityStreams]] collections and objects,
Activities may additionally be addressed to the special "public"
audience denoted by the object</p>
<pre>
{
"@id": "http://activityschema.org/collection/public",
"@type": "collection"
}
</pre>
<p>Activities addressed to this special URI shall be accessible to all
users, without authentication.</p>
<p>For the purposes of delivery, the server shall treat the public
collection as if it contains the same entries as the user's
<a href="#followers">followers collection</a>.
<p>TODO: New URI? Can we get as:public in the schema or such?</p>
</section>
</section>
<section id="content-objects">
<h2>Content Objects</h2>
<p><b>TODO. Cover replies, etc</b></p>
</section>
<section id="activities">
<h2>Activities</h2>
<p>The core of any [[!ActivityStreams]] based protocol is activities within.
Users post activities to their <a href="#outbox">outbox</a>, from which they
are distributed to recipients' <a href="#inbox">inboxes</a>. ActivityPump
places no restrictions on the activities which may be distributed; however,
it defines certain activities with special behaviors</p>
<p>TODO</p>
</section>
</body>
</html>