Mastodon Wishlist (1/?)

Having been on Mastodon now for like eight months or so, I decided to write up some of the features that I've thought would be cool to have. Some of these have already been proposed, some are things I've just sorta gone wouldn't it be cool if… on.

This list is by no means comprehensive, and I'll probably think of more the second this is published, but this gives me something to look back on and say “Hey, whatever happened to that?” lol.

Pinned toots


Most of us probably already know what pinned toots are: They're toots that are pinned to the top of your profile page. Twitter has had them with tweets for quite some time.

This is really important, especially for artists, both because bio space is at a premium right now, and because unlike bios a pinned toot can be boosted and replied to, and have media attachments. (Of course, private or nonrebloggable pinned toots are an option too.)

Providing multiple pinned toots, or different pinned toots for different audiences, or perhaps an entire "featured" timeline that's distinct from the normal user timeline, are all expansions on this idea, but even with just one pinned toot you could provide links to other toots from there.


In the original issue for this idea I suggested using a "type": "pinned" Portable Contacts url to provide pinned toots. This is backwards-compatible, federates, and is allowed by the Portable Contacts spec.

"urls": [
        "value": "https://mastodon.social/users/marrus_sh/updates/312820",
        "type": "pinned"
I have no idea how Portable Contacts information is shared but here's a mock-up of what it might look like.

Alternatively, instead of storing pinned toot information in a user's contact information, it might be better to have an entire separate "featured timeline", which toots could be added to and removed from at a user's request (eg by clicking a button). The specifics of retreiving and displaying this timeline are beyond me but I can't imagine why it couldn't be done.

The current GitHub Issue for pinned toots is here.

Custom user metadata


A number of folks have expressed the desire to include pronoun information, websites, other accounts, Myers-Briggs information, birthdays, horoscopes, etc in their profile in a more visible manner. Consequently, I proposed adding a number (3–5) of configurable key-value user metadata pairs to the profile settings page, which would then show up on profiles.

Mockup for user metadata settings Mockup for user metadata profiles
My original mockup


The problem with this one is that Portable Contacts doesn't currently provide a way of distributing custom metadata information. In order to stay backwards-compatible, one option for implementing this is to include YAML frontmatter in user bios:

pronouns: "she/her"
website: "http://marrus.xyz"
This is my bio. I can put whatever I want here.
YAML mockup

This frontmatter could be easily caught and processed by frontends which supported it, and displayed verbatim by those which didn't. YAML is human-readable, and users on servers which don't implement this in-software could even type it in themselves.

Mastodon currently sends user bio information in HTML, so another option would be to hide metadata information in JSON inside the user bio:

<script type="text/plain" class="user-metadata">
  "pronouns": "she/her",
  "website": "http://marrus.xyz"
This is my bio. I can put whatever I want here.
JSON mockup

This solution is easier for frontends to process, but because the <script> tag should be stripped by any nonconforming server, it won't be available to those users whose servers don't support it.

Multiple frontend support


Some users like a more Tweetdeck-style frontend, others don't. Users should be able to choose which frontend they want to view Mastodon in when they visit the website.


I've already done this one. The problem is it breaks compatibility with anything upstream, and merge conflicts will abound. There's no way around that.

Instance metadata


The following pieces of instance metadata need to be provided to clients and there is no excuse for not doing so:

  • Maximum number of characters per toot
  • Maximum media filesize
  • Software version

Clients should have the option of respecting an instance's unique culture, and these additional pieces of information would facilitate that:

  • Title
  • Logo/icon
  • Localization data (custom words for "toot", etc; this would need to much better standardized)
  • Links (to the "about" page, and so forth)
  • Site colors
  • Client-specific information

This was all pretty much shut down when I proposed it, but I think it is essential for allowing instance customizations and cultures to flourish.


All of this metadata should be standardized and placed in a JSON file in a well-known location, for example /instance.json. Client-specific information should be allowed if properly namespaced. For example:

  "title": "I'm a Pirate!",
  "chars": 800,
  "max-filesize": 4000000,
  "localization": {
    "en": {
      "account.posts": "Messages",
      "column.home": "Deck",
      "column.notifications": "Signals",
      "column.public": "The Open Sea",
      "compose_form.publish": "Send off",
  "links": {
    "about": "/about",
    "more": "/about/more",
    "terms": "/terms"
  "mastodon": {
    "version": "1.4.3",
    "api": "/api/v1",
    "clients": {
      "http://marrus.xyz/labcoat": {
        "simple": true
Sample /instance.json

Hypothetically, this /instance.json could be expanded to provide other API endpoints in addition to the Mastodon one at /api/v1, allowing the properly-configured Mastodon server to be used with eg GNU Social frontends or apps.



Essentially, PictoChat for Mastodon. If that doesn't sound awesome, I don't know what to tell you.


There are a number of ways one could implement this, but here's a basic one:

basic implementation.

In short, this requires adding an additional media type; in addition to image, video, and gifv we would have picto. Pictos are:

  1. PNG images
  2. That are 1-bit (black & white)
  3. With no transparency
  4. And of standardized dimensions [484x220]

Specifically, pictos:

  • MUST have an IDHR header which gives the following values:
    • Width: 484
    • Height: 220
    • Bit depth: 1
    • Color type: 0
    • Compression method: Any
    • Filter method: 0
    • Interlace method: 0
  • MUST NOT contain a PLTE palette.
  • MUST NOT contain a tRNS transparency chunk
  • MAY have a bKGD background color, which MUST be 1
  • MAY have any number of other optional chunks

Whenever Mastodon receives an image matching these requirements, it is interpreted as a picto. For simplicity, frontends may also upload images to the API with picto=true; Mastodon will then create and store a conforming picto image server-side.

Frontends can style a picto to match their theme by adjusting the rendered values of the picto's bits. Furthermore, frontends can allow copying another user's picto onto the picto canvas, letting them edit and create a new picto using that user's as a base. This should generate a notification for the originating user.

Because pictos are just PNGs, servers which don't support pictos will interpret them as black-and-white images.

Collapse long toots


If a toot is too long, it should be collapsed in the frontend to save space.


I already did this one too, but it never got merged. 🤷

Better privacy settings


Right now Mastodon's privacy settings are opaque and hard to understand or communicate. direct, private, public, and unlisted are vague and not well-defined privacy features.


Instead of using direct, private, public, or unlisted, privacy should be signified through binary flags:

Value Meaning
0001 Listed in home timelines
0010 Listed in public timelines
0100 Is rebloggable
1000 Federates

The existing privacy settings would map to these as follows:

Value Meaning
1000 direct
1001 private
1101 unlisted
1111 public

However, users should not be restricted to just these traditional settings. For example, there is no good reason not to allow users to post toots which display in the public timelines but cannot be reblogged.

This list can easily be expanded; for example, if pictos were implemented, we might have:

Value Meaning
10000 Picto can be copied/edited by others

Reblog with message


This is a compromise between the people who want quote-boosts and those who do not. In essence, it allows for reblogging a toot with a custom CW; like with all CWs, @mentions, hashtags, and the like would not be functional inside the message.

This is, imo, an important safety feature, as it allows people to add CWs to content which might not have had it already before sharing with their followers. However, it could also be used to add a quick commentary when sharing something.

Obviously, this feature would only be available on toots which are able to be reblogged.


This can be implemented just by adding an additional parameter to reblogs allowing them to overwrite the CW of the original toot. Reblog notifications should also be sent when this occurs.

Disabled mentions


Users should be able to specify who can @mention them. Potential options might be everyone, local+followers, local, followers, nobody.


There are a number of possible ways of handling an improper mention:

  • Throw an error and refuse to post the toot
  • Redact the username of the mentioned user somehow
  • Pretend like the user doesn't exist and print their username in full, without any link

Of these, the first two are probably safer than the latter.

The complicating issues with this feature are in regards to federation:

  1. This setting needs to federate, and so it needs to be encoded into a user's contact information somehow
  2. If a user is not in an instance's database, it will need to fetch the user and check their settings before allowing a mention of them in a toot

Additionally, in the case of username autocomplete, username searches should be configurable to omit those users for whom mentions are disabled.