distbin.com 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232
  1. # distbin.com activitypub implementation report
  2. Distbin is a distributed pastebin. Anyone can anonymously create little text posts, and anyone else can reply to them.
  3. You can even create posts that are inReplyTo parent posts that are hosted elsewhere on the web (like another distbin.com installation), and distbin will tell the parent about it via ActivityPub.
  4. distbin is made up of at least two components:
  5. * core - Speaks only JSON/ActivityPub
  6. * distbin-html
  7. * Renders a homepage with a form that helps an end-user build Create Note activites
  8. * Renders created activities to HTML
  9. * Renders the public collection to HTML
  10. Implementation Home Page URL: https://distbin.com
  11. Implementation Classes (Sender and/or Receiver):
  12. * [x] Client
  13. * [x] Server
  14. * [x] Federated Server (all of the above)
  15. Developer(s): [Benjamin Goering](http://bengo.is)
  16. Interface to other applications: network service
  17. Publicly Accessible: [x]
  18. Source Code repo URL(s): n/a
  19. * [ ] 100% open source implementation
  20. License:
  21. Programming Language(s): JavaScript
  22. ## Client
  23. distbin is a client infsofar as it is a Federated Server and sends requests to other ActivityPub servers.
  24. ### Features
  25. #### Outbox Submission
  26. > A client receiving authorization and subsequently submitting an activity to the authenticated actor's outbox.
  27. According to [Section 7](https://w3c.github.io/activitypub/#client-to-server-interactions)...
  28. MUST
  29. * [ ] Client discovers the URL of a user's outbox from their profile
  30. * [x] Client submits activity by sending an HTTP post request to the outbox URL with the Content-Type of application/ld+json; profile="https://www.w3.org/ns/activitystreams#"
  31. * [x] Client submission request body is either a single Activity or a single non-Activity Object
  32. * [ ] Clients provide the object property when submitting the following activity types to an outbox: Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo.
  33. * [ ] Clients provide the target property when submitting the following activity types to an outbox: Add, Remove.
  34. * [ ] Client submission request is authenticated with the credentials of the user to whom the outbox belongs
  35. * [ ] Client supports [uploading media](https://www.w3.org/TR/activitypub/#uploading-media) by sending a multipart/form-data request body
  36. SHOULD
  37. * [ ] Before submitting a new activity or object, Client infers appropriate target audience by recursively looking at certain properties (e.g. `inReplyTo`, See Section 7), and adds these targets to the new submission's audience.
  38. * [ ] Client limits depth of this recursion.
  39. #### Retrieving Objects
  40. MUST
  41. * [x] When retrieving objects, Client specifies an Accept header with the `application/ld+json; profile="https://www.w3.org/ns/activitystreams#"` media type ([3.2](https://w3c.github.io/activitypub/#retrieving-objects))
  42. ## Server
  43. ### Features
  44. A Server:
  45. * Accepts activity submissions in an outbox, and updates the server's Objects per rules described below
  46. * Delivers these submissions to the inboxes of other Servers
  47. * Receives Activity from other servers in an inbox, and updates the server's Objects per rules described below
  48. * Makes Objects available for retrieval by Clients
  49. #### Accept activity submissions and produce correct side effects
  50. > A server handling an activity submitted by an authenticated actor to their outbox and handling client to server interaction side effects appropriately.
  51. When a Client submits Activities to a Server's outbox, the Server...
  52. MUST
  53. * [x] Accepts Activity Objects
  54. * [x] Accepts non-Activity Objects, and converts to Create Activities per 7.1.1
  55. * [ ] Removes the `bto` and `bcc` properties from Objects before storage and delivery
  56. * [x] Ignores 'id' on submitted objects, and generates a new id instead
  57. * [x] Responds with status code 201 Created
  58. * [x] Response includes Location header whose value is id of new object, unless the Activity is transient
  59. * [ ] Accepts Uploaded Media in submissions
  60. * accepts uploadedMedia file parameter
  61. * accepts uploadedMedia object parameter
  62. * Responds with status code of 201 Created or 202 Accepted as described in 6.
  63. * Response contains a Location header pointing to the to-be-created object's id.
  64. * Appends an id property to the new object
  65. * Update
  66. * [ ] Server takes care to be sure that the Update is authorized to modify its object before modifying the server's stored copy
  67. SHOULD
  68. * [x] Server does not trust client submitted content
  69. * [ ] Validate the content they receive to avoid content spoofing attacks.
  70. * [ ] After receiving submission with uploaded media, the server should include the upload's new URL in the submitted object's url property
  71. * [ ] Take care not to overload other servers with delivery submissions
  72. * Create
  73. * [ ] merges audience properties (to, bto, cc, bcc, audience) with the Create object's audience properties
  74. * [ ] Create's actor property is copied to be the value of .object.attributedTo
  75. * Follow
  76. * [ ] Adds followed object to the actor's Following Collection
  77. * Add
  78. * [ ] Adds object to the target Collection, unless not allowed due to requirements in 7.5
  79. * Remove
  80. * [ ] Remove object from the target Collection, unless not allowed due to requirements in 7.5
  81. * Like
  82. * [ ] Adds the object to the actor's Likes Collection.
  83. * Block
  84. * Prevent the blocked object from interacting with any object posted by the actor.
  85. #### Deliver to inboxes
  86. > A federated server delivering an activity posted by a local actor to the inbox endpoints of all recipients specified in the activity, including those on other remote federated servers.
  87. After receiving submitted Activities in an Outbox, a Server...
  88. MUST
  89. * [x] Performs delivery on all Activities posted to the outbox
  90. * [x] Utilizes `to`, `bto`, `cc`, and `bcc` to determine delivery recipients.
  91. * [x] Provides an `id` all Activities sent to other servers, unless the activity is intentionally transient.
  92. * [ ] Dereferences delivery targets with the submitting user's credentials
  93. * [ ] Delivers to all items in recipients that are Collections or OrderedCollections
  94. * [ ] Applies the above, recursively if the Collection contains Collections, and limits recursion depth >= 1
  95. * [ ] Delivers activity with 'object' property if the Activity type is one of Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo
  96. * [ ] Delivers activity with 'target' property if the Activity type is one of Add, Remove
  97. * [x] Deduplicates final recipient list
  98. * [ ] Does not deliver to recipients which are the same as the actor of the Activity being notified about
  99. SHOULD
  100. * [ ] NOT deliver Block Activities to their object.
  101. #### Accept inbox notifications from other servers
  102. > A federated server receiving an activity to its actor's inbox, validating that the activity and any nested objects were created by their respective actors, and handling server to server side effects appropriately.
  103. When receiving notifications in an inbox, a Server...
  104. MUST
  105. * [x] Deduplicates activities returned by the inbox by comparing activity `id`s
  106. * [] Forwards incoming activities to the values of to, bto, cc, bcc, audience if and only if criteria in 8.1.2 are met.
  107. * Update
  108. * [ ] Take care to be sure that the Update is authorized to modify its object
  109. SHOULD
  110. * [ ] Don't trust content received from a server other than the content's origin without some form of verification.
  111. * [ ] Recurse through to, bto, cc, bcc, audience object values to determine whether/where to forward according to criteria in 8.1.2
  112. * [ ] Limit recursion in this process
  113. * Update
  114. * [ ] Completely replace its copy of the activity with the newly received value
  115. * Follow
  116. * [ ] Add the actor to the object user's Followers Collection.
  117. * Add
  118. * [ ] Add the object to the Collection specified in the target property, unless not allowed to per requirements in 8.6
  119. * Remove
  120. * [ ] Remove the object from the Collection specified in the target property, unless not allowed per requirements in 8.6
  121. * Like
  122. * [ ] Perform appropriate indication of the like being performed (See 8.8 for examples)
  123. * [ ] Validate the content they receive to avoid content spoofing attacks.
  124. ##### Inbox Retrieval
  125. non-normative
  126. * [x] Server responds to GET request at inbox URL
  127. MUST
  128. * [x] inbox is an OrderedCollection
  129. SHOULD
  130. * [ ] Server filters inbox content according to the requester's permission
  131. #### Allow Object Retrieval
  132. According to [section 3.2](https://w3c.github.io/activitypub/#retrieving-objects), the Server...
  133. MAY
  134. * [x] Allow dereferencing Object `id`s by responding to HTTP GET requests with a representation of the Object
  135. If the above, is true, the Server...
  136. MUST
  137. * [x] Respond with the ActivityStreams object representation in response to requests that primarily Accept the media type `application/ld+json; profile="https://www.w3.org/ns/activitystreams#"`
  138. SHOULD
  139. * [x] - Respond with the ActivityStreams object representation in response to requests that primarily Accept the media type `application/activity+json`
  140. * Deleted Object retrieval
  141. * [ ] Respond with 410 Gone status code to requests for deleted objects
  142. * [ ] Respond with response body that is an ActivityStreams Object of type `Tombstone`.
  143. * [ ] Respond with 404 status code for Object URIs that have never existed
  144. * [ ] Respond with a 403 Forbidden status code to all requests that access Objects considered Private
  145. * [ ] Respond to requests which do not pass authorization checks using "the appropriate HTTP error code"
  146. * [ ] Respond with a 403 Forbidden error code to all requests to Object URIs where the existence of the object is considered private.
  147. ## Security Considerations
  148. non-normative
  149. * [ ] Server verifies that the new content is really posted by the author indicated in Objects received in inbox and outbox ([B.1](https://w3c.github.io/activitypub/#security-verification))
  150. * [ ] By default, implementation does not make HTTP requests to localhost when delivering Activities ([B.2](https://w3c.github.io/activitypub/#security-localhost))
  151. * [ ] Implementation applies a whitelist of allowed URI protocols before issuing requests, e.g. for inbox delivery ([B.3](https://w3c.github.io/activitypub/#security-uri-schemes))
  152. * [ ] Server filters incoming content both by local untrusted users and any remote users through some sort of spam filter ([B.4](https://w3c.github.io/activitypub/#security-spam))
  153. * [x] Implementation takes care to santizie fields containing markup to prevent cross site scripting attacks ([B.5](https://w3c.github.io/activitypub/#security-sanitizing-content))
  154. ## Other Features
  155. ### Requirements not yet specified
  156. * Discovering an actor's profile based on their URI.
  157. * TODO clarify acceptance criteria: https://github.com/w3c/activitypub/issues/173