The current High Contrast theme provided with vanilla Mastodon and intended to be accessible does not comply with current industry best practise (in fact to the untrained eye it is indistinguishable from the default theme!).

Previous attempts to fix this upstream have been rebuffed for aesthetic reasons.

This feature request proposes amending the existing theme to conform as closely as possible to WCAG 2.0: https://www.w3.org/TR/WCAG20/

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/visibility-icons/

This is obviously GitHub-only and we'll probably want something similar that will work on a self-hosted version. Setting this up on some form of CI shouldn't be too hard.

Documentation: https://glitch-soc.github.io/docs/features/themes/

This is going to be a Major UI Change for sure.

Mastodon allow users to add up to four items on their profile that will be displayed as a table. Based on my observations, those items are often used for indicating:

• pronouns;
• languages;
• secondary account;
• website;
• donation profile (Liberation, Patreon, Ko-fi, etc.);
• instant messaging handle (Matrix, Discord, XMPP, etc.).

Obviously, not everyone is using all those things. But we can see how having only four items can be inconvenient. I have been struggling with that myself.
If it doesn't bring any trouble from a design perspective, I think we should allow users to display up to five items, not four. It'll give them a little more flexibility and has the advantage to feeling a little less like a random choice.

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/collapsible-toots/

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/status-data-attributes/

For votes, collapse the options under a CW as well.

Due to the nature of how federation works, you'll get yourself checking out a post's direct link to its static page to get the full conversation.

As the people of the Fediverse tend to be more technically inclined, a lot disable JavaScript by default on unknown domains as a security precaution. If a thread contains content warnings, there is no way to expand them, without having JavaScript enabled. As a result one has to allow the execution of JavaScript manually every time.

Here is an example page for examining the problem: https://harpy.life/@erinbee/102027937751106507

There would be benefits for non-technical people as well. Seeing how the size of JavaScript on the above example page exceeds 1MB, implementing this feature in pure HTML5 and CSS, would greatly reduce the required bandwidth for loading such a page and holding it in memory.
(There are other optimisations that could be done to images for example, but that is beyond the scope of this issue.)

An alternative implementation for CWs would be possible using HTML5's <details> and <summary> tags.
They are supported by every current major browser, except MS Edge - this will change in the future however.

Dynamic image loading would be trickier, but also doable I think. Maybe retaining some JavaScript for smooth functioning would be necessary here, but heavily reducing the amount of used JavaScript is definitely a possibility.

We would be trading all the benefits mentioned above for compatibility with MS Internet Explorer (any version). I'd say it's worth it.

Website: https://glitch-soc.github.io/docs/
Repository: https://github.com/glitch-soc/mastodon/

This is going to be the parent issue for all glitch.social changes to be incorporated.

• Hiding media behind subjects/CWs: #4
• Fullwidth images and videos: #5
• Image letterboxing: #6
• App settings modal: #7
• Collapsible toots: #8
• Collapsible notifications: #9
• Visibility icons on toots: #10
• Non-federated toots: #11
• Threaded posting mode: #12
• Extra data-* attributes on toots: #13
• Theming: #14
• Bookmarks: #15
• Doodles: #16

Right now, none of the CI from the original repo is carried over here. Ideally, we should look through what the other repo has and trim things down so that things are easier to self-host.

Right now, it’s hard to see the scrollbar in itself and the thumb, see screenshot:

I myself had difficulty in the beginning locating the scrollbar, and even now it’s hard to locate it instinctively, so it might be really hard for people who don’t have a perfect vision.

So we may want to tweak the colors to make it more accessible.

Right now, Mastodon takes a lot of resources to host, and there are probably a bunch of low-hanging fruit we can work on.

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/media/

From cybre.space fork: https://cybre.tech/cybrespace/mastodon/commit/0c9600eb14c32930aff35fccd11bdb2b5884d5af

We should probably just modify the existing task rather than adding a new one.

Cybre.space change: https://cybre.tech/cybrespace/mastodon/commit/28890ed0b030c3e738dd0556d0f0caf3fa77c4f6

Are you really, really sure you want to block the entire (domain)? In most cases a few targeted blocks or mutes are sufficient and preferable. You will not see content from that domain in any public timelines or your notifications. Your followers from that domain will be removed.

We need to change this.

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/threaded-mode/

One of the problems/frustrations I found with Twitter and Mastodon is the limited amount of responses that don't require a full-blown post. We have "like" but there are times when "like" doesn't make sense like when someone is expressing anxiety, sorrow, or the like. The (slightly) larger palette of responses from Facebook is nicer in that regard because talking about losing a job doesn't result in a ton of "heart" responses (which feels wrong). Likewise having a slew of "I'm sorry" responses to that also adds to information overload where simple reactions would show the emotional state. This would also related to those who don't feel comfortable posting longer text but still want to show sympathy/emotion.

