Merge pull request 'Merge search behaviour change, and refactor elasticsearch' (...
[akkoma] / docs / development / API / differences_in_mastoapi_responses.md
1 # Differences in Mastodon API responses from vanilla Mastodon
2
3 A Pleroma instance can be identified by "<Mastodon version> (compatible; Pleroma <version>)" present in `version` field in response from `/api/v1/instance`
4
5 ## Flake IDs
6
7 Pleroma uses 128-bit ids as opposed to Mastodon's 64 bits. However, just like Mastodon's ids, they are lexically sortable strings
8
9 ## Timelines
10
11 Adding the parameter `with_muted=true` to the timeline queries will also return activities by muted (not by blocked!) users.
12
13 Adding the parameter `exclude_visibilities` to the timeline queries will exclude the statuses with the given visibilities. The parameter accepts an array of visibility types (`public`, `unlisted`, `private`, `direct`), e.g., `exclude_visibilities[]=direct&exclude_visibilities[]=private`.
14
15 Adding the parameter `reply_visibility` to the public and home timelines queries will filter replies. Possible values: without parameter (default) shows all replies, `following` - replies directed to you or users you follow, `self` - replies directed to you.
16
17 Adding the parameter `instance=lain.com` to the public timeline will show only statuses originating from `lain.com` (or any remote instance).
18
19 Home, public, hashtag & list timelines accept these parameters:
20
21 - `only_media`: show only statuses with media attached
22 - `local`: show only local statuses
23 - `remote`: show only remote statuses
24
25 ## Statuses
26
27 - `visibility`: has additional possible values `list` and `local` (for local-only statuses)
28
29 Has these additional fields under the `pleroma` object:
30
31 - `local`: true if the post was made on the local instance
32 - `conversation_id`: the ID of the AP context the status is associated with (if any)
33 - `direct_conversation_id`: the ID of the Mastodon direct message conversation the status is associated with (if any)
34 - `in_reply_to_account_acct`: the `acct` property of User entity for replied user (if any)
35 - `content`: a map consisting of alternate representations of the `content` property with the key being its mimetype. Currently, the only alternate representation supported is `text/plain`
36 - `spoiler_text`: a map consisting of alternate representations of the `spoiler_text` property with the key being its mimetype. Currently, the only alternate representation supported is `text/plain`
37 - `expires_at`: a datetime (iso8601) that states when the post will expire (be deleted automatically), or empty if the post won't expire
38 - `thread_muted`: true if the thread the post belongs to is muted
39 - `emoji_reactions`: A list with emoji / reaction maps. The format is `{name: "☕", count: 1, me: true}`. Contains no information about the reacting users, for that use the `/statuses/:id/reactions` endpoint.
40 - `parent_visible`: If the parent of this post is visible to the user or not.
41 - `pinned_at`: a datetime (iso8601) when status was pinned, `null` otherwise.
42
43 ## Scheduled statuses
44
45 Has these additional fields in `params`:
46
47 - `expires_in`: the number of seconds the posted activity should expire in.
48
49 ## Media Attachments
50
51 Has these additional fields under the `pleroma` object:
52
53 - `mime_type`: mime type of the attachment.
54
55 ### Attachment cap
56
57 Some apps operate under the assumption that no more than 4 attachments can be returned or uploaded. Pleroma however does not enforce any limits on attachment count neither when returning the status object nor when posting.
58
59 ### Limitations
60
61 Pleroma does not process remote images and therefore cannot include fields such as `meta` and `blurhash`. It does not support focal points or aspect ratios. The frontend is expected to handle it.
62
63 ## Accounts
64
65 The `id` parameter can also be the `nickname` of the user. This only works in these endpoints, not the deeper nested ones for following etc.
66
67 - `/api/v1/accounts/:id`
68 - `/api/v1/accounts/:id/statuses`
69
70 `/api/v1/accounts/:id/statuses` endpoint accepts these parameters:
71
72 - `pinned`: include only pinned statuses
73 - `tagged`: with tag
74 - `only_media`: include only statuses with media attached
75 - `with_muted`: include statuses/reactions from muted accounts
76 - `exclude_reblogs`: exclude reblogs
77 - `exclude_replies`: exclude replies
78 - `exclude_visibilities`: exclude visibilities
79
80 Endpoints which accept `with_relationships` parameter:
81
82 - `/api/v1/accounts/:id`
83 - `/api/v1/accounts/:id/followers`
84 - `/api/v1/accounts/:id/following`
85 - `/api/v1/mutes`
86
87 Has these additional fields under the `pleroma` object:
88
89 - `ap_id`: nullable URL string, ActivityPub id of the user
90 - `background_image`: nullable URL string, background image of the user
91 - `tags`: Lists an array of tags for the user
92 - `relationship` (object): Includes fields as documented for Mastodon API https://docs.joinmastodon.org/entities/relationship/
93 - `is_moderator`: boolean, nullable, true if user is a moderator
94 - `is_admin`: boolean, nullable, true if user is an admin
95 - `confirmation_pending`: boolean, true if a new user account is waiting on email confirmation to be activated
96 - `hide_favorites`: boolean, true when the user has hiding favorites enabled
97 - `hide_followers`: boolean, true when the user has follower hiding enabled
98 - `hide_follows`: boolean, true when the user has follow hiding enabled
99 - `hide_followers_count`: boolean, true when the user has follower stat hiding enabled
100 - `hide_follows_count`: boolean, true when the user has follow stat hiding enabled
101 - `settings_store`: A generic map of settings for frontends. Opaque to the backend. Only returned in `/api/v1/accounts/verify_credentials` and `/api/v1/accounts/update_credentials`
102 - `chat_token`: The token needed for Pleroma shoutbox. Only returned in `/api/v1/accounts/verify_credentials`
103 - `deactivated`: boolean, true when the user is deactivated
104 - `allow_following_move`: boolean, true when the user allows automatically follow moved following accounts
105 - `unread_conversation_count`: The count of unread conversations. Only returned to the account owner.
106 - `unread_notifications_count`: The count of unread notifications. Only returned to the account owner.
107 - `notification_settings`: object, can be absent. See `/api/v1/pleroma/notification_settings` for the parameters/keys returned.
108 - `accepts_chat_messages`: boolean, but can be null if we don't have that information about a user
109 - `favicon`: nullable URL string, Favicon image of the user's instance
110
111 ### Source
112
113 Has these additional fields under the `pleroma` object:
114
115 - `show_role`: boolean, nullable, true when the user wants his role (e.g admin, moderator) to be shown
116 - `no_rich_text` - boolean, nullable, true when html tags are stripped from all statuses requested from the API
117 - `discoverable`: boolean, true when the user allows external services (search bots) etc. to index / list the account (regardless of this setting, user will still appear in regular search results)
118 - `actor_type`: string, the type of this account.
119
120 ## Conversations
121
122 Has an additional field under the `pleroma` object:
123
124 - `recipients`: The list of the recipients of this Conversation. These will be addressed when replying to this conversation.
125
126 ## GET `/api/v1/conversations`
127
128 Accepts additional parameters:
129
130 - `recipients`: Only return conversations with the given recipients (a list of user ids). Usage example: `GET /api/v1/conversations?recipients[]=1&recipients[]=2`
131
132 ## Account Search
133
134 Behavior has changed:
135
136 - `/api/v1/accounts/search`: Does not require authentication
137
138 ## Search (global)
139
140 Unlisted posts are available in search results, they are considered to be public posts that shouldn't be shown in local/federated timeline.
141
142 ## Notifications
143
144 Has these additional fields under the `pleroma` object:
145
146 - `is_seen`: true if the notification was read by the user
147
148 ### Move Notification
149
150 The `type` value is `move`. Has an additional field:
151
152 - `target`: new account
153
154 ### EmojiReact Notification
155
156 The `type` value is `pleroma:emoji_reaction`. Has these fields:
157
158 - `emoji`: The used emoji
159 - `account`: The account of the user who reacted
160 - `status`: The status that was reacted on
161
162 ### ChatMention Notification (not default)
163
164 This notification has to be requested explicitly.
165
166 The `type` value is `pleroma:chat_mention`
167
168 - `account`: The account who sent the message
169 - `chat_message`: The chat message
170
171 ### Report Notification (not default)
172
173 This notification has to be requested explicitly.
174
175 The `type` value is `pleroma:report`
176
177 - `account`: The account who reported
178 - `report`: The report
179
180 ## GET `/api/v1/notifications`
181
182 Accepts additional parameters:
183
184 - `exclude_visibilities`: will exclude the notifications for activities with the given visibilities. The parameter accepts an array of visibility types (`public`, `unlisted`, `private`, `direct`). Usage example: `GET /api/v1/notifications?exclude_visibilities[]=direct&exclude_visibilities[]=private`.
185 - `include_types`: will include the notifications for activities with the given types. The parameter accepts an array of types (`mention`, `follow`, `reblog`, `favourite`, `move`, `pleroma:emoji_reaction`, `pleroma:chat_mention`, `pleroma:report`). Usage example: `GET /api/v1/notifications?include_types[]=mention&include_types[]=reblog`.
186
187 ## DELETE `/api/v1/notifications/destroy_multiple`
188
189 An endpoint to delete multiple statuses by IDs.
190
191 Required parameters:
192
193 - `ids`: array of activity ids
194
195 Usage example: `DELETE /api/v1/notifications/destroy_multiple/?ids[]=1&ids[]=2`.
196
197 Returns on success: 200 OK `{}`
198
199 ## POST `/api/v1/statuses`
200
201 Additional parameters can be added to the JSON body/Form data:
202
203 - `preview`: boolean, if set to `true` the post won't be actually posted, but the status entity would still be rendered back. This could be useful for previewing rich text/custom emoji, for example.
204 - `content_type`: string, contain the MIME type of the status, it is transformed into HTML by the backend. You can get the list of the supported MIME types with the nodeinfo endpoint.
205 - `to`: A list of nicknames (like `lain@soykaf.club` or `lain` on the local server) that will be used to determine who is going to be addressed by this post. Using this will disable the implicit addressing by mentioned names in the `status` body, only the people in the `to` list will be addressed. The normal rules for post visibility are not affected by this and will still apply.
206 - `visibility`: string, besides standard MastoAPI values (`direct`, `private`, `unlisted`, `local` or `public`) it can be used to address a List by setting it to `list:LIST_ID`.
207 - `expires_in`: The number of seconds the posted activity should expire in. When a posted activity expires it will be deleted from the server, and a delete request for it will be federated. This needs to be longer than an hour.
208 - `in_reply_to_conversation_id`: Will reply to a given conversation, addressing only the people who are part of the recipient set of that conversation. Sets the visibility to `direct`.
209
210 ## GET `/api/v1/statuses`
211
212 An endpoint to get multiple statuses by IDs.
213
214 Required parameters:
215
216 - `ids`: array of activity ids
217
218 Usage example: `GET /api/v1/statuses/?ids[]=1&ids[]=2`.
219
220 Returns: array of Status.
221
222 The maximum number of statuses is limited to 100 per request.
223
224 ## PATCH `/api/v1/accounts/update_credentials`
225
226 Additional parameters can be added to the JSON body/Form data:
227
228 - `no_rich_text` - if true, html tags are stripped from all statuses requested from the API
229 - `hide_followers` - if true, user's followers will be hidden
230 - `hide_follows` - if true, user's follows will be hidden
231 - `hide_followers_count` - if true, user's follower count will be hidden
232 - `hide_follows_count` - if true, user's follow count will be hidden
233 - `hide_favorites` - if true, user's favorites timeline will be hidden
234 - `show_role` - if true, user's role (e.g admin, moderator) will be exposed to anyone in the API
235 - `default_scope` - the scope returned under `privacy` key in Source subentity
236 - `pleroma_settings_store` - Opaque user settings to be saved on the backend.
237 - `skip_thread_containment` - if true, skip filtering out broken threads
238 - `allow_following_move` - if true, allows automatically follow moved following accounts
239 - `also_known_as` - array of ActivityPub IDs, needed for following move
240 - `pleroma_background_image` - sets the background image of the user. Can be set to "" (an empty string) to reset.
241 - `discoverable` - if true, external services (search bots) etc. are allowed to index / list the account (regardless of this setting, user will still appear in regular search results).
242 - `actor_type` - the type of this account.
243 - `accepts_chat_messages` - if false, this account will reject all chat messages.
244 - `language` - user's preferred language for receiving emails (digest, confirmation, etc.)
245
246 All images (avatar, banner and background) can be reset to the default by sending an empty string ("") instead of a file.
247
248 ### Pleroma Settings Store
249
250 Pleroma has mechanism that allows frontends to save blobs of json for each user on the backend. This can be used to save frontend-specific settings for a user that the backend does not need to know about.
251
252 The parameter should have a form of `{frontend_name: {...}}`, with `frontend_name` identifying your type of client, e.g. `pleroma_fe`. It will overwrite everything under this property, but will not overwrite other frontend's settings.
253
254 This information is returned in the `/api/v1/accounts/verify_credentials` endpoint.
255
256 ## Authentication
257
258 *Pleroma supports refreshing tokens.*
259
260 ### POST `/oauth/token`
261
262 You can obtain access tokens for a user in a few additional ways.
263
264 #### Refreshing a token
265
266 To obtain a new access token from a refresh token, pass `grant_type=refresh_token` with the following extra parameters:
267
268 - `refresh_token`: The refresh token.
269
270 #### Getting a token with a password
271
272 To obtain a token from a user's password, pass `grant_type=password` with the following extra parameters:
273
274 - `username`: Username to authenticate.
275 - `password`: The user's password.
276
277 #### Response body
278
279 Additional fields are returned in the response:
280
281 - `id`: The primary key of this token in Pleroma's database.
282 - `me` (user tokens only): The ActivityPub ID of the user who owns the token.
283
284 ## Account Registration
285
286 `POST /api/v1/accounts`
287
288 Has these additional parameters (which are the same as in Pleroma-API):
289
290 - `fullname`: optional
291 - `bio`: optional
292 - `captcha_solution`: optional, contains provider-specific captcha solution,
293 - `captcha_token`: optional, contains provider-specific captcha token
294 - `captcha_answer_data`: optional, contains provider-specific captcha data
295 - `token`: invite token required when the registrations aren't public.
296 - `language`: optional, user's preferred language for receiving emails (digest, confirmation, etc.), default to the language set in the `userLanguage` cookies or `Accept-Language` header.
297
298 ## Instance
299
300 `GET /api/v1/instance` has additional fields
301
302 - `max_toot_chars`: The maximum characters per post
303 - `chat_limit`: The maximum characters per chat message
304 - `description_limit`: The maximum characters per image description
305 - `poll_limits`: The limits of polls
306 - `upload_limit`: The maximum upload file size
307 - `avatar_upload_limit`: The same for avatars
308 - `background_upload_limit`: The same for backgrounds
309 - `banner_upload_limit`: The same for banners
310 - `background_image`: A background image that frontends can use
311 - `pleroma.metadata.features`: A list of supported features
312 - `pleroma.metadata.federation`: The federation restrictions of this instance
313 - `pleroma.metadata.fields_limits`: A list of values detailing the length and count limitation for various instance-configurable fields.
314 - `pleroma.metadata.post_formats`: A list of the allowed post format types
315 - `vapid_public_key`: The public key needed for push messages
316
317 ## Push Subscription
318
319 `POST /api/v1/push/subscription`
320 `PUT /api/v1/push/subscription`
321
322 Permits these additional alert types:
323
324 - pleroma:chat_mention
325 - pleroma:emoji_reaction
326
327 ## Markers
328
329 Has these additional fields under the `pleroma` object:
330
331 - `unread_count`: contains number unread notifications
332
333 ## Streaming
334
335 ### Chats
336
337 There is an additional `user:pleroma_chat` stream. Incoming chat messages will make the current chat be sent to this `user` stream. The `event` of an incoming chat message is `pleroma:chat_update`. The payload is the updated chat with the incoming chat message in the `last_message` field.
338
339 ### Remote timelines
340
341 For viewing remote server timelines, there are `public:remote` and `public:remote:media` streams. Each of these accept a parameter like `?instance=lain.com`.
342
343 ### Follow relationships updates
344
345 Pleroma streams follow relationships updates as `pleroma:follow_relationships_update` events to the `user` stream.
346
347 The message payload consist of:
348
349 - `state`: a relationship state, one of `follow_pending`, `follow_accept` or `follow_reject`.
350
351 - `follower` and `following` maps with following fields:
352 - `id`: user ID
353 - `follower_count`: follower count
354 - `following_count`: following count
355
356 ## User muting and thread muting
357
358 Both user muting and thread muting can be done for only a certain time by adding an `expires_in` parameter to the API calls and giving the expiration time in seconds.
359
360 ## Not implemented
361
362 Pleroma is generally compatible with the Mastodon 2.7.2 API, but some newer features and non-essential features are omitted. These features usually return an HTTP 200 status code, but with an empty response. While they may be added in the future, they are considered low priority.
363
364 ### Suggestions
365
366 *Added in Mastodon 2.4.3*
367
368 - `GET /api/v1/suggestions`: Returns an empty array, `[]`
369
370 ### Trends
371
372 *Added in Mastodon 3.0.0*
373
374 - `GET /api/v1/trends`: Returns an empty array, `[]`
375
376 ### Identity proofs
377
378 *Added in Mastodon 2.8.0*
379
380 - `GET /api/v1/identity_proofs`: Returns an empty array, `[]`
381
382 ### Endorsements
383
384 *Added in Mastodon 2.5.0*
385
386 - `GET /api/v1/endorsements`: Returns an empty array, `[]`
387
388 ### Featured tags
389
390 *Added in Mastodon 3.0.0*
391
392 - `GET /api/v1/featured_tags`: Returns HTTP 404