For some reason on glitchsoc if I click to show a sensitive image it opens that post up in the context column which is not expected behavior. This doesn't happen in Mastodon v1.4.1

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

It's just so ever slightly higher than it, for some reason

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

this is such a prevalent problem that i have seen it on twitter, and on mastodon, since before i ever knew what it meant. "my notifications exploded" and the like, all mean that a simple post got Too Popular and overwhelmed any ability to use the account as normal is impossible.

the solution is the ability to temporarily or permanently dismiss notifications from a certain thread.

as such, clicking on a post's action menu (the ... at the bottom) (at any level, base or reply, etc) should give us a "mute thread" option, with a list of three things to hide from any replies or actions on that post or it's successors in the thread.

• hide favorites
• hide boosts
• hide replies

all would presumably default to being checked when you click the mute thread button, and whenever a thread is currently muted, in the column options for your notifications, a button should be added to "view muted threads" that would show all notifications being hidden, and add a button beside each one to "unmute thread"

EDIT: in theory we do not want to load the notifications at all, they should not be sent to the client unless they request them by clicking view muted threads

We keep wanting to have more granularity of control over our toots- does it show on our profile, does it only go to the mentioned ppl, does it leave the local instance, etc.

However, the proliferation of controls runs the risk of scaring off or overwhelming new users.

Hence I propose two modes for the toot dynamics config interface:

Simple Mode (on by default):

- DM/Direct to Mentioned
- Followers
- Public Timeline

^ (this basically just hides federation-specific controlling and boostability-controlling)

POWER MODE

Visibility: (WHO can see it, checkboxes)
 - Mentioned
 - Followers
 - On Local TL
 - On Federated TLs
 - On My Profile

Actions: (WHAT can be done with it, toggles)
 - Boostable (maybe further breakdown, local vs federated)
 (potentially add) quoteable
 (potentially add) direct linking (disabling direct-to-toot URL from timestamp or something, idk)

Propagation (WHICH INSTANCES get it, slider?)
 - Only Local Instance
 - Federating: open borders only
 - Federating: open borders or silenced
 - Federating: Literally Anybody

Propogation would be actually implemented as a set of binary toggles like:
prop_federate
prop_to_silenced
prop_to_blocked

In this splitting of settings, the Simple Mode settings translate to:

Direct to Mentioned =  {
 Set to True: vis_mentioned, act_linkable, prop_federate, prop_to_silenced
 Set False: vis_followers, vis_localTL, vis_federatedTLs, vis_profile, act_boostable, act_quoteable, act_linkable, prop_to_blocked
}
Followers = {
 Set to True: vis_mentioned, vis_followers, act_linkable, prop_federate, prop_to_silenced
 Set False: vis_localTL, vis_federatedTLs, vis_profile, act_boostable, act_quoteable, act_linkable, prop_to_blocked
}
Public = {
 Set to True: vis_mentioned, vis_followers, vis_localTL, vis_federatedTLs, vis_profile,
     act_boostable, act_linkable, prop_federate, prop_to_silenced
 Set False: act_quoteable, prop_to_blocked
}

Text from corresponding issue on tootsuite:

"The primary function of muting for me, as a high follower-count user, is to remove someone's comments from my notifications without them knowing I have done so (via not seeing my posts etc). Block = "I don't want this person to see me", Mute = "I don't want to see this person." If I block a troll they claim it as a victory and I just get more trolls. If I block someone who is an "overzealous fan" I've had quite a few incidents of them tracking down my contact info (via my website, the mastodon discord server, etc.) and interrogating me on what they did wrong, when I never wanted to bother with that conversation and wished I could use mute to avoid that social drama. I also sometimes get others hearing I blocked someone and asking what they "did wrong" when it was really just that they replied to my posts too much with inane comments.

Expected behavior: A muted user's mentions or replies of me do not show up in my notifications, as on other social media.
Actual behavior (v1.4.1): A muter user's replies and mentions of me show up in my notifications.

