This has been an omission for as long as Tesseract has existed, and I’m happy to finally have language configuration and selection added to this version.

Users

• You can now manage your discussion languages in your profile settings. The available languages are limited to those set at the server level. e.g. If your instance only allow English, French, and Spanish, those are the only three that will be available to select.
• You can now define the language when creating/editing posts and comments
• The allowed languages for a community are now shown in the sidebar.
  • Note: Only on the community page. When on a post page with the community sidebar, the allowed languages are not available from the API without doing a separate call which is inefficient.
• The site’s configured languages are now available in the site sidebar

Mods

• You can now set the allowed languages in the community settings. As with the user’s languages, the list of available languages is limited to only those enabled by the site admins.

Admins

• The site-level discussion languages can now be configured from the admin panel at Admin->Languages

You can now add an arbitrary number of tags to any user. Tags are limited to 25 characters and can also be used with the filter policies explained below.

Community Grouping

This feature has existed for a while, but it got a facelift in this release. You can now select icons, search for groups, and there’s better integration with the rest of the application.

Additionally, groups can have filter policies attached to them which gives you really fine-grained control over the content you see in them.

The filtering subsystem has been completely re-written and is much more granular and much more powerful. There are now two levels you can filter: globally and per community group.

Previously, the terms “filter” and “hide” were used interchangeably, but in this release, “filter” means the content is still visible but collapsed into a stub you can expand to see. “Hide” means the UI will not show it at all. Additionally, you can use these without being logged in. So if you want to browse as a guest, you can tailor your experience just the same as you could if you were logged in.

Global filters apply to everything. Use these for things, people, keywords, domains, instances, or platforms that you never, ever want to see.

Community group filtering has the same options as global filtering, but those are only applied to communities that are members of the group you’ve defined.

Filtering Mechanisms

1. Filter and/or hide accounts by minimum age
2. Filter and/or hide bot accounts
3. Filter and/or hide posts you’ve downvoted
4. Filter and/or hide NSFW posts
5. Filter and/or hide NSFW communities
6. Hide removed comments in the comment section
7. Filter and/or hide your deleted items (in the feed and profile)
8. Filter and/or hide posts with a negative score (threshold is configurable from -1 to -30)
9. Filter and/or hide content from users that have specific tags
10. Filter and/or hide users. Users can be added to the policy directly, by regex pattern, and/or by instance
11. Filter and/or hide communities. Communities can be added to the policy directly, by regex pattern, and/or by instance
12. Filter and/or hide content by keyword. Keywords are evaluated as regex patterns, so you can get really granular here.
13. Filter and/or hide content by instance or platform. Hide all content from specific instances or even entire platforms such as Mastodon.
14. Filter and/or hide posts that link to specific domains. Domains can be wildcards such as *.example.com and there are quick toggles for common domains that have multiple records such as Bluesky, Facebook, Reddit, Twitter/X, and YouTube.
15. Filter and/or hide content that is not flagged with the specified languages. This is most useful at the community group level as it allows you to limit content in those groups to a specific subset of the languages selected in your profile.
16. Add users, user regex patterns, communities, and/or community regex patterns to a list of exceptions where the policy rules are ignored.

Notes:

1. If you’ve opted to hide things in the policy, then any inbox item that the policy flags (post/comment reply, mention, and/or DM) will be hidden and won’t trigger the notification indicator. You can/will still see those in other clients as they won’t hide them, and if you’re sending notifications to email, they will still come through. The filtering is only within the Tesseract UI.
2. Filtering works a little differently for mods and admins. See the “Mod/Admin Tools” section below for details.

Example Usage of User Tags, Community Groups, and Filter Policies

Making a (mostly) politics-free meme experience

1. Add your meme communities to a group and enable the option in the group to use it as a filter group
2. Populate the keyword list in the policy with all the hot-button words that apply
3. Add specific users to the policy that only ever seem to post politics. If they use several alts with the same name on different instances, use a regex instead.
4. Tag users who are “always on” and can’t seem to help themselves from injecting politics into everything
5. Add the “always on” tag to the policy
6. If everyone from the instance example.com is preachy in the meme communities, add example.com to the policy under the “Instances” tab.
7. Enjoy a better feed :)

Saw mentions of this font going around, checked it out, and I like it. It seems to be designed for visually impaired, but it also helps dyslexics such as myself without being as wonky-looking as OpenDyslexic (no offense to OD’s creators).

This is also the new default font for the application.

Community and user cards will indicate if the community’s home instance is defederated from your instance. The create post and other action buttons will also be disabled.

When blind voting is enabled, scores will be hidden until you’ve cast a vote. This encourages you to both vote/participate as well as to vote based on the content without being influenced by the current score. While I’m not naive enough to think this will competely prevent dogpiling and bandwagon voting, it is a step in the right direction for those who choose to enable this option.