I think allow the full gamut of the emoji on the server allows for more detailed conversations (e.g., The Emoji Movie comes to mind) but also the individual relationships (in my circle, green apple means something specific and Mastodon used to have the bread response to various things).

With abuse and the like, I could see that it would need to use the same filtering/muting rules that normal posts have. In some systems, they convert the "+1" or single emoji responses into a counter for display purposes. Maybe use that where someone's response of a single emoji results in collapsing down to a table instead of individual posts? I also believe ActivityPub has a place that could be used for those but places like Mastodon would then ignore it.

Related to Mastodon, this was requested mastodon/mastodon#4106.

Change from cybre.space fork:

• https://cybre.tech/cybrespace/mastodon/commit/fe6a7dfb2c9db62ca67940363b667be612580290

People sometimes upload videos or animations that can contain significant amounts of bright flashing, but they may not always add a content warning for it. Detecting this is easy and would help protect those who are susceptible to seizures.

A "flashing" flag could be added to a video/post as indication (similar to Mastodon's current NSFW flag). This flag would get set automatically if flashing is detected, or it could be set by the user manually.

People often upload pictures of text from websites or PDFs, but might not include said text in the alternative text field of the image. Having the option of letting OCR software scan the image and fill in the alternate text field automatically would be very convenient.

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/local-only-toots/

Tracking issues:

• glitch.social tracking issue: #3
• monsterfork tracking issue: #177
• configurable character counts (#18 + #19 + #20)

Links:

• https://gitlab.com/flussence/masto-css
• https://cybre.tech/cybrespace/mastodon
• https://mspsocial.net/@lawremipsum/101495129936425755 (mspsocial)

  MSP Social has implemented the following features that are not in the official Mastodon codebase:

  Local-only toots
  "Request an invitation" button
  Described-image indicator icon
  500 character bios
  Minnesota-flavored error messages

  https://github.com/lawremipsum/mspsocial-mastodon

General notes:

• CSS underlines hack
• Keeping CW box open

Any others?

Basically, we need to accumulate a list of trusted people who can accept PRs. This is on the to-do list for 0.1.

Documentation here: https://glitch-soc.github.io/docs/features/app-settings/

Not 100% sure how we're going to want to incorporate this, but it's something to consider. Going to label as abstract.

A few instances do this with CSS hacks, but it'd be nice to have something a bit nicer with configuration.

The problem is expressed in this post.

What is the expected behaviour when user B responds to a direct message of user A and mentions user C, who was not mentioned in the original message ?

The current behaviour of Mastodon is to send the reply to user A and C. However, this may not what user B expects, and it could confuse user C who cannot see the original message user B is replying to.

In the ActivityPub protocol, there is a separation between the content of a message (content field) and its recipients (to/cc/bto/bcc fields). There is no such distinction in Mastodon (or in microblogging in general), as mentioning someone adds it to the list of recipients.

When the messages are public (or unlisted), this is not really an issue, but as soon as the audience is restricted (follower-only, direct), a clear separation between who should receive the message and what is inside the message is preferable.

Will have to look up what this entails.

Right now, everything is a giant React app, which is very heavy. We might want to consider moving to something like Redux which is lighter weight, or potentially something entirely different. #48 (separating frontend and backend) might also allow for different web app versions, depending on user needs.

Basically, this is going to be a master tracking issue for ways to make the web app faster.

This has been merged via #32.

Right now, this is going to remain open until translations are added to the admin UI and API.

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/doodle/

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/collapsible-toots/

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/media/

I'm a bit iffy on the implementation so I'm going to mark this as abstract.

One of the main selling points of Mastodon always have been its 500 characters limit. Despite that, the number of characters one can use in their biography is only of 340, which is both short and a strange choice.
I would suggest to change the default limit of the number of characters that can be used in bios to 500.

Changes can be found on these branches:

• https://cybre.tech/cybrespace/mastodon/commits/branch/branding_cybre
• https://cybre.tech/cybrespace/mastodon/src/branch/feature_cybrespace_locale

Basically, anything here that could be applied to the fork as configuration settings, etc. might be worth pursuing.

Currently individual users can set filters to automatically hide toots containing certain words, phrases or links.

This feature request proposes providing admins with a "global" version they can use for known spam URLs and phrases. This would hide offending toots for all instance users when they view the federated and/or local timeline.

In future this should also be extended to allow automating silencing or suspending of accounts that toot certain URLs or phrases. This is particularly useful when there is a persistent spammer that creates accounts across multiple instances (eg. like the "womenarestupid" stunt)

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/bookmarks/

Something I've seen brought up a number of times (most recently: #29 (comment)), and which makes a lot of sense to me, is to have a clear separation between the front and back ends of Florence.

Points:

• Require different skillsets and knowledge, so should make it easier to develop
• Can be updated independently. Does this make more work for sys. admins.? Would need separate version numbers.
• Have to be careful not to step on each others' toes!
• Would enable alternative web clients/interfaces to be included in this project, and developed by others and plugged-in. Pleroma has a couple of frontend options, and it's pretty cool.
• Web client would no-longer have to be a one-size-fits-all solution, thinking RE accessibility.

I'm not at all familiar with the codebase, nor Ruby. I assume this, if pursued, would be a long-term rather than immediate goal. Like say version 3.0?

Related Tootsuite Issues:

• fully seperating UI from backend, remote logon, and preparing for the future

The CW mute or CW Filter is a feature that would, using the existent filter system, allow users to optionally add a content warning to the posts matching the filter in question, instead of hiding them entirely. this would be surfaced in the UI as such if no CW already exists:
(CW TEXT USER INPUTS) added by filters <specially formatted with a color to make it clear

when a content warning exists, it would be appended after "added by filters" IF it is not the part of the post that triggered the filter, and would instead be surfaced as a second content warning within the first (yes, nested CWs) so that users can still use that information if a word in the content warning is what is being filtered

Many glitch.social forks seem to have this but it's not documented anywhere. Keeping this open until we have things translated and an API is set up.

Example on the cybre.space fork:

• https://cybre.tech/cybrespace/mastodon/commit/a2aea63ae9306d4f29713a6e31bcf263dd775afc

Currently, the characters limit for alternate text is 420. This seems like a really random number. Why not use 500 instead? Or, if this is too much characters, 450 or 400?
If there is not technical limitations, I suggest we change this limit to 500 instead.

hi!

it would be great if florence supported the nodeinfo protocol.

nodeinfo is a unified method of fetching metrics from instances, similar to the /api/v1/instance endpoint. this is useful because it is implemented by basically every software other than mastodon, so implementing it will improve visibility into the overall health of the fediverse.

please add support for this feature.

I believe that some glitch.social instances have this but it's not documented anywhere.

Basically, anything we might want to add to this repo.

I'll incorporate this later.

• Custom emoji
  • mastodon/mastodon#9269 (alt text)
• Post features
  • mastodon/mastodon#10629 (accept formatted posts from other instances)
• General UI
  • mastodon/mastodon#6775 (allow following back from follow requests column)
  • mastodon/mastodon#8632 (resizing columns)
  • glitch-soc/mastodon#647 (use system emoji)
  • mastodon/mastodon#6189 (un-animate error GIF)
  • mastodon/mastodon#9898 (underline links)
• Technical
  • mastodon/mastodon#1469 (SVG instead of webfonts)
  • mastodon/mastodon#4800 (offer as OpenID provider)
  • mastodon/mastodon#7444 (use Atom instead of RSS)
  • mastodon/mastodon#4829 ("URI" isn't a URI in URIs)
• Muting/filtering
  • mastodon/mastodon#8293 (allow filtering bot posts)
• Localisation
  • mastodon/mastodon#8428 (allow translating instance rules)
  • mastodon/mastodon#6462 (2FA page uses wrong language)
• Federation
  • mastodon/mastodon#10096 (trust model for federation)

when creating a filter, often you will risk collateral post filtering, and removing things that are not what are intended. most of the time, this is thanks to the filter being targeted at a couple people, or a specific person, who uses the filtered text in a certain way. this can be mitigated/resolved entirely via the CW-Applying-Filter, and the ability to filter only X users posts out. this would essentially turn it into "Filter X if posted by Y users" and "Filter X if Not posted by Y users".

In UI, this would have a checkbox to expand a field marked "Filter by user" which would then have "filter posts by this/these user" and "filter posts NOT by this/these users" as radio buttons, alongside a UI that lets users add users to the list being used for the filter

This is a glitch.social feature that we can incorporate. Documentation: https://glitch-soc.github.io/docs/features/media/

Cybre.space change: https://cybre.tech/cybrespace/mastodon/commit/4bfe7c37c28f2f7231b2220a7014a93a71c9da8f

Right now, filters leave "filtered" tombstones behind in the UI, and the "drop" option in the UI kind of sucks. It'd be nice if there were better options to remove filtered elements from the UI and API at will.

Many people just get rid of the tombstones with CSS right now.