qbism/qb_akkoma
1
0
Fork 0
forked from AkkomaGang/akkoma
Code Issues Pull requests Projects Releases Packages Wiki Activity
qb_akkoma/docs/api/differences_in_mastoapi_responses.md
rinpatch dfae0050af Move out of Gitlab Wiki 
I understand that this change is quite unreadable and hard to review, sorry for forgetting to do atomic commits. This patch does not change too much content wise, it just
* Gets everything from gitlab wiki
* Removes some specific gitlab hacks
* Formats all documentation file names to be in snake case so they look the same way as our code does
2019-03-28 19:46:30 +03:00

1.8 KiB
Raw Blame History

Differences in Mastodon API responses from vanilla Mastodon

A Pleroma instance can be identified by " (compatible; Pleroma )" present in version field in response from /api/v1/instance

Flake IDs

Pleroma uses 128-bit ids as opposed to Mastodon's 64 bits. However just like Mastodon's ids they are sortable strings

Attachment cap

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.

Timelines

Adding the parameter with_muted=true to the timeline queries will also return activities by muted (not by blocked!) users.

Statuses

Has these additional fields under the pleroma object:

  • local: true if the post was made on the local instance.
  • conversation_id: the ID of the conversation the status is associated with (if any)

Attachments

Has these additional fields under the pleroma object:

  • mime_type: mime type of the attachment.

Accounts

  • /api/v1/accounts/:id: The id parameter can also be the nickname of the user. This only works in this endpoint, not the deeper nested ones for following etc.

Has these additional fields under the pleroma object:

  • tags: Lists an array of tags for the user
  • relationship{}: Includes fields as documented for Mastodon API https://docs.joinmastodon.org/api/entities/#relationship
  • is_moderator: boolean, true if user is a moderator
  • is_admin: boolean, true if user is an admin
  • confirmation_pending: boolean, true if a new user account is waiting on email confirmation to be activated

Notifications

Has these additional fields under the pleroma object:

  • is_seen: true if the notification was read by the user