Mastodon: API to get server constants (toot length, ...)

Created on 13 Sep 2017  ·  9Comments  ·  Source: tootsuite/mastodon

It world be nice to make API to get constants thats is used in validation.

it provides some constants to need to validate profile,toots,media attachment.

  • no need to new endpoint. it may be in instance-information API.
  • no need to enumerate all the possibilities. it shows some build-time constants that used in official mastodon.

Wanted attributes from app-side validations:

  • max-length of toot + spoiler_text (already defined in web-app)
  • max-length of user display name (already defined in web-app)
  • max-length of user note (already defined in web-app)
  • max-number of media attachment (already defined in web-app)
  • list of mime types that acceptable for media attachment. (already defined in web-app)
  • max-length of attached media bytes count. (before re-encoding, it may depends on limitation in Web front server. maybe we need to make variable in .env.production ? )
api suggestion

Most helpful comment

I'm thinking limits object in /api/v1/instance, for example:

{
    uri: "example.com",
    title: "example",
    description: "<p>hoge</p>",
    email: "[email protected]",
    version: "2.1.0",
    thumbnail: "https://example.com/system/site_uploads/files/000/000/001/original/mstdn_opengraph.png"
    urls: {
      streaming_api: "wss://example.com"
    },
    stats: {
      user_count: 1,
      status_count: 1,
      domain_count: 1
    },
    limits: {
      account_display_name_length: 30,
      account_note_length: 160,
      status_length: 500,
      # 4 for images, but 1 for video?
      status_attachment_count: 4,
      # less than 8.megabytes
      attachment_size: 8.megabytes - 1,
      attachment_mime_types: ['image/jpeg', 'image/png', 'image/gif', 'video_webm', 'video/mp4'],
      attachment_extensions: ['.jpg', '.jpeg', '.png', '.gif', '.webm', '.mp4', '.m4v']
    }
  }

All 9 comments

As far as I know, mstdn.maud.io has modified these constants
Kanzaki-don also changes the upper limit of the number of bytes of attached media

I'd be very interested in that too. Now that Pleroma speaks the Mastodon api, it would be good if it was possible to tell client apps how much characters they can actually use.

This is a really good idea yeah.

I'm thinking limits object in /api/v1/instance, for example:

{
    uri: "example.com",
    title: "example",
    description: "<p>hoge</p>",
    email: "[email protected]",
    version: "2.1.0",
    thumbnail: "https://example.com/system/site_uploads/files/000/000/001/original/mstdn_opengraph.png"
    urls: {
      streaming_api: "wss://example.com"
    },
    stats: {
      user_count: 1,
      status_count: 1,
      domain_count: 1
    },
    limits: {
      account_display_name_length: 30,
      account_note_length: 160,
      status_length: 500,
      # 4 for images, but 1 for video?
      status_attachment_count: 4,
      # less than 8.megabytes
      attachment_size: 8.megabytes - 1,
      attachment_mime_types: ['image/jpeg', 'image/png', 'image/gif', 'video_webm', 'video/mp4'],
      attachment_extensions: ['.jpg', '.jpeg', '.png', '.gif', '.webm', '.mp4', '.m4v']
    }
  }

How about capabilities, or caps instead of limits? Then, we can add information not only limitation, but also whether the instance implements features such as pinned toots by simply add pinned_toots: true.

As far as I can tell, Gargron will block these kinds of feature requests. see https://github.com/tootsuite/mastodon/pull/5697

@lambadalambda I've read your PR and his comments, then I wonder if it's only exposing without making configurable.

We may change constraints in the future, even if we don't support customizations. So exposing those constraints via API is still useful for third-party clients.

@nullkal Hmm, should those information be in the same property? Also don't clients want to know feature/endpoint versions, instead of only existence?

Pleroma has "max_toot_chars" in https://pleroma.soykaf.com/api/v1/instance .

Was this page helpful?
0 / 5 - 0 ratings

Related issues

golbette picture golbette  ·  3Comments

selfagency picture selfagency  ·  3Comments

almafeta picture almafeta  ·  3Comments

KellerFuchs picture KellerFuchs  ·  3Comments

Lewiscowles1986 picture Lewiscowles1986  ·  3Comments