mirror of
https://akkoma.dev/AkkomaGang/akkoma.git
synced 2024-11-09 17:55:11 +00:00
Merge branch 'mastoapi-stop-capping-attachments' into 'develop'
Remove a limit on attachments in Mastodon API and document the changes in responses from vanilla Mastodon See merge request pleroma/pleroma!834
This commit is contained in:
commit
f26582aae9
11
docs/Differences-in-MastodonAPI-Responses.md
Normal file
11
docs/Differences-in-MastodonAPI-Responses.md
Normal file
|
@ -0,0 +1,11 @@
|
|||
# Differences in Mastodon API responses from vanilla Mastodon
|
||||
|
||||
A Pleroma instance can be identified by "<Mastodon version> (compatible; Pleroma <version>)" 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.
|
|
@ -166,7 +166,7 @@ defmodule Pleroma.Web.MastodonAPI.StatusView do
|
|||
sensitive: sensitive,
|
||||
spoiler_text: object["summary"] || "",
|
||||
visibility: get_visibility(object),
|
||||
media_attachments: attachments |> Enum.take(4),
|
||||
media_attachments: attachments,
|
||||
mentions: mentions,
|
||||
tags: build_tags(tags),
|
||||
application: %{
|
||||
|
|
8
mix.exs
8
mix.exs
|
@ -21,7 +21,13 @@ defmodule Pleroma.Mixfile do
|
|||
homepage_url: "https://pleroma.social/",
|
||||
docs: [
|
||||
logo: "priv/static/static/logo.png",
|
||||
extras: ["README.md", "docs/config.md", "docs/Pleroma-API.md", "docs/Admin-API.md"],
|
||||
extras: [
|
||||
"README.md",
|
||||
"docs/config.md",
|
||||
"docs/Pleroma-API.md",
|
||||
"docs/Admin-API.md",
|
||||
"docs/Differences-in-MastodonAPI-Responses.md"
|
||||
],
|
||||
main: "readme",
|
||||
output: "priv/static/doc"
|
||||
]
|
||||
|
|
Loading…
Reference in a new issue