-
Notifications
You must be signed in to change notification settings - Fork 0
/
buddycloud.html
executable file
·1438 lines (1372 loc) · 74.5 KB
/
buddycloud.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
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>XEP-xxxx: Buddycloud Channels</title><link rel="stylesheet" type="text/css" href="../xmpp.css" /><link href="../prettify.css" type="text/css" rel="stylesheet" /><link rel="shortcut icon" type="image/x-icon" href="/favicon.ico" /><script type="text/javascript" src="../prettify.js"></script><meta name="DC.Title" content="Buddycloud Channels" /><meta name="DC.Creator" content="Simon Tennant" /><meta name="DC.Creator" content="Ashley Ward" /><meta name="DC.Description" content="This document describes a profile and conventions for usage 			of the PubSub protocol in the context of a new type of communication." /><meta name="DC.Publisher" content="XMPP Standards Foundation" /><meta name="DC.Contributor" content="XMPP Extensions Editor" /><meta name="DC.Date" content="2014-01-xx" /><meta name="DC.Type" content="XMPP Extension Protocol" /><meta name="DC.Format" content="XHTML" /><meta name="DC.Identifier" content="XEP-xxxx" /><meta name="DC.Language" content="en" /><meta name="DC.Rights" content="This XMPP Extension Protocol is copyright (c) 1999 - 2010 				by the XMPP Standards Foundation (XSF). 			" /></head><body onload="prettyPrint()"><h1>XEP-xxxx: Buddycloud Channels</h1><table><tr valign="top"><td><strong>Abstract:</strong></td><td>This document describes a profile and conventions for usage
of the PubSub protocol in the context of a new type of communication.</td></tr><tr valign="top"><td><strong>Authors:</strong></td><td>Simon Tennant, Ashley Ward</td></tr><tr valign="top"><td><strong>Copyright:</strong></td><td>© 1999 - 2010 XMPP Standards Foundation. <a href="#appendix-legal">SEE LEGAL NOTICES</a>.</td></tr><tr valign="top"><td><strong>Status:</strong></td><td>ProtoXEP</td></tr><tr valign="top"><td><strong>Type:</strong></td><td>Standards Track</td></tr><tr valign="top"><td><strong>Version:</strong></td><td>0.0.1</td></tr><tr valign="top"><td><strong>Last Updated:</strong></td><td>2014-01-xx</td></tr></table><hr /><p style="color:red">WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <<a href="http://xmpp.org/extensions/">http://xmpp.org/extensions/</a>> and announced on the <standards@xmpp.org> mailing list.</p><hr /><h2>Table of Contents</h2><div class="indent"><p><br />1. <a href="#intro">Buddycloud Introduction</a><br />2. <a href="#reqs">Requirements</a><br />3. <a href="#glossary">Glossary</a><br />4. <a href="#preliminaries">Preliminaries</a><br />
4.1. <a href="#preliminaries-businesslogic">Business Logic</a><br />
4.2. <a href="#sect-idm167522553520">The Buddycloud Inbox</a><br />
4.2.1. <a href="#sect-idm167522551632">Inbox Discovery</a><br />
4.2.2. <a href="#sect-idm167522549056">Inbox Authorization</a><br />
4.2.3. <a href="#sect-idm167522545376">Partition Detection</a><br />
4.3. <a href="#preliminaries-channelnodes">Channel Nodes</a><br />
4.3.1. <a href="#preliminaries-channelnodes-ids">Channel NodeIDs</a><br />
4.3.2. <a href="#preliminaries-channelnodes-types">Node Types</a><br />
4.4. <a href="#preliminaries-channelmetadata">Channel Metadata</a><br />
4.4.1. <a href="#preliminaries-channelmetadata-accessmodel">Channel Access Model</a><br />
4.4.2. <a href="#preliminaries-channelmetadata-affiliations">Channel Affiliations</a><br />
4.4.2.1. <a href="#preliminaries-channelmetadata-affiliations-default">Default Affiliations</a><br />5. <a href="#entityusecases">Entity Use Cases</a><br />
5.1. <a href="#entityusecases-servicediscovery">Service Discovery</a><br />
5.2. <a href="#entityusecases-verifyserver">Verify the Authority of a Server for a JID</a><br />
5.3. <a href="#entityusecases-register">Register with the Service</a><br />6. <a href="#publisherusecases">Publisher Use Cases</a><br />
6.1. <a href="#publisherusecases-post">Post to a Channel</a><br />
6.1.1. <a href="#publisherusecases-post-normalization">Content normalization</a><br />
6.2. <a href="#publisherusecases-replytopost">Reply to a Post</a><br />
6.2.1. <a href="#publisherusecases-replytopost-errors">Error Conditions</a><br />
6.2.1.1. <a href="#publisherusecases-replytopost-errors-replytoreply">The client attempts to post a Reply to a Reply</a><br />
6.3. <a href="#publisherusecases-deletepost">Delete a Post</a><br />7. <a href="#subscriberusecases">Subscriber Use Cases</a><br />
7.1. <a href="#subscriberusecases-subscribe">Subscribe to a Channel</a><br />
7.2. <a href="#subscriberusecases-retrieverecentposts">Retrieve Recent Posts from all Subscribed Channels</a><br />
7.3. <a href="#subscriberusecases-newpostnotification">Receive a New Post Notification</a><br />
7.4. <a href="#subscriberusecases-allposts">Retrieve all Posts for a Node</a><br />
7.5. <a href="#sect-idm167522327936">Retrieve All Replies to a Single Post</a><br />
7.6. <a href="#sect-idm167522320400">Retrieve Entire Thread From a Single Post</a><br />8. <a href="#ownerusecases">Owner Use Cases</a><br />
8.1. <a href="#ownerusecases-createchannel">Create a Channel</a><br />
8.2. <a href="#ownerusecases-changeaffiliation">Change a Subscriber"s Affiliation</a><br />9. <a href="#rules">Business Rules</a><br />
9.1. <a href="#rules-nodeaffiliations">Maintain Similar Affiliations across Channel Nodes</a><br />10. <a href="#impl">Implementation Notes</a><br />
10.1. <a href="#impl-timestamp">Timestamp Preservation</a><br />
10.2. <a href="#impl-caching">Inbox Caching</a><br />11. <a href="#access">Accessibility Considerations</a><br />12. <a href="#i18n">Internationalization Considerations</a><br />13. <a href="#security">Security Considerations</a><br />
13.1. <a href="#security-addressspoofing">Address Spoofing</a><br />
13.1.1. <a href="#security-addressspoofing-actor">Actor Spoofing</a><br />
13.1.2. <a href="#security-addressspoofing-node">Node Spoofing</a><br />
13.2. <a href="#security-xss">Cross Site Scripting ( XSS )</a><br />14. <a href="#iana">IANA Considerations</a><br />15. <a href="#registrar">XMPP Registrar Considerations</a><br />16. <a href="#schema">XML Schema</a><br />
16.1. <a href="#sect-idm167522251488">http://buddycloud.org/v1</a><br />
16.2. <a href="#sect-idm167522249664">http://buddycloud.org/v1#errors</a></p><p><a href="#appendices">Appendices</a><br /> <a href="#appendix-docinfo">A: Document Information</a><br /> <a href="#appendix-authorinfo">B: Author Information</a><br /> <a href="#appendix-legal">C: Legal Notices</a><br /> <a href="#appendix-xmpp">D: Relation to XMPP</a><br /> <a href="#appendix-discuss">E: Discussion Venue</a><br /> <a href="#appendix-conformance">F: Requirements Conformance</a><br /> <a href="#appendix-notes">G: Notes</a><br /> <a href="#appendix-revs">H: Revision History</a></p></div><hr /><h2>1.
<a name="intro" id="intro">Buddycloud Introduction</a></h2>
<p class="" style="">Buddycloud channels is a decentralised communication protocol that
enables synchronised communication in the form of channels between
Buddycloud-enabled domains.
</p>
<p class="" style="">Buddycloud channels build on XMPP's native federation and
asynchronous messaging to provide a decentralised sharing and
communication network. The Buddycloud ecosystem contains multiple
[XMPP] components (for example: location-butler, media-server and
channel-directory) that work together and enable developers to build
new communication products.
</p>
<h2>2.
<a name="reqs" id="reqs">Requirements</a></h2>
<h2>3.
<a name="glossary" id="glossary">Glossary</a></h2>
<div class="indent"><dl>
<di>
<dt><strong>Channel</strong></dt>
<dd>A
collection of content-specific <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0060.html">Publish-Subscribe</a></span> [<a href="#nt-idm167522574944">1</a>]
Nodes (posts, geoloc, public-key)
</dd>
</di>
<di>
<dt><strong>Channel Server</strong></dt>
<dd>An XMPP component which hosts channel nodes and provides an
interface conforming to this document to allow access to them via
XMPP.
</dd>
</di>
<di>
<dt><strong>Home Server</strong></dt>
<dd>The channel server which hosts a user's personal channel nodes
and contains their Inbox. The home server operates on behalf of
users (for example subscribing to a whitelisted channel))
</dd>
</di>
<di>
<dt><strong>Follower</strong></dt>
<dd>A Channel subscriber</dd>
</di>
<di>
<dt><strong>Moderator</strong></dt>
<dd>A channel follower with capabilities to also approve followers
to topic channels and retract posts
</dd>
</di>
<di>
<dt><strong>Producer</strong></dt>
<dd>the owner of a channel with the ability to add and remove
moderators
</dd>
</di>
<di>
<dt><strong>Inbox</strong></dt>
<dd> Service on the Entity's Home Server which subscribes to nodes
on the Entity's behalf, and may cache node data and provide an
ability to replay recent messages.
</dd>
</di>
<di>
<dt><strong>Personal Channel</strong></dt>
<dd> A Channel about an Entity and named after their jid (e.g.
film-girl@example.com)
</dd>
</di>
<di>
<dt><strong>Topic Channel</strong></dt>
<dd> A Channel based on an arbitrary topic and carrying slightly
different business logic (e.g. film-lovers@example.org)
</dd>
</di>
</dl></div>
<h2>4.
<a name="preliminaries" id="preliminaries">Preliminaries</a></h2>
<div class="indent"><h3>4.1 <a name="preliminaries-businesslogic" id="preliminaries-businesslogic">Business Logic</a></h3>
<p class="" style="">By prescribing sensible behavior that a server can enforce we
avoid support issues on clients. "I've lost publishing rights to my
own channel" or "I can't view a friends channel even though I am a
moderator in that channel". Pub-sub is a great backend. A good user
service built on it will prescribe sensible business logic that fits
with a users mental model of what channels provide. We do that by
adding a bit of business logic to the Buddycloud server:
</p>
<ul class="" style="">
<li class="" style="">
Personal Channel Nodes are always owned by their JID. The server
MUST NOT allow the ownership to be altered. For example:
<span class="em">user@example.org</span>
owns
<span class="em">channel.example.org</span>
, node
<span class="em">/user/user@example.org/posts</span>
</li>
<li class="" style="">
The Buddycloud server must maintain similar affiliations across
<span class="em">.../posts</span>
,
<span class="em">.../geo/current</span>
,
<span class="em">.../geo/previous</span>
,
<span class="em">.../geo/future</span>
and
<span class="em">.../mood</span>
ie, if you follow a user, you also get to see their status.
</li>
<li class="" style="">Only owners, moderators and producers should be able to see
channel outcasts (don't glorify bad behavior)
</li>
</ul>
</div>
<div class="indent"><h3>4.2 <a name="sect-idm167522553520" id="sect-idm167522553520">The Buddycloud Inbox</a></h3>
<p class="" style="">The inbox is an auxiliary service that can be discovered similar
to the content-hosting service by pubsub/inbox. It takes care of
receiving all notifications and synchronization while providing a
one-shot MAM protocol for replaying them to clients. Therefore,
users need only one presence authorization to that inbox.
</p>
<div class="indent"><h3>4.2.1 <a name="sect-idm167522551632" id="sect-idm167522551632">Inbox Discovery</a></h3>
<p class="" style="">Inbox components MUST advertise their type in order to be used by
users.
</p>
<p class="caption"><a name="example-1" id="example-1"></a>Example 1. </p><div class="indent"><pre class="prettyprint">
<identity category="pubsub" type="inbox"/>
</pre></div>
</div>
<div class="indent"><h3>4.2.2 <a name="sect-idm167522549056" id="sect-idm167522549056">Inbox Authorization</a></h3>
<p class="" style="">Any stanza except subscribe/unsubscribe do not convey identity of
the end-user.
</p>
<p class="" style="">The remote server must check authority of the inbox/home server
for the domain/user. The remote server must also has to check that
at least one user of the inbox has permission to access the node.
</p>
<p class="" style="">The inbox/home server must synchronize subscriptions/affiliations
to decide permissioning for its local users.
</p>
</div>
<div class="indent"><h3>4.2.3 <a name="sect-idm167522545376" id="sect-idm167522545376">Partition Detection</a></h3>
<p class="" style="">Channel services MUST also advertize all supported XMPP
extensions in Service Discovery feature elements.
</p>
<p class="" style="">Network partition detection has been designed for the
notification-sending side. A service does not need to track
delivery status of each message, but keeps track of remote services
that were unreachable.
</p>
<p class="" style="">When an inbox comes online after downtime, it has to retrieve all
metadata and posts from user-subscribed nodes.
</p>
<p class="" style="">In case of a network partition, it is the notification sender
that detects unavailability of an inbox. It keeps track of the
services that were offline, and periodically sends.
</p>
<p class="caption"><a name="example-2" id="example-2"></a>Example 2. </p><div class="indent"><pre class="prettyprint">
<iq type="set" from="buddycloud.example.com" to="buddycloud.example.org">
<you-missed-something xmlns="http://buddycloud.org/v1"/>
</iq>
</pre></div>
</div>
</div>
<div class="indent"><h3>4.3 <a name="preliminaries-channelnodes" id="preliminaries-channelnodes">Channel Nodes</a></h3>
<p class="" style="">A Channel consists of a number of PubSub Nodes with well-known ids
</p>
<div class="indent"><h3>4.3.1 <a name="preliminaries-channelnodes-ids" id="preliminaries-channelnodes-ids">Channel NodeIDs</a></h3>
<p class="" style="">
Node IDs are constructed as
<span class="strong">"/user/<JID>/<node type>"</span>
</p>
<div class="indent"><dl>
<di>
<dt><strong>JID</strong></dt>
<dd>This is the Bare JID of the channel, in the form
'channel@domain.tld'
</dd>
</di>
<di>
<dt><strong>Node Type</strong></dt>
<dd>
See
<a href="#preliminaries-channelnodes-types">Node Types</a>
</dd>
</di>
</dl></div>
</div>
<div class="indent"><h3>4.3.2 <a name="preliminaries-channelnodes-types" id="preliminaries-channelnodes-types">Node Types</a></h3>
<p class="" style="">A channel is split into various nodes, each of which contains a
different set of data relating to the channel. The following table
describes the currently defined node types.
</p>
<div class="indent"><p class="caption"><a name="table-1" id="table-1"></a>Table 1: Node Types</p><table border="1" cellpadding="3" cellspacing="0">
<tr class="body">
<th colspan="" rowspan="2">Node Type</th>
<th colspan="2" rowspan="">Required</th>
<th colspan="" rowspan="2">Description</th>
</tr>
<tr class="body">
<th colspan="" rowspan="">Personal Channels</th>
<th colspan="" rowspan="">Topic Channels</th>
</tr>
<tr class="body">
<td colspan="" rowspan="">posts</td>
<td colspan="" rowspan="">Yes</td>
<td colspan="" rowspan="">Yes</td>
<td colspan="" rowspan="">The main node for the channel, containing the primary activity
stream</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">geo/current</td>
<td colspan="" rowspan="">Yes</td>
<td colspan="" rowspan="">No</td>
<td colspan="" rowspan="">A XEP-0255 compliant feed of the User's current location</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">geo/previous</td>
<td colspan="" rowspan="">Yes</td>
<td colspan="" rowspan="">No</td>
<td colspan="" rowspan="">A XEP-0255 compliant feed of the User's previous location</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">geo/future</td>
<td colspan="" rowspan="">Yes</td>
<td colspan="" rowspan="">No</td>
<td colspan="" rowspan="">A XEP-0255 compliant feed of the User's future location</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">subscriptions</td>
<td colspan="" rowspan="">Yes</td>
<td colspan="" rowspan="">No</td>
<td colspan="" rowspan="">A list of the user's public subscriptions</td>
</tr>
</table></div>
</div>
</div>
<div class="indent"><h3>4.4 <a name="preliminaries-channelmetadata" id="preliminaries-channelmetadata">Channel Metadata</a></h3>
<p class="" style="">Channel metadata is stored as node metadata against the /posts
node of the channel.
</p>
<p class="" style="">Most
metadata fields used for Channels are already defined in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0060.html">Publish-Subscribe</a></span> [<a href="#nt-idm167522576960">2</a>].
The relevant ones are listed below.
</p>
<div class="indent"><p class="caption"><a name="table-2" id="table-2"></a>Table 2: Channel Metadata Fields</p><table border="1" cellpadding="3" cellspacing="0">
<tr class="body">
<th colspan="" rowspan="">Metadata</th>
<th colspan="" rowspan="">Field</th>
<th colspan="" rowspan="">Example</th>
<th colspan="" rowspan="">Notes</th>
<th colspan="" rowspan="">Defaults</th>
</tr>
<tr class="body">
<td colspan="" rowspan="">Channel Title</td>
<td colspan="" rowspan="">pubsub#title</td>
<td colspan="" rowspan="">"Juliet's musings"</td>
<td colspan="" rowspan="">Should be a brief single sentence</td>
<td colspan="" rowspan="">"user@example.org's Buddycloud channel"</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Channel Description</td>
<td colspan="" rowspan="">pubsub#description</td>
<td colspan="" rowspan="">"This is a channel about the things that I like to do."</td>
<td colspan="" rowspan="">A longer description of the channel</td>
<td colspan="" rowspan=""><empty></td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Channel Access Model</td>
<td colspan="" rowspan="">pubsub#access_model</td>
<td colspan="" rowspan="">"whitelist"</td>
<td colspan="" rowspan="">The channel subscriber model</td>
<td colspan="" rowspan="">Dependent on Node</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Default Affiliation</td>
<td colspan="" rowspan="">Buddycloud#default_affiliation</td>
<td colspan="" rowspan="">"publisher"</td>
<td colspan="" rowspan="">The role given to new channel followers</td>
<td colspan="" rowspan="">Dependent on Channel Type</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Channel Type</td>
<td colspan="" rowspan="">Buddycloud#channel_type</td>
<td colspan="" rowspan="">"personal"</td>
<td colspan="" rowspan="">The type of this channel</td>
<td colspan="" rowspan="">N/A</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Channel Creation Date</td>
<td colspan="" rowspan="">pubsub#creation_date</td>
<td colspan="" rowspan="">"2011-01-31T23:59:42"</td>
<td colspan="" rowspan="">When the channel was created in ISO 8601 time format</td>
<td colspan="" rowspan=""></td>
</tr>
</table></div>
<div class="indent"><h3>4.4.1 <a name="preliminaries-channelmetadata-accessmodel" id="preliminaries-channelmetadata-accessmodel">Channel Access Model</a></h3>
<div class="indent"><p class="caption"><a name="table-3" id="table-3"></a>Table 3: Channel Access Models</p><table border="1" cellpadding="3" cellspacing="0">
<tr class="body">
<th colspan="" rowspan="">Access Model</th>
<th colspan="" rowspan="">Description</th>
</tr>
<tr class="body">
<td colspan="" rowspan="">"authorise"</td>
<td colspan="" rowspan="">The channel is only viewable by it's producer, followers,
followers+post and moderators.</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">"open"</td>
<td colspan="" rowspan="">Anyone can view the channel.</td>
</tr>
</table></div>
</div>
<div class="indent"><h3>4.4.2 <a name="preliminaries-channelmetadata-affiliations" id="preliminaries-channelmetadata-affiliations">Channel Affiliations</a></h3>
<p class="" style="">Buddycloud
channel affiliations are mapped onto <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0060.html">Publish-Subscribe</a></span> [<a href="#nt-idm167522502000">3</a>]
node affiliations.
</p>
<div class="indent"><p class="caption"><a name="table-4" id="table-4"></a>Table 4: Channel Affiliations</p><table border="1" cellpadding="3" cellspacing="0">
<tr class="body">
<th colspan="" rowspan="">XEP-0060 Affiliation</th>
<th colspan="" rowspan="">Buddycloud Affiliation</th>
<th colspan="" rowspan="">Description</th>
<th colspan="" rowspan="">Required?</th>
</tr>
<tr class="body">
<td colspan="" rowspan="">Owner</td>
<td colspan="" rowspan="">owner</td>
<td colspan="" rowspan="">The channel owner. Full access rights</td>
<td colspan="" rowspan="">REQUIRED</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">-</td>
<td colspan="" rowspan="">moderator</td>
<td colspan="" rowspan="">An entity which has follower+post rights, rights to manage the
affiliation of entites with the node (except changing ownership),
and rights to manage the subscriptions of entities with the node</td>
<td colspan="" rowspan="">REQUIRED</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Publisher</td>
<td colspan="" rowspan="">follower+post</td>
<td colspan="" rowspan="">Entity can view posts and replies, publish new posts, and
publish replies to posts.</td>
<td colspan="" rowspan="">REQUIRED</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Member</td>
<td colspan="" rowspan="">follower</td>
<td colspan="" rowspan="">Entity can view posts and replies for whitelist and open
channels, but cannot publish new posts or replies.</td>
<td colspan="" rowspan="">REQUIRED</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">None</td>
<td colspan="" rowspan="">none</td>
<td colspan="" rowspan="">Entity can view posts and replies for open channels, but
cannot publish new posts or replies.</td>
<td colspan="" rowspan="">REQUIRED</td>
</tr>
<tr class="body">
<td colspan="" rowspan="">Outcast</td>
<td colspan="" rowspan="">outcast</td>
<td colspan="" rowspan="">Entity cannot view any posts or replies, and cannot publish
new posts or replies.</td>
<td colspan="" rowspan="">RECOMMENDED</td>
</tr>
</table></div>
<div class="indent"><h3>4.4.2.1 <a name="preliminaries-channelmetadata-affiliations-default" id="preliminaries-channelmetadata-affiliations-default">Default Affiliations</a></h3>
</div>
</div>
</div>
<h2>5.
<a name="entityusecases" id="entityusecases">Entity Use Cases</a></h2>
<div class="indent"><h3>5.1 <a name="entityusecases-servicediscovery" id="entityusecases-servicediscovery">Service Discovery</a></h3>
<p class="" style="">Service discovery happens per domain, and is a multi step process.
</p>
<p class="" style="">To discover the channels component for a domain, the entity first
sends an items discovery request to the domain to discover all the
available components
</p>
<p class="caption"><a name="example-3" id="example-3"></a>Example 3. The Entity sends a disco#items request to the domain</p><div class="indent"><pre class="prettyprint">
<iq type='get'
from='user@example.org/client'
to='example.org'
id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
</pre></div>
<p class="" style="">The server replies with the list of available components, along
with their associated JIDs.
</p>
<p class="caption"><a name="example-4" id="example-4"></a>Example 4. The server replies with a list of available components.</p><div class="indent"><pre class="prettyprint">
<iq type='result' from='example.org' to='user@example.org/BuddycloudApp'
id='items1'>
<query xmlns='http://jabber.org/protocol/disco#items'>
<item jid='muc.example.org' name='Chatrooms' />
<item jid='buddycloud.example.com' name='Buddycloud Server' />
</query>
</iq>
</pre></div>
<p class="" style="">The entity then iterates through the <item/> elements,
sending an info discovery request to each jid.
</p>
<p class="caption"><a name="example-5" id="example-5"></a>Example 5. The Entity sends a disco#info request to each component</p><div class="indent"><pre class="prettyprint">
<iq type='get'
from='user@example.org/BuddycloudApp'
to='channels.example.org'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
</pre></div>
<p class="" style="">Each component replies with its identity. The channels component
has an identity of category 'pubsub' and type 'channels'.
</p>
<p class="" style="">
A domain MUST only host one component with an identity of category
'pubsub' and type 'channels'.
</p>
<p class="caption"><a name="example-6" id="example-6"></a>Example 6. The Buddycloud component replies with its identity</p><div class="indent"><pre class="prettyprint">
<iq type='result' from='buddycloud.example.org' to='user@example.org/BuddycloudApp'
id='info2'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity category='pubsub' type='channels' />
<identity category='pubsub' type='inbox' />
<feature var='jabber:iq:register' />
<feature var='http://jabber.org/protocol/disco#info' />
</query>
</iq>
</pre></div>
</div>
<div class="indent"><h3>5.2 <a name="entityusecases-verifyserver" id="entityusecases-verifyserver">Verify the Authority of a Server for a JID</a></h3>
<p class="" style="">It is necessary to verify that a given Channel Server is a
channel's home server for a given JID. For example, an Entity may
wish to verify that the JID 'buddycloud.example.org' is the
authoritative Home Server for the JID 'user@example.org'.
</p>
<p class="" style="">
The Channel Server SHOULD do this by discovering the Channel Server
for the JID using
<a href="#entityusecases-servicediscovery">Channel Server Discovery</a>
, but an implementation MAY choose to ascertain this mapping by
other means. This mapping SHOULD be cached for later use.
</p>
<p class="" style="">
The Channel Server MUST then apply the Nameprep profile to the
domains (as defined in
<a href="http://tools.ietf.org/html/rfc5891">IDNA</a>
) before comparing the domain portions of the two JIDs
</p>
</div>
<div class="indent"><h3>5.3 <a name="entityusecases-register" id="entityusecases-register">Register with the Service</a></h3>
<p class="" style="">If the jid doesn't already have a Personal Channel on the service,
one can be created. The Buddycloud server will then also setup the
associated geoloc and mood nodes and ensure that the nodes have the
correct default permissions.
</p>
<p class="caption"><a name="example-7" id="example-7"></a>Example 7. The Service Advertises the Registration Feature</p><div class="indent"><pre class="prettyprint">
<feature var='jabber:iq:register'/>
</pre></div>
<p class="caption"><a name="example-8" id="example-8"></a>Example 8. An Entity Registers with the Service</p><div class="indent"><pre class="prettyprint">
<iq from="user@example.org/BuddycloudApp" to="buddycloudserver.example.org" type="set">
<query xmlns="jabber:iq:register"/>
</iq>
</pre></div>
</div>
<h2>6.
<a name="publisherusecases" id="publisherusecases">Publisher Use Cases</a></h2>
<div class="indent"><h3>6.1 <a name="publisherusecases-post" id="publisherusecases-post">Post to a Channel</a></h3>
<p class="" style="">Posting to a channel implies a role of "follower+post, moderator
or producer"
</p>
<p class="caption"><a name="example-9" id="example-9"></a>Example 9. A Publisher Posts to a Channel</p><div class="indent"><pre class="prettyprint">
<iq from="user@example.com/BuddycloudApp" to="buddycloud.example.com"
type="set" id="publish:20">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="/user/user@example.org/posts">
<item>
<entry xmlns="http://www.w3.org/2005/Atom">
<published>2010-01-06T21:41:32Z</published>
<content type="text">Wherefore art thou?</content>
<geoloc xmlns="http://jabber.org/protocol/geoloc">
<text>Verona, Italy</text>
<locality>Verona</locality>
<country>Italy</country>
</geoloc>
</entry>
</item>
</publish>
</pubsub>
</iq>
</pre></div>
<p class="" style="">The Local Server relays the <publish/> request to the Remote
Server, along with <actor/> information.</p>
<p class="caption"><a name="example-10" id="example-10"></a>Example 10. The Local Server relays the request to the Remote Server</p><div class="indent"><pre class="prettyprint">
<iq from="buddycloud.example.com" to="buddycloud.example.org" type="set" id="publish:21">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="/user/user@example.org/posts">
<item>
<entry xmlns="http://www.w3.org/2005/Atom">
<published>2010-01-06T21:41:32Z</published>
<content type="text">Wherefore art thou?</content>
<geoloc xmlns="http://jabber.org/protocol/geoloc">
<text>Verona, Italy</text>
<locality>Verona</locality>
<country>Italy</country>
</geoloc>
</entry>
</item>
</publish>
<actor xmlns='http://buddycloud.org/v1'>user@example.com</actor>
</pubsub>
</iq>
</pre></div>
<p class="" style="">The Remote Server then checks that:</p>
<ul class="" style="">
<li class="" style="">The
'from' JID is authoritative for the <actor/>
</li>
<li class="" style="">The <actor/> is authorised to post to the Node</li>
</ul>
<p class="" style="">The server then stores the Post against the Node, and responds.
</p>
<p class="caption"><a name="example-11" id="example-11"></a>Example 11. The Remote Server responds to the Post request</p><div class="indent"><pre class="prettyprint">
<iq from="buddycloud.example.org" to="buddycloud.example.com" type="result"
id="publish:21">
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='/user/user@example.com/posts'>
<item id='123-456-789' />
</publish>
</pubsub>
</iq>
</pre></div>
<p class="caption"><a name="example-12" id="example-12"></a>Example 12. The Local Server relays the Response back to the Client</p><div class="indent"><pre class="prettyprint">
<iq from="buddycloud.example.com" to="user@example.com/BuddycloudApp"
type="result" id="publish:20">
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='/user/user@example.org/posts'>
<item id='123-456-789' />
</publish>
</pubsub>
</iq>
</pre></div>
<div class="indent"><h3>6.1.1 <a name="publisherusecases-post-normalization" id="publisherusecases-post-normalization">Content normalization</a></h3>
<p class="" style="">When posting to a Channel the Server MUST apply the following
rules to the ATOM payload:
</p>
<ul class="" style="">
<li class="" style="">The entry/author/uri MUST be set to the acct: account of the
entity that is actually posting to the channel. This should be the
bare jid.
</li>
<li class="" style="">Upon a new entry the entry/published timestamp MUST be set to
the current server time (often more accurate than client clock)
</li>
<li class="" style="">Upon overwriting an existing entry, the entry/published SHOULD
be copied from the old version and entry/updated SHOULD be set to
the current server time
</li>
<li class="" style="">The entry/id element SHOULD be updated to reflect the PubSub
content model
</li>
<li class="" style="">Any conversation thread information MAY be checked for existing
references, and possibly deny posting with missing context
</li>
<li class="" style="">The entry/content MAY be used for spam filtering, especially
for posts from non-channel-owners
</li>
<li class="" style="">Missing Activity Streams constructs may be replaced by verb
post or comment (depending on presence of thr:in-reply-to)
</li>
</ul>
<p class="" style="">Note: Add something about post size restrictions</p>
<p class="" style="">Note: in a decentralized system not only content-hosting servers
may validate content.
</p>
</div>
</div>
<div class="indent"><h3>6.2 <a name="publisherusecases-replytopost" id="publisherusecases-replytopost">Reply to a Post</a></h3>
<p class="" style="">Replying to a Post is similar to creating a new Post with the
following exceptions:
</p>
<ul class="" style="">
<li class="" style="">The <activity:object-type/> MUST be comment</li>
<li class="" style="">The <entry/> element MUST contain an <in-reply-to/>
element, qualified by the 'http://purl.org/syndication/thread/1.0'
namespace containing the ItemID of the primary Post
</li>
</ul>
<p class="caption"><a name="example-13" id="example-13"></a>Example 13. A Publisher Replies to a Post</p><div class="indent"><pre class="prettyprint">
<iq from="user@example.org/mobile" to="buddycloud.example.org"
type="set" id="publish:22">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<publish node="/user/user@example.org/posts">
<item>
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0">
<published>2010-01-06T21:41:32Z</published>
<author>
<name>user@example.org</name>
<jid xmlns="http://buddycloud.com/atom-elements-0">user@example.org</jid>
</author>
<content type="text">Test</content>
<geoloc xmlns="http://jabber.org/protocol/geoloc">
<text>Verona, Italy</text>
<locality>Verona</locality>
<country>Italy</country>
</geoloc>
<thr:in-reply-to ref='123-456-789' />
</entry>
</item>
</publish>
</pubsub>
</iq>
</pre></div>
<div class="indent"><h3>6.2.1 <a name="publisherusecases-replytopost-errors" id="publisherusecases-replytopost-errors">Error Conditions</a></h3>
<div class="indent"><h3>6.2.1.1 <a name="publisherusecases-replytopost-errors-replytoreply" id="publisherusecases-replytopost-errors-replytoreply">The client attempts to post a Reply to a Reply</a></h3>
<p class="" style="">Buddycloud
allows a single level of replies to posts, so if a request is
received to post a reply to a reply then the server MUST respond
with a <bad-request/>
error, which SHOULD include a pub-sub specific
<invalid-payload/> error.
</p>
<p class="caption"><a name="example-14" id="example-14"></a>Example 14. The server rejects a reply to a reply</p><div class="indent"><pre class="prettyprint">
<iq type='error' from='buddycloud.example.org' to='user@example.org/BuddycloudApp'
id='publish1'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' />
<invalid-payload xmlns='http://jabber.org/protocol/pubsub#errors' />
</error>
</iq>
</pre></div>
</div>
</div>
</div>
<div class="indent"><h3>6.3 <a name="publisherusecases-deletepost" id="publisherusecases-deletepost">Delete a Post</a></h3>
<p class="" style="">The client sends a <retract/> request to the Local Inbox
</p>
<p class="caption"><a name="example-15" id="example-15"></a>Example 15. The Client sends a Delete Post request to their Local Server</p><div class="indent"><pre class="prettyprint">
<iq from="user@example.com/mobile" to="buddycloud.example.com"
type="set" id="retractitem:32">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<retract node="/user/user@example.org/posts" notify="1">
<item id="123-456-790" />
</retract>
</pubsub>
</iq>
</pre></div>
<p class="" style="">The
Local Server relays the request to the Remote Server, attaching <actor/>
information.
</p>
<p class="caption"><a name="example-16" id="example-16"></a>Example 16. The Client sends a Delete Post request to their Local Server</p><div class="indent"><pre class="prettyprint">
<iq from="user@example.com/mobile" to="buddycloud.example.com"
type="set" id="retractitem:32">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<retract node="/user/user@example.org/posts" notify="1">
<item id="123-456-790" />
</retract>
</pubsub>
</iq>
</pre></div>
<p class="" style="">Server replies</p>
<p class="caption"><a name="example-17" id="example-17"></a>Example 17. The Server replies to a Delete Post request</p><div class="indent"><pre class="prettyprint">
<iq from="user@example.org/BuddycloudApp" to="buddycloudserver.example.org" type="result" id="retractitem:32"/>
</pre></div>
<p class="" style="">A retraction message is sent to all online clients, along with an
Atom tombstone to replace the deleted post
</p>
<p class="caption"><a name="example-18" id="example-18"></a>Example 18. The Server send a Retraction Notification to all Subscribers to the Channel</p><div class="indent"><pre class="prettyprint">
<message from="buddycloudserver.example.org" id="bc:MGV3B"
to="imranraza@example.org">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/user/user@example.org/posts">
<retract id="1291048772456" />
<item id="1291048772456">
<deleted-entry xmlns="http://purl.org/atompub/tombstones/1.0"
ref="xmpp:channels.example.org?pubsub;action=retrieve;node=/user/user@example.org/posts;item=1291048772456"
when="2012-07-01T15:08:32.950Z">
<updated>2012-07-01T15:08:32.950Z</updated>
<id xmlns="http://www.w3.org/2005/Atom">1291048772456</id>
<link xmlns="http://www.w3.org/2005/Atom"
href="xmpp:channels.example.org?pubsub;action=retrieve;node=/user/user@example.org/posts;item=1291048772456"
rel="self" />
<published xmlns="http://www.w3.org/2005/Atom">2012-07-01T15:08:30.922Z</published>
<object xmlns="http://activitystrea.ms/spec/1.0/">
<object-type>comment</object-type>
.
</object>
<verb xmlns="http://activitystrea.ms/spec/1.0/">post</verb>
.
</deleted-entry>
.
</item>
.
</items>
.
</event>
</message>
</pre></div>
</div>
<h2>7.
<a name="subscriberusecases" id="subscriberusecases">Subscriber Use Cases</a></h2>
<div class="indent"><h3>7.1 <a name="subscriberusecases-subscribe" id="subscriberusecases-subscribe">Subscribe to a Channel</a></h3>
<p class="" style="">Channel followers should send subscription requests to their Local
Inbox, even for remote channels.
</p>
<p class="caption"><a name="example-19" id="example-19"></a>Example 19. Client sends Subscription Request to their Local Inbox</p><div class="indent"><pre class="prettyprint">
<iq type="set" from="user@example.com/client" to="buddycloud.example.com"
id="sub1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="/users/user@example.org/posts" jid="user@example.com" />
</pubsub>
</iq>
</pre></div>
<p class="" style="">The Local Inbox then Subscribes to the Remote Nodes on the
Subscriber's behalf.
</p>
<p class="caption"><a name="example-20" id="example-20"></a>Example 20. The Local Inbox Subscribes to the Remote Server</p><div class="indent"><pre class="prettyprint">
<iq type="set" from="buddycloud.example.com" to="buddycloud.example.org"
id="sub2">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscribe node="/users/user@example.org/posts" jid="user@example.com" />
<actor xmlns="http://buddycloud.org/v1">user@example.com</actor>
</pubsub>
</iq>
</pre></div>
<p class="" style="">The remote service checks the actor for permission.</p>
<p class="" style="">
The
<span class="em">@jid</span>
attribute is purely decorative to comply with XEP-0060. It is not
the actual notification listener (in that case the inbox instead of
the user himself), but the user that wishes to subscribe. Use of the
<span class="em"><actor/></span>
element is more generic and applies to a variety of other requests
that require authorization.
</p>
<p class="" style="">Upon successful subscription/unsubscription, the inbox SHOULD keep
track if there's at least one subscription to the node with the
inbox itself as listener, allowing it to answer read queries from
only its cache.
</p>
<p class="" style="">Inbox then receives acknowledgement for subscription request, and
relays it to the client:
</p>
<p class="caption"><a name="example-21" id="example-21"></a>Example 21. The Remote Inbox acknowledges the Subscription Request</p><div class="indent"><pre class="prettyprint">
<iq type="result"
from="buddycloud.example.org"
to="buddycloud.example.org"
id="sub2">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscription node="/users/user@example.org/posts" jid="user@example.com" subscription="subscribed"/>
</pubsub>
</iq>
</pre></div>
<p class="caption"><a name="example-22" id="example-22"></a>Example 22. The Local Inbox replays the Subscription Request acknowledgement to the Client</p><div class="indent"><pre class="prettyprint">
<iq type="result"
from="buddycloud.example.org"
to="user@example.com/client"
id="sub1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<subscription node="/users/user@example.org/posts" jid="user@example.com" subscription="subscribed"/>
</pubsub>
</iq>
</pre></div>
<p class="" style="">Subscribed inboxes and clients are also notified:</p>
<p class="caption"><a name="example-23" id="example-23"></a>Example 23. The Remote Inbox notifies Channel Subscribers</p><div class="indent"><pre class="prettyprint">
<message from="buddycloud.example.org" to="user@example.com"
type="headline">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<subscription node="/users/user@example.org/posts"
jid="user@example.com" subscription="subscribed" />
</event>
</message>
</pre></div>
</div>
<div class="indent"><h3>7.2 <a name="subscriberusecases-retrieverecentposts" id="subscriberusecases-retrieverecentposts">Retrieve Recent Posts from all Subscribed Channels</a></h3>
<p class="" style="">
Clients that need to access recent posts in all the followed
channels may use the quick synchronization mechanism. This can only
be used by authenticated users.
.
</p>
<p class="" style="">Client sends:</p>
<p class="caption"><a name="example-24" id="example-24"></a>Example 24. An Entity requests Recent Posts</p><div class="indent"><pre class="prettyprint">
<iq from="user@example.org/BuddycloudApp" to="buddycloudserver.example.org" type="get" id="ri1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<recent-items xmlns="http://buddycloud.org/v1"
since="2012-12-04T23:36:51.123Z"
max="50"/>
</pubsub>
</iq>
</pre></div>
<p class="" style="">The servers responds with items from the subscribed channels:
</p>
<ul class="" style="">
<li class="" style="">items from the /posts nodes only</li>
<li class="" style="">updated after since, newest items first, required</li>
<li class="" style="">at most max per channel, required</li>
<li class="" style="">RSM must be used to page through results</li>
</ul>
</div>
<div class="indent"><h3>7.3 <a name="subscriberusecases-newpostnotification" id="subscriberusecases-newpostnotification">Receive a New Post Notification</a></h3>
<p class="" style="">Subscribed inboxes are always notified. Online clients
automatically receive new posts from the inbox
</p>
<p class="caption"><a name="example-25" id="example-25"></a>Example 25. New Post Notification</p><div class="indent"><pre class="prettyprint">
<message type="headline" id="bc:GfLwH" from="buddycloudserver.example.org"
to="31941515521289471453412508@anon.buddycloud.com/2906694851289471453813745">
<event xmlns="http://jabber.org/protocol/pubsub#event">
<items node="/user/user@example.org/posts">
<item id="1291048810046">
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0">
<author>
<name>Dirk</name>
<jid xmlns="http://buddycloud.com/atom-elements-0">fahrertuer@example.org</jid>
<affiliation xmlns="http://buddycloud.com/atom-elements-0">moderator</affiliation>
</author>
<content type="text">A comment, wondering what all this testing
does</content>
<published>2010-11-29T16:40:10Z</published>
<updated>2010-11-29T16:40:10Z</updated>
<id>/user/user@example.org/posts:1291048810046</id>
<geoloc xmlns="http://jabber.org/protocol/geoloc">
<text>Bremen, Germany</text>
<locality>Bremen</locality>
<country>Germany</country>
</geoloc>
<thr:in-reply-to ref="1291048772456" />
</entry>
</item>
</items>
</event>
</message>
</pre></div>
</div>
<div class="indent"><h3>7.4 <a name="subscriberusecases-allposts" id="subscriberusecases-allposts">Retrieve all Posts for a Node</a></h3>
<p class="" style="">Node items are ordered newest first. The Result Set Management
elements after and before are not related to timestamps but this
ordering!
</p>
<p class="" style="">Client sends:</p>
<p class="caption"><a name="example-26" id="example-26"></a>Example 26. Client requests all Posts</p><div class="indent"><pre class="prettyprint">
<iq type="get"
from="user@example.org/BuddycloudApp"
to="buddycloudserver.example.org"
id="items1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<items node="/user/kitteh@example.org/posts"/>
</pubsub>
</iq>
</pre></div>
<p class="" style="">Server responds:</p>
<p class="caption"><a name="example-27" id="example-27"></a>Example 27. The Server responds with all Posts</p><div class="indent"><pre class="prettyprint">
<iq type="result" from="buddycloudserver.example.org" to="user@example.org/BuddycloudApp"
id="items1">
<pubsub xmlns="http://jabber.org/protocol/pubsub">
<items node="/user/kitteh@example.org/posts">
<item id="1291048810046">
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0">
<author>
<name>Dirk</name>
<jid xmlns="http://buddycloud.com/atom-elements-0">fahrertuer@example.org</jid>
<affiliation xmlns="http://buddycloud.com/atom-elements-0">moderator</affiliation>
</author>
<content type="text">A comment, wondering what all this testing
does</content>
<published>2010-11-29T16:40:10Z</published>
<updated>2010-11-29T16:40:10Z</updated>
<id>/user/user@example.org/posts:1291048810046</id>
<geoloc xmlns="http://jabber.org/protocol/geoloc">
<text>Bremen, Germany</text>
<locality>Bremen</locality>
<country>Germany</country>
</geoloc>
<thr:in-reply-to ref="1291048772456" />
</entry>
</item>
<!-- [more items...] -->
<item id="1131048810046">
<entry xmlns="http://www.w3.org/2005/Atom" xmlns:thr="http://purl.org/syndication/thread/1.0">
<author>
<name>Kittycat</name>
<jid xmlns="http://buddycloud.com/atom-elements-0">kitteh@example.org</jid>
<affiliation xmlns="http://buddycloud.com/atom-elements-0">owner</affiliation>
</author>
<content type="text">I"m in ur channel, meowing federatedly
</content>
<published>2009-08-12T16:40:10Z</published>
<id>/user/user@example.org/posts:1131048810046</id>
<geoloc xmlns="http://jabber.org/protocol/geoloc">
<text>Home basket</text>
<locality>Munich</locality>
<country>Germany</country>
</geoloc>
</entry>
</item>
</items>
<set xmlns="http://jabber.org/protocol/rsm">
<first>1291048810046</first>
<last>1131048810046</last>
<count>19827</count>
</set>
</pubsub>
</iq>
</pre></div>
<p class="" style="">Client can then request older items for pagination or filling its