Blind voting only applies for logged-in users. Browsing as a guest will still show the scores since there is no ability to vote.

You can now mute replies on up to 25 posts. The option is available from the post action menu (three dots at top of post). Any replies to those posts will be silently marked as read and not included in the notifications. You will still see those replies in the inbox, but they’ll be marked as read leaving your “unread” inbox clean for replies you are interested in. Muted posts have a “Muted” badge in the title to indicate that reply notifications will be discarded.

This also applies to comments on the muted post. For example, if you comment under your own post and then mute replies to that post, any replies to your comment will also be muted.

Behavior

• If it is your own post, you will not receive notifications for any replies to the post while it is muted.
• If it is someone else’s post, you will not receive notifications for any replies to your comments to that post

It was requested to add a LemVotes link to posts/comments. I was initially against it, and still am, but decided “what the hell?” and added it anyway.

Post and comment action menus now have a “See Votes” option that will search for the item at lemvotes.org.

Since this is an external service, the only guarantee I can make is that the correct AP ID is being sent. Whether it finds the content or is working is out of my control.

Note: Right now, it loads in a modal in an iframe. If that tool ever changes to prohibit embeddng in an iframe, it will have to be turned into an external link.

Banning/Unbanning Multiple Communities

In the previous releases, you could only ban a user from a single community or all communities. This is now more granular, and you can select individual communities for the actions. The expiry, remove content option, and reason are used for all actions as before.

Local User Management

In Admin -> Local Users you can now list your instance’s users. Since this is limited to what I can do with the /api/v3/search endpoint, the only sorting opitons are Old and New. You can also search for a local user from within this section.

Use Cases

• Keep an eye on new signups. It will show the number of posts and/or comments they’ve made
• Take action against or interact with an account. Clicking their username will open the User Profile Modal for their account giving access to various tools.
• Check the status of any local account

Send a Welcome Message During Registration Approvals

You can now opt to send a welcome message via DM to newly approved accounts as part of the application approval process. Send a “welcome aboard” message, a getting started guide, or anything you feel might help new users get up and going with their account.

A default welcome message can be configured in Settings -> Moderation -> Welcome Message (similar to a default registration denial message). There’s a button on the welcome message field in the application approval screen to populate it with this canned message.

Search for Alts in the Registration Application Menu is Now Localized

Rather than the “Search for Alts” button taking you to the search page in the previous releases, it now loads in a modal so you do not have to leave the application page.

Additionally, you can click on any alt from the results to load that alt’s user profile modal in order to check post/comment history or modlog history. Very useful for vetting new accounts before you approve the application and doesn’t require leaving the application workflow.

Set Site Content Warning

Both the field to set the content warning contents and a method of displaying it were both missing in prior releases.

As of 1.5.0, if any text is saved to the “Content Warning” field, then a modal will appear for all users the first time they visit the site. The modal will be shown in place of the UI until the visitor acknowledges it.

Defederate (or Re-Federate) Instances from the Instances Page

Rather than manually putting instance domains into the admin panel, admins will see a “Defederate” or “Re-Federate” button on instances listed on the /instances page.

LemVotes User Histories

Admins have the option to see a user’s history at LemVotes. This is useful for identifying suspected manipulation accounts which have been more prevalent lately.

Notes on Filtering Behavior

The filters behave differently for mods and admins in order to prevent blind spots. As such, some capabilities are reduced or disabled depending on your account role and where the content is posted. “Posted” here means either a post or a comment.

Mods

All filtering is bypassed in communities you moderate. If content is posted to a community you moderate, it will be neither filtered nor hidden. If you want to stop seeing content from specific users, you will need to ban them from the community. If you want to avoid specific topics, you will need to make a rule against it and enforce it.

Admins

There are two types of admins the filter subsystem handles, local admin and remote admin, and the behavior differs depending on which applies to a given submission.

Local Admin: A local admin is defined as an admin account that is on the same instance as the submission. e.g. If you are an admin of example.com, then any content posted to a community that resides on example.com will treat you as a local admin as far as filter processing is concerned.

For local admins, filters are bypassed for content in any local community, and items will not collapse into a stub nor be hidden. Content from remote instances, however, can be filtered (collapsed to a stub) but NOT hidden.

Remote Admin: A remote admin is defined as an admin of one instance while the content comes from another. e.g. If you are an admin at example.com and the content is federated from foo.com.

For remote admins, content from federated communities can be filtered (collapsed into a stub) but NOT hidden. The reason for this is that admins should have full visibility of content they are platforming, and if they don’t want that content, they should remove it. Admins are responsible for their instances and what (and who) they platform, so the filtering system will not hide anything from them.

These distinctions and limits on the filtering behavior are intended to prevent moderation blind spots. If you want to browse your instance while being able to fully utilize the filters, you will need to do so from an unprivileged alt.