Muting is essentially useless to me when it has such a large hole for harassment to go through. Blocking people who harass me always makes them go brag about it and then others seek to get blocked as well. I haven't muted any servers but if muting a server behaves like muting an individual user then that also removes that feature's anti-harassment aspect."

On glitchsoc we could have a "soft mute" and "hard mute" for the two behaviors

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

For some reason the compose box was made narrower on glitchsoc which I don't like personally but more importantly when you upload an image this is what happens:

It's really cluttered and difficult to see all the small things and understand them and stuff.

Solution: Return compose column to how it is on mainline or otherwise increase the width. I personally also find it weird and distracting how the column is now a box creating a massive color contrast in the empty space. My eyes are drawn there more than anything else and there's nothing there.

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

see here for info about how they work

i think something that better reflected the needs/state/style of the project would be nice

see here for info about how they work

i think something that better reflected the needs/state/style of the project would be nice

when a user replies to a toot ending in the local only marker (the eye emoji currently), the local only UI toggle should be defaulted to 'on'

A bug in my last PR, oops

The current "Authorized Followers" screen gives you the ability to select entire instances and force everyone from that instance to unfollow you. This is incredibly useful, if a whole instance seeing your private posts is a problem (say, if an instance doesn't respect post privacy). However, you cannot see which users from that instance follow you, only how many, and you cannot force-unfollow individual users without "softblocking," or blocking the user and then unblocking them.

I would suggest putting a sort of dropdown arrow next to a domain's listing in the page, which would then display individual users' basic information for you to then decide upon. Hitting the check on the instance would, of course, select every user in that instance's list, but you could also select or deselect individuals from this as well.

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

the ability to mark a post of any privacy level to Not federate to other instances. this enables local-timeline-only posting, and allows other interesting interactions, like unlisted posts to only people you trust on a private instance that's just yr closest friends.

Currently, at the very least, the following things are not served by the API and could be to make things a little nicer on clients:
The default post setting for your account
The character limit for posts on an instance
Muted conversations
Regex filtering/keywords
The maximum size of files for media posts
Information about the instance/the API? (this was something I believe @marrus-sh kinda brought up in discord as maybe being given somehow elsewise but I didn't totally get, please feel free to input on that one and I can edit or disregard this portion as necessary!)

Any additions are welcome, this was a result of my searching through discord for everything people had complained about not being available.

I like the user metadata fields and people have expressed interest in them so I want to transition them from a cheap hack to a more fully-fledged feature! Here's what needs to happen:

• Initial support added in 0d3ec19 with linting fixes in 414dfb3
• Better define the YAML frontmatter regex to match the spec 😉
  • Implemented with e6300de
  • \n line-break support added with ab4632a
• (Maybe?) Improve backwards-compatible frontmatter support (notably: support " and ')
  • Implemented with e6300de
• Figure out and handle YAML character escaping
  • Implemented in e6300de
• Increase or remove character limits for metadata keys and (especially) values
  • Implemented in e6300de
• Style the metadata table…
  • as a CSS table instead of using flexboxes, which are frankly overkill
  • as allowing either one or two (vertically-centered) lines, with text-overflow: ellipsis for any content that doesn't fit.
  • Implemented in e6300de
• Show on static pages
  • Implemented in 6107e95 with a minor fix in 6cbbdc8
  • Improvements to styling made in 03f9648 and 7b1d233
• Intercept simplified_format(account) in app/lib/formatter.rb to not break the YAML when formatting HTML
  • Likely VERY IMPORTANT in the case of hashtags, links, usernames
• Handle links so they open in new tabs or web view or whatever
• Write up a spec defining what is and isn't recognized
  • See the comment in e6300de although more should be said
• Make sure \UXXXXXXXX escapes are actually valid in regex to avoid errors
• Potentially fail to support certain YAML escape codes (such as \0) or restrict escapes to only characters in c-printable.
• Improve input methods beyond plain-text in the bio entry field (?)
  • The createBio() function was added to ease with this in c588778
• Make profile metadata not count towards bio length (?)
  • WIP implemented in 4f36aad
• Support multiline values (??)
• Maybe make the entire table scroll (fix a max-height), instead of individual boxes 😅

bios as they are do not have enough space for a complete thought, let alone a description of yourself.

i propose bumping the field to 500 characters

EDIT: bios already got counters, i just missed that update

mockup now complete!

hashtags as they are rarely used, and when they are used, they are clunky, and break the flow of a post as a thing to read, or just feel odd when in the body of it.

to alleviate this and improve on the feature, i suggest several changes

minimum necessary is as follows

• making a separate section of the post for hashtags only, and an "add tag" button when drafting a post to let users choose from hashtags they have added before, and predefined ones such as #lewd or #art etc, as well as add new ones. the UI for this i can map out at a later time.
• the ability to make your account default on all posts to have certain tags present on them
• hashtags added to the body of a post automatically added to section for tags only after the post
• make this extra section only be shown when you hover over the post or view it in full context in rightmost column

below is the wishlist, polish and fancy shit that we can add after the minimum necessary for a functional feature

• the ability to filter timelines (home, public and lists should they ever exist) to only show a tag, or hide tags from the timeline when viewing it normally (API side, as well as temporarily through UI in column settings)
• making the ability to mute tags, presumably through the same feature as keyword muting, should it ever come into existence
• the ability to make images hidden by default / click to show if the post is tagged with tags you choose ('content-mute' option, somewhere)

Todo:

• Put images inside of CWs for normal statuses
  • Implemented in 38a1299
• Solve problems relating to sensitive media (#32)
  • Partially solved in 19690d3 and solved the rest of the way in b525caf
• Modify the CW button to show whether or not there is an image inside
  • Implemented in 99889ea and improved in cc4cba8
• Put images inside of CWs for detailed statuses
  • Implemented in 651c3d6
• Verify everything works on static pages
  • Implemented in fc65b69
• Update the tootsuite PR accordingly
  • See mastodon#3979

The toot privacy dropdown spawns inside the modal for creating the toots, forcing me to scroll down every time I want to pick something outside the default.

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

(because they're rendered as <video> not <img>)

I can't tell if this is just a failure on the part of the Mastodon frontend or if the API literally won't let you do this, but you should 100% be able to do this imo.

Tasklist

• Create settings modal (see #39)
  • Implemented in 595c6de
• Redefine all of Mastodon's colours using semantic variables [eg, ui-body-text, ui-header-text, ui-column-color, and so forth] so that these can be easily changed independently.
• Define new light-mode and high-contrast values for the above.
• Define mixins in the manner of the ones already currently used for multi-/single-column layout for various options
  • For reduce-animation
  • For no-transparency
  • For high-contrast
  • For light-mode
    • For these latter two, perhaps redefine the semantic variables above inside the mixin; eg:

      [[content]]
      .light-mode & {
          $redefined-color: #074e4c;
          [[content]]
      }

• Apply mixins to CSS
• Add options to the settings modal to enable these settings

Original post

Would love it if the Mastodon frontend had the following options:

• reduce_animation: Removes all the CSS transitions, spinning effects, etc. on the frontend. Conserves resources and is less distracting.
• no_transparency: Eliminate all semi-opaque elements from the UI and make the media lightbox an opaque colour.
• high_contrast: Increases the contrast of UI elements.
• light_mode: Dark text on a light background instead of vice-versa.

All of this can be implemented through CSS but it will be a chore, and then there's the matter of activating/deactivating these options.

Specifically, the frontend needs to be able to interact with the following endpoints:

• PATCH /api/v1/accounts/update_credentials
• GET /api/v1/instance
• Anything new added by #30

This is a prerequisite for adding this stuff to App Settings as in #39.

All these new features that make things collapse makes it take a rly long time to like, analyze a post to see what kinda content is there and then go through the process of viewing it. A lotta clicks to see those dicks if you know what I mean.

I'd like to be able to disable things like hiding images under CWs, collapsing toots, collapsing images, etc.

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

When a toot is flagged with a CW and contains images, it's collapsed behind the Read More with an image marker, as follows:

While the presence of the marker is very important (and imo hiding CW images is as well), it may be easy to overlook as it blends into the toot's information and/or collapsing marker, and makes the user have to glance consciously to the top of toot to verify it's there or not.

A possible solution is borrowing the blue colour from the collapse marker, which can work as a subconscious context clue that there are hidden images in the CW toot, but I'm not entirely sure (colour blindness?).

Another possible solution is also putting the image marker inside the Show More.

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

the existing one is kinda terse/minimal/code focused and only has links to tootsuite

i reckon we can make it nicer and better

we already have a system for follow requests, and this system could be duplicated and extended to allow many things that (while not inherently bad) can be very bad when done without permission.

the number one worry as a target of harassment is venues for harassment, "just how easy" is it for someone to harass you. hotlinking someone's profile instantly sets that level to max, it is too easy, and anyone can do it at a few clicks.

so, an innocuous thing, like linking someone else's @ in your profile, can go from innocent to malicious purely based on the case.

the easy way to fix this is to require permission. in other words, when you submit a bio (or, should pinned toots exist, when you try to pin a toot that has someone else's @ in it) it would send them a request, similar to how follower requests are currently implemented, that asks permission. upon the user giving permission, it would approve/submit the bio change/pin that was requested.

white on white is hard to read

This is better for accessibility and better for life.
Right now Mastodon uses <div> for everything. Gross.
It should use <header>, <nav>, <footer>, <aside>, <section>, <main> where appropriate.
Statuses should be wrapped in <article> as they are standalone potentially-rebloggable content.

Also Mastodon should really use <b> instead of <strong> unless it is intending to be shouting.

Todo:

• Create the modal
  • Implemented in 595c6de with important bugfixes in 2d8ebdc and 0b371da
• Add a setting for toggling wide view in desktop mode (#33)
  • Part of initial implementation
• Add settings for configuring collapsed-toot functionality (#35)
  • Part of initial implementation
• Add additional settings from elsewhere (column settings, preferences) (depends on #30 for some features)
  • Letterboxed media settings added in ec2daae
• Improve styling
• Improve language

Not sure why but even if I uncheck "give collapsed toots image background" it still does it anyway. On Firefox in Windows.

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

I have stereoscopy problems and moving my eyes horizontally so much tires my eyes out and then I can't read for a while and also get a migraine. Please let me disable full-width

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

private post federation is a powerful feature, but there's a lot of other details that can be worked out alongside it and improved.

exposing more options to users to allow them to customize their experience and capabilities is, in my opinion always the better route for devs to take. for private posts and federation, there are many things that can/should be exposed to the user.

an example would be fine-tuning on federation, IE, levels of trust in your followers, for those that end up with a massive account.

the first set of options to start with is as follows:

1. distribute to all followers
   this option is pretty simple, and trusts all your followers with your private posts without any checks or balances.
2. distribute to followers on mastodon instances
   this option allows users to trust based on technology, by allowing the user to know that their toots will only ever be boosted by a hacked/modified mastodon instance that does not respect post privacy. this is also a fairly good middleground, and would be where i set the default for this set of settings
3. distribute to people who follow me that i also follow (mutuals)
   this is another way to limit your private posts that would be very powerful for users to have, by letting you only trust mutuals, it also enforces a good balance for more private posts such as venting and the like, it allows you to only let people who care about you, and you care about them (by care i mean follow) see your private and thus most vulnerable posts
4. distribute to only users on my instance (possibly allow another subsection choice on only mutuals

i will update this post with any other ideas i have to flesh out and improve this feature as they come to me.

EDIT:
the description in the drop down menu should change appropriately (and possibly have a gear you can click to jump to that part of the settings menu) for private posts

since dev.glitch.social is unlikely to be people's main instance due to instability, i suggest a bot be added to dev.glitch.social that updates when glitchsoc the fork updates to alert people that there are things to check out on the dev instance

When I mute someone it's because I don't want them talking to me anymore, without having to go through the drama of them realizing I blocked them. It's an "assisted ignoring" in my mind. As a popular user, blocking people becomes An Ordeal and people often hassle me in private to ask why I blocked them and the only answer is "I found you annoying" which just isn't worth it. I want to be able to mute someone and that means they can see all my stuff fine but I don't see their posts in my feeds and if they @ me it doesn't show up in my notifications.

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

For anyone who didn't write the code itself, what causes someone to federate to an instance regarding public timelines is shrouded in mystery and confusion. You can explain it a million times but there's a few "if > if > if" that are quite considerably removed from the simple answer of "If someone from that instance follows you."

There is no existing feature that allows users to see what all instances take their public timeline posts right now, with the best guess of who's all seeing you is posting "everybody favourite this post". I've found myself posting to public timelines and getting replies from instances I ain't ever heard of without anybody boosting me. I assume they saw me in their federated timeline.

This is would quite similar to the existing feature called Authorized Followers, which lists all the instances of your followers.

Combined with the ability of User Level Instance Blocks it would allow for a more curated and safer experience for all involved.

And yes, it's no secret that in my ideal world there'd just be no federated timelines anywhere. I may not ever get that. In the meantime, there's no reason for federated timelines to be this bad oh my god

Example (caution, crazy flashing) https://dev.glitch.social/web/accounts/745

This is our bug, doesn't happen with mainline (tested on mastodon.xyz)

So I wanted to start an issue for pinned toots and I think there are two approaches we can take to them, but as they have completely different implementations it would be good to have some on-record discussion, yeah? The approaches I see are,,

Traditional pinned toots

AKA what Twitter has. Pawoo has already implemented this, although I'm assuming (?? does anyone know??) that it doesn't federate? But anyway, this one is pretty easy imo, it can be achieved just adding a link field to the user's contact info that links to the pinned toot, and then adding that to the Accounts API. There's a lot you can do with this too: forbidding mentions or links to other toots in pinned toots, for example. It should federate easily and is pretty straightforward.

The downside to this approach is that you are limited to one, or at most a small number, of pinned toots per user.

“Pinned”/“Featured” timelines

Alternatively, we could allow users to “feature” their own toots in a Featured Timeline. We could implement this locally fairly simply by just making the Featured Timeline all of a user's own toots that they have favourited; i.e., when you click the star on your own toot, it gets added to your Featured Timeline.

This would be super cool for like artists and such because they could feature just the posts with their own art (better than media timelines which include art from all sources), and it would allow people to feature toots with variable visibilities that different people can see.

The downside is that, unless I'm mistaken (I might be tbf), favourites don't federate, so the Featured Timeline would only be available locally without significant backend work (i.e., federating favourites that a user has made on their own toots). So we would have to work on that.

It's also a little harder to impose restrictions on what toots you can feature if we're gonna tie it to favouriting. Not impossible though.

Of course we could implement both of these options if we really wanted. But I figured discussion would be good. I want something to happen with this lol 😅

this option would presumably leave the federated timeline be, or have seperate options for the federated timeline and the local timeline.

as both of these have API endpoints, the API must also support this change through throwing a "not allowed" error of sorts.

Add an option in the settings modal to allow switching image thumbnail presentation between the width in tootsuite (from the right edge of the avatar to the right edge of the toot) and the current (full width of the toot box).

they are now aligned to the top and don't really look as they should

The feature wherein a user is given the ability to upload custom emojis (to a predefined limit.) These emojis should be force-prefixed with the user's handle in the form :dynaomi-smileyface: This is similar to how Twitch handles channel emotes where all of a particular channel's emotes are prefixed with a set term, as opposed to how Discord handles them (which suffixes the term with a counting number for each duplicate.)

This in functionality would replicate the functionality present with Discord servers.

Somewhat relates to #3

• Create routing and storage for uploading emojis.
• Write API endpoints for managing emojis.
• Extend status API logic to include emoji metadata (including links to the artifacts)
• Write frontend logic for showing and listing emojis.
• Write (helper) logic to list emojis of people you're following.
• Write frontend logic to disable an emoji per double click
• Write frontend settings (Circa #39) to enable or disable any or all user emojis.
• Create the ability for administrators to create instance-wide emojis.
• Write tests for all of the above (ugh)
• Write docs

right now, emojis are served from the main host as below
https://ephemeral.glitch.social/emoji/1f914.svg

it would be better if it came from the static asset host instead:
https://ephemeral-static.glitch.social/emoji/1f914.svg

(Edited)

Add the option to automatically delete old toots.

Configurable per user and instance-wide (which is used as the default setting for users).

Sub-tasks:

• add it to permanent user settings
• add settings UI to user settings and somewhere in the admin interface
• add a rake task to wipe expired statuses and make the needed effort to federate the deletes

Implementation ideas

• Regularly fetch all users, go through their statuses and delete based on user settings
• Pinned toots might be spared so they stay in existence (after we implement pinning ;)

Also: Emojis ... 🕒, ⌛ 12h ... but that makes the cleaner's job harder

I wanna livetoot gay anime but I don't want a bajillion of my toots cluttering up everyone's timeline when I livetoot gay anime so thread collapsing would be nice. I'm imagining something just like Twitter, I'm revising my earlier fears and saying it can probably be done on the order of O(2n): first reading through the timeline and keeping track of the first and last toots for each conversation_id, and then only displaying those with a [x other toots] or whatever in-between. That's pretty doable I think and only a tiny bit slower than just throwing everything up there. The behind-the-scenes processing is slightly more but bear in mind that the number of elements actually being rendered will be slightly less.

The potentially difficult part is that Mastodon unloads its toots from the DOM when they're not visible to conserve memory, so we'll have to work around that.

If you collapse one post, then disable collapsing posts from the modal, the UI element for collapsing and uncollapsing disappears and all posts are collapsed; with their UI elements totally removed (no fav, etc.). If you click on a post it does expand it and it's only the posts on the screen. Still a weird bug

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

The Back button that displays on top of the right column always takes me back to /web/getting-started, no matter how many intermediate things I've been to. The browser's back functionality works fine though.

To reproduce:

1. Click a status.
2. In the detailed status view that 1 opens on the right, click the user name to open the user's profile.
3. Click the Back button on top of the column.

Expected behavior:
The rightmost column returns to the detailed status view.

Observed behavior:
The rightmost column returns to the getting-started view.

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

I don't wanna make a bunch of issues and milestones lol but these are things that would be nice to have with collapsed toots:

• Basic implementation added in 93c5230 with styling improvements in 4bd7482, 40ecbfd, and 2513d92
• Prevent reblogs from breaking the website via collapsed toots
  • Implemented in 67adbcc
• Update height of toot on collapsing
  • Implemented in 4fe45dd
  • Fixed with respect to reblogs through 36805a3
• Show media as a filtered background on collapsed toots
  • For toots with multiple media attachments, the first would be used
  • For gifv and video, the thumbnail would be used
  • Implemented in efacfec
  • This should be A Setting
  • Setting implemented in 595c6de
• Include a media icon next to the collapse button
  • Implemented in 4bc237f and recolored in ddc6b85
  • (Optional) Also include a number specifying the number of media attachments
    • No number is provided, but photosets are given a different icon in 4bc237f
• Turn off the [Show Less/More] button on collapsed toots Make expanding content warning also expand the toot
  • Implemented in d6e3918
  • Reverted in 6a50e73, which is a better solution
• Click anywhere to expand a toot
  • Implemented for status text in e60f27d and a520b11 with a slight appearance fix in aeff898
  • Implemented for links in 5df7bc3
  • Implemented for header text/avatars in 59503a8
• Make notification toots collapsed-by-default
  • Implemented in c806fef
  • It would be nice if this was A Setting
  • Setting implemented in 595c6de
• Toots don't seem to auto-collapse in Notifications, Conversations, etc (!?)
  • Hopefully fixed by c806fef
• Setting to auto-collapse toots with replies or toots with media or all toots
  • Implemented as an App Setting in 595c6de
• Don't include media when calculating whether or not to collapse a toot, so that artists don't get all their toots auto-collapsed
  • Fixed as a part of ec2daae
• Improve styling of collapsed toots so that links/headers don't look clickable
  • Done for headers in 99889ea, but still needs to be done for links
  • Done for links in bba75c1
• Change the appearance of the "boosted" wrapper to work better with collapsed toots
  • Boosted wrapper placed inside of statuses with bba75c1
• Improve the appearance of collapsed notifications with backgrounds
  • Fixed via better filter in bba75c1
• Revise the background filter on collapsed toots to more closely reflect the filters used elsewhere on the site; for example, on static user pages
  • Done in bba75c1
• Shift+click to collapse a toot
  • Implemented in bba75c1
• 🙅 Rename "uncollapse" to "expand" lol
  • Probably a WONTFIX since Expand/Unexpand is CW terminology
• 🙅 Include a conversation icon next to the collapse button, maybe with the number of toots in the conversation, for replies/threads
  • I don't know if we can give the actual length of the conversation (in a twitter-esque “X replies” manner
  • But we can say how many statuses with that conversation_id we've encountered
  • Probably a WONTFIX in favor of actual collapsed conversations
• 🙅 Button to collapse-all or uncollapse-all toots in a timeline
  • May depend on #27
  • Can be made its own issue probably

the CW and sensitive media features have some inherent flaws in UI and presentation/wording, and this list of proposed changes aims to address those.

NSFW is a term rooted in ableism and sex shaming, implying that sex work isn't work, and that work is the standard

as such, since CW is obviously the better term i would suggest these two feature be rolled into one, the CW feature aims to solve the same problem, but for text content.

this is not to say the ability to tag a post's image content alone, or text content alone, should be lost, and i would suggest this middle ground:

clicking the CW button should open a drop down below the toot box with a check box for "hide text" and "hide image" (only when images are attached, obviously)

since generally, you want both under a CW, these other use cases are smaller in size. by opening the CW drop down, you would hide both by default, and have a field to mark a tag for it. you may argue that this requires people to type the four letters "NSFW" to maintain the current feature, and to combat this i propose that empty content warnings still act like NSFW does now, visually, mark it as "hidden" in general, and display "tag not set" before the show more button

thanks for listening.

lists are an incredibly powerful twitter feature that is often overlooked or ignored by non-power-users

this said, this is in many ways due to the failings of twitter as a platform, and the ways it does not make the feature easy to use, find, or implement into your personal use of the platform.

as such, i will be outlining how to do this better for mastodon, how to make the feature better tooled and better integrated with mastodon itself.

first, the API needs to support it, and to support posting to lists as a group of receivers. the default posting levels should honestly be scrapped, in my opinion, and better implemented.

first, i would propose that we retool the existing "posting levels" into modifiers. the current system could even still be kept, with an opt-in to the more advanced system i am about to lay out. (to avoid the "cockpit effect" i have heard of several times, for newer users) let me elaborate on how to better re-tool the current system.

MODIFIERS
the better way to implement the system we are currently using, while simultaneously providing for more advanced usage of the posting mechanism (lists, for example) is to rework the system into modifiers and list-targets. obviously, the default list-target would be your followers. after the modifiers, i will elaborate on how to handle non-followers and lists.

1. "post to public timeline"
   this modifier is comparable to the unlisted option, and it does not limit people who choose to look at you from seeing them, or boosting them. i would personally argue, if there were not pre-existing opinions on what the 'default' is, through existing code, that this should be an OPPOSITE modifier, namely "post to public timelines" as this would fit better in with the semantics of lists API side.

2. "can not be boosted"
   to many users, this is different from private posts, and i suggested they be different way back before they were implemented. this would also not disallow the post from being posted to the public timeline. i can already see the arguments against this, so i shall counterpoint them before they come. "what if an instance doesn't respect this setting" rather than say that this is avoidable, as many people argue it is currently unavoidable, i would suggest a more transparent way for users to understand what happened when such a "failstate" as many would see it, occurs. namely, something along the lines of "oops! x boosted your toot, their instance does not support this tag for posts. try petitioning them to add support, or block them if it is harmful to you for toots to be boosted" some might argue that blocking is a bit extreme, but i personally believe people have every right to block people for whatever reason, and it instantly resolves the issue, and is thus something to be considered and chosen by the user. furthermore, the words block and petition would hotlink to a yes/no are you sure prompt, and a "compose new toot" action, mentioning the owner of the instance in question. (should it be an instance this can easily be done for)
   i would also propose one change that might be considered unusual to this feature: the creator of the toot can boost the post

3. "only visible to [list]"
   this is the equivalent of the current method of private toots, in addition to "can not be boosted". the change here, is that this is now changed to work with lists as a feature. i am yet unsure if this modifier should automatically include the second modifier, but instinctively i would lean toward yes.

4. "do not federate"
   hey it's time for a new one! this is a long-requested feature, and it can be used in tandem with any of the above modifiers, or with no other modifiers to post a local-timeline-only post.

LISTS
now we get to the meat of it. lists are the ability to post to a subset of users. there are two usages of lists, both of which i will get into in detail.

first: to better organize people you are already following, or who are already following you into more manageable subsets of said users.
second: to keep someone out of your home timeline.

now, this gets tricky with the implementation of private and public lists. public lists can be viewed by anyone, private lists are just the user who created it. the difficulty here is one of abuse, namely, not everyone wants to be in a list, and as such there needs to be better ways to opt-out.

i suggest a system with several layers to remedy this. namely, private lists will always be treated the same as following someone, down to the level that if you have added someone you do not follow to a list, they will be added to your following list that is displayed to others. this requires a more flexible understanding of following. following someone would drop down a list of private lists if you have them, and allow you to (instead of adding them to your home timeline) add them to a list.

this makes the home timeline very simple! it is now a list that when you follow someone, is the default place to put someone. you can add/remove them from other lists, or only follow them via another list, and suddenly the following system makes much more sense.

alright, private lists are out of the way.
"wait, what about harassment!" private lists are inherently solved via the existing follow system being extrapolated into this list format. namely, vetting follow requests already exists. private lists are not publically shared, so they are essentially the equivalent of following someone normally. this means, for private lists, they will merely need to use the retooled following mechanics, the retooled vetting of follower requests. already taken care of.

public lists are a different story. since anyone can view them, it would need a separate mechanism, to better enable the user to understand the consequences of allowing yourself to be placed on that list. a public list can be viewed or followed by anyone, and is treated the same way private lists are when it comes to "posting to"

here's how the list mechanic would work, when it comes to making a new post. you can distribute to all your followers by default, and in addition to this, any lists you have created (thus allowing subsets of your own followers) and any public lists you have allowed yourself to be added to, can be selected in addition to or instead of your full list of followers.

it is worth noting that all of these changes require the existing feature of default-posting-levels to be retooled as well, so that modifiers can be chosen for your default posting level.

there's another thing i haven't mentioned, which is arguably it's own feature, and that's the option to follow everyone in a list. this would be an option for anyone who views a public list to add everyone into the list to any of their own lists.

EDIT: public lists should allow users in a public lists to remove themself from the list at any time.
EDIT 2: blocking should remove from all private lists as well. the wording of the warning when allowing yourself to be added to a public list should suggest follow vetting be turned on if they do not personally want just anybody to be following them.
EDIT 3: WHEN someone tries to follow you by adding you to a private list, it should say it as such in follow request/notification "X followed you via private list", and when someone adds someone they followed normally, it should say "X added to/removed from a private list" to better allow transparency and allow users who have reason to be wary of harassment/plants and the like to know "hey maybe i should double check that this person isn't malicious"
EDIT 4: this also makes mutuals only a really easy list to be able to be posted to, another highly requested feature.

I believe we could bring it back, unless I misunderstand the reasons for reverting it.

This was introduced here: mastodon#552 (commit: Nyoho@32a0e31)

Then someone found inconsistency in the implementation (mastodon#2610) and Eugen axed it in mastodon#2970 (mastodon@7a0f4df)

Oddly, the revert doesn't have its own commit and isn't mentioned in the commit message.

This could be optional via the config modal