• Fix bug where expanding/collapsing the post image would trigger unwanted reactivity causing the comment section to refresh.
• Comments now respond to the "lockPost" event in order to disable/enable the reply button appropriately.
• If an inbox item is expanded, switching accounts or refreshing the list as a new item arrives would keep the text from the previous comment while updating the heading info correctly. Caused the wrong comment/reply to be displayed.
• Same as above but for moderation reports
• Don't invalidate/refresh Reports page when resolving a report (not needed).
• When removing a post/comment, if you enabled the option to send a reply message and left it blank, it would throw a toast message informing you as such but not reset the "loading" variable and kept the "submit" button disabled.
• When distinghishing a mod comment, only push top-level comments to the top of the tree. e.g. if you need to distinguish a comment that is a reply to another comment, that would previously push a copy of that distinguished reply up as a top-level comment.
• Fixed unhandled error when an admin enters the community settings when there are no moderators.
• Fixed "Local Community" toggle not reflecting API state after reload.
• Fix truncation in post headings to account for community display names where the community creator thinks "Display Name" and "Community Long Description" are the same picture :sigh:
  • Note: Backported to 1.4.38
• Svelte was URI-encoding ampersands when rendering links
• The absolute time displayed in the tooltip of the RelativeTime component was not updating correctly when re-rendering due to a reacctive event.
• If you linked an image in markdown, the image would render but without the link. Now, the link will be below the image.
  • e.g. [![This is a linked image](https://foo.com/image.jpg)](https://example.com/article/page.htm)
  • The cause is that zoomable image takes precedence over the hyperlink.
  • Known "bug": Badges (e.g. img.shields.io are still kind of ugly and don't really fit the model. Working on some exceptions for things like those, but that didn't make it into this release.

The filtering subsystem has been refactored and enhanced. Prior to this release, anything that was filtered was simply discarded before being rendered.

Now, filtered objects will show a placeholder that indicates which filter was triggered (or which keywords triggered the filter). Clicking the "eye" button on the placeholder will show the hidden content.

This is the case for both posts and comments that are hidden by your filter preferences.

Notes on Filtering

There are a few safety checks in place that will disable the filters under certain conditions. The first two are to prevent moderation blind spots, and the rest are just sanity checks/compromises to keep from over-complicating things.

1. If you are a moderator, the filters will not apply to content posted to any community you moderate. This includes viewing reports.
2. If you are an instance admin, the filters will not apply to content posted to any local communities.
3. The filters will not apply when viewing your own content anywhere in the app.
4. Filters are not applied when viewing someone's profile.
5. If you have a community filtered, going to its /c/ page or browsing it in a modal will show the community's content, though any other filters are still applied (keywords, user filters, etc). Reason being, you went to the commmunity, so the content shouldn't be filtered out by default.

Finally, filters are global and apply to all accounts in use in the app. You cannot have different filters on one account than on another. I may change my mind at some point, but it made much more sense to have one set than one set per profile. It also eliminates the need to have extra management tools to copy them or sync them between profiles and other things like that.

Keyword filters now apply to comments! I had always meant to apply them there, but until the work done to the comment section in this release, I didn't have a way to apply them that wouldn't nuke the rest of the thread. Now, just the offending comments will be hidden with the rest of the chain remaining intact.

Filtered comments will hide the score and creator as well. Unless manually revealed, the "creator" will be [email protected] with the Tesseract logo as the avatar. Revealing the comment will replace that with the actual creator. This is to both further hide/mask content you don't want to see as well as keep the formatting/rendering consistent.

You can now filter users rather than blocking them. This is especially helpful for those who moderate large communities. Think of filtering out a user like a "soft block".

Why would you want to filter a user rather than block them?

Lemmy's blocking has a couple of glaring issues:

1. Content from blocked accounts does not show up in communities you moderate. This leaves a huge blind spot when you don't want to see content from certain users but it is not warranted to ban them from your communities.

2. When you block a user, not only are their comments not visible in the comment section, you will not see any replies to them, either. Depending on who you block, this could cause you to miss out on quite a bit of discussion.

If you filter those users instead, both of those are addressed:

1. Filters are automatically disabled on communities you moderate, so you will still see content from the filtered users there but you won't anywhere else.

2. Only the filtered user's comment will be masked; all the replies will be visible.

Why would you want to do this instead of block the community?

Think of it like a soft unsubscribe. Need a break from a community but don't want to unsubscribe completely? Filter it! You'll see a placeholder stub in the feed for it, and you can reveal if you want to. Otherwise, it's out of sight, out of mind. When you're ready to get back into the community, just un-filter it.

Communities work the same way except from the community profile modals.

You can also manage the filtered users directly from Settings->Filters->User Filters. Be aware that is pretty low-level, and you're basically editing a list of actor IDs. It's best to only use that to remove items, though you can add them there as well. It will also accept a comma-delimited list of actor IDs, so you can add them in bulk:

e.g.

https://instance.xyz/u/jerk1, https://instance.xyz/u/jerk2, https://other-instance.abc/u/AnotherJerk

Again, the users you enter directly must be in the actor ID format as that is what's compared when running the filters. An incorrectly formatted entry will not break anything, but it won't work, either.

• Added color-coded conversation lines to comment threads.

  • The conversaton lines are clickable buttons and can be used to collapse/expand threads.
  • The user avatars in the comment header have ring borders corresponding to the thread color
  • Avatars are now de-coupled from the user links; clicking them will expand/collapse the thread
  • Are color-coded by default but can change to monochrome if you prefer.
  • Setting is in Settings -> Posts and Comments -> Color Coded Conversation Lines

• Tweaked comment renderers / layout

  • Removed "card" effect
  • Distinguished comments now render fancier.

• Comment text height can be limited to 120px and be expanded/collapsed (similar to post bodies in the feed).

  • Disabled by default
  • Can enable via Settings -> Posts and Comments -> Limit Comment Height

• When removing a post/comment and opting to reply with a reason via comment, automatically distinguish the comment.
• In the Community Profile Modal -> Ban/Unban User panel, you can now search for a user as well as enter the actor ID, @[email protected], or https://lemmyverse.link/u/[email protected] format.
• Added a quick shortcut to "Moderator View" in the sidebar. Will not show unless the current account is moderating at least one community (e.g. if you're an admin that isn't explicitly a moderator of any community, it will be hidden).
• Added a button on reports that will copy the report text to the clipboard if you want to use it in the removal reason.

• Added button to view user's modlog history in the full modlog (without having to open the embededded, mini-modlog first.
• Both can be middle-clicked to open the full modlog in a new tab on desktop
• Added "View in Full Modlog" button to User Profile Modal -> User Modlog panel (Thought I already had this, but it was in the moderation modal)
• Added button to filter (or un-filter) users or communities.

• Clicking the "hand" icon will now load the modlog details for the comment even if you have the setting disabled. If the setting is enabled, then it will take you to the full modlog for the entry.
• Moved comment removal reason box above the comment text.

Gave the modlog a slight visual and functional refresh

• Can now +/- quick filter by action type
• More consistent and uniform layout
• Removed redundant components
• Moved filter options out of sub-navbar and into page proper
• Cleaner mobile/desktop reflow
• Can switch between relative timestamps (1 hr ago) and absolute timestamps for modlog events

Additionally, it can now lookup the moderatee on "remove post" action types. The API very stupidly doesn't include the person details on the "Remove Post" (or lock post) events, so Tesseract can optionally/automatically perform a lookup based on the post's creator ID if you have that option toggled on.

Note that an API-lookup is a "last resort". In the modlog loader, it will attempt to resolve the creator_id by looking at other entries in the batch of modlog entries it retrieves. If it finds a person object matching that id, it will add it transparently and not trigger an API-lookup. The API lookups are also cached for 5 minutes (too short, and they're not useful, too long, and ban indicators may not show when they should). Attempting to resolve those in the loader, synchronously, caused too much delay in loading the page, so they fill in dynamically/asynchronously after the modlog renders.

Filtering Revamp

The filtering subsystem has been refactored and enhanced. Prior to this release, anything that was filtered was simply discarded before being rendered.

Now, filtered objects will show a placeholder that indicates which filter was triggered (or which keywords triggered the filter). Clicking the "eye" button on the placeholder will show the hidden content.

This is the case for both posts and comments that are hidden by your filter preferences.

Notes on Filtering

There are a few safety checks in place that will disable the filters under certain conditions. The first two are to prevent moderation blind spots, and the rest are just sanity checks/compromises to keep from over-complicating things.

1. If you are a moderator, the filters will not apply to content posted to any community you moderate. This includes viewing reports.
2. If you are an instance admin, the filters will not apply to content posted to any local communities.
3. The filters will not apply when viewing your own content anywhere in the app.
4. Filters are not applied when viewing someone's profile.
5. If you have a community filtered, going to its /c/ page or browsing it in a modal will show the community's content, though any other filters are still applied (keywords, user filters, etc). Reason being, you went to the commmunity, so the content shouldn't be filtered out by default.

Finally, filters are global and apply to all accounts in use in the app. You cannot have different filters on one account than on another. I may change my mind at some point, but it made much more sense to have one set than one set per profile. It also eliminates the need to have extra management tools to copy them or sync them between profiles and other things like that.

Keyword Filters Now Apply to Comments

Keyword filters now apply to comments! I had always meant to apply them there, but until the work done to the comment section in this release, I didn't have a way to apply them that wouldn't nuke the rest of the thread. Now, just the offending comments will be hidden with the rest of the chain remaining intact.

Filtered comments will hide the score and creator as well. Unless manually revealed, the "creator" will be [email protected] with the Tesseract logo as the avatar. Revealing the comment will replace that with the actual creator. This is to both further hide/mask content you don't want to see as well as keep the formatting/rendering consistent.

Additional Filtering Options

There are a few new filters available as of this release:

Hide Content from Blank Profiles

A "blank profile" is one that lacks both a bio and an avatar. Why? Sometimes you might want to filter out "faceless opinions" for a while and/or only deal with the people who are more likely to be here for the community rather than anonymous opinion shouting.

Filter Users (Soft Blocking)

You can now filter users rather than blocking them. This is especially helpful for those who moderate large communities. Think of filtering out a user like a "soft block".

Why would you want to filter a user rather than block them?

Lemmy's blocking has a couple of glaring issues:

1. Content from blocked accounts does not show up in communities you moderate. This leaves a huge blind spot when you don't want to see content from certain users but it is not warranted to ban them from your communities.

2. When you block a user, not only are their comments not visible in the comment section, you will not see any replies to them, either. Depending on who you block, this could cause you to miss out on quite a bit of discussion.

If you filter those users instead, both of those are addressed:

1. Filters are automatically disabled on communities you moderate, so you will still see content from the filtered users there but you won't anywhere else.

2. Only the filtered user's comment will be masked; all the replies will be visible.

How to Use:

To filter (or un-filter) a user, click their username to bring up the User Profile Modal. From there, use the "Filter User..." (or Un-Filter User...) button in the modal. When a user is filtered, all of their content in the current area will collapse to a placeholder (or un-collapse if you're un-filtering them).

You can also manage the filtered users direclty from Settings->Filters->User Filters. Be aware that is pretty low-level, and you're basically editing a list of actor IDs. It's best to only use that to remove items, though you can add them there as well. It will also accept a comma-delimited list of actor IDs, so you can add them in bulk:

e.g.

https://instance.xyz/u/jerk1, https://instance.xyz/u/jerk2, https://other-instance.abc/u/AnotherJerk

Again, the users you enter directly must be in the actor ID format as that is what's compared when running the filters. An incorrectly formatted entry will not break anything, but it won't work, either.

Filter Communities (Soft Block Communities)

Similar to users, you can also filter/soft block communities.

Why would you want to do this instead of block the community?

Think of it like a soft unsubscribe. Need a break from a community but don't want to unsubscribe completely? Filter it! You'll see a placeholder stub in the feed for it, and you can reveal if you want to. Otherwise, it's out of sight, out of mind. When you're ready to get back into the community, just un-filter it.

The process is the same as with filtering a user, except it's accessed from the Community modal (click any community link in the app).

Reactivity

• Fix bug where expanding/collapsing the post image would trigger unwanted reactivity causing the comment section to refresh.

• Comments now respond to the "lockPost" event in order to disable/enable the reply button appropriately.

• If an inbox item is expanded, switching accounts or refreshing the list as a new item arrives would keep the text from the previous comment while updating the heading info correctly. Caused the wrong comment/reply to be displayed.

Moderation

• Don't invalidate/refresh Reports page when resolving a report (not needed).

• When removing a post/comment, if you enabled the option to send a reply message and left it blank, it would throw a toast message informing you as such but not reset the "loading" variable and kept the "submit" button disabled.

• When distinghishing a mod comment, only push top-level comments to the top of the tree. e.g. if you need to distinguish a comment that is a reply to another comment, that would previously push a copy of that distinguished reply up as a top-level comment.

Community Settings Section

• Fixed unhandled error when an admin enters the community settings when there are no moderators.

• Fixed "Local Community" toggle not reflecting API state after reload.

Misc

• [Display] Fix truncation in post headings to account for community display names where the community creator thinks "Display Name" and "Community Long Description" are the same picture :sigh:

  • Note: Backported to 1.4.38

• [Annoyance] Svelte was URI-encoding ampersands when rendering links

• [Time Display] The absolute time displayed in the tooltip of the RelativeTime component was not updating correctly when re-rendering due to a reacctive event.

Comments

• Added color-coded conversation lines to comment threads.

  • The conversaton lines are clickable buttons and can be used to collapse/expand threads.
  • The user avatars in the comment header have ring borders corresponding to the thread color
  • Avatars are now de-coupled from the user links; clicking them will expand/collapse the thread
  • Are color-coded by default but can change to monochrome if you prefer.
  • Setting is in Settings -> Posts and Comments -> Color Coded Conversation Lines

• Tweaked comment renderers / layout

  • Removed "card" effect
  • Distinguished comments now render fancier.

• Comment text height can be limited to 120px and be expanded/collapsed (similar to post bodies in the feed).

  • Disabled by default
  • Can enable via Settings -> Posts and Comments -> Limit Comment Height

Moderation

• When removing a post/comment and opting to reply with a reason via comment, automatically distinguish the comment.

• In the Community Profile Modal -> Ban/Unban User panel, you can now search for a user as well as enter the actor ID, @[email protected], or https://lemmyverse.link/u/[email protected] format.

• Added a quick shortcut to "Moderator View" in the sidebar. Will not show unless the current account is moderating at least one community (e.g. if you're an admin that isn't explicitly a moderator of any community, it will be hidden).

• Added a button on reports that will copy the report text to the clipboard if you want to use it in the removal reason.

User and Community Profile Modals

• Added button to view user's modlog history in the full modlog (without having to open the embededded, mini-modlog first.

• Both can be middle-clicked to open the full modlog in a new tab on desktop

• Added "View in Full Modlog" button to User Profile Modal -> User Modlog panel (Thought I already had this, but it was in the moderation modal)

Inline Comment Removal Reasons

• Clicking the "hand" icon will now load the modlog details for the comment even if you have the setting disabled. If the setting is enabled, then it will take you to the full modlog for the entry.

• Move comment removal reason box above the comment text.

Gave the modlog a slight visual and functional refresh

• Can now +/- quick filter by action type
• More consistent and uniform layout
• Removed redundant components
• Moved filter options out of sub-navbar and into page proper
• Cleaner mobile/desktop reflow
• Can switch between relative timestamps (1 hr ago) and absolute timestamps for modlog events

Additionally, it can now lookup the moderatee on "remove post" action types. The API very stupidly doesn't include the person details on the "Remove Post" (or lock post) events, so Tesseract can optionally/automatically perform a lookup based on the post's creator ID if you have that option toggled on.

Note that an API-lookup is a "last resort". In the modlog loader, it will attempt to resolve the creator_id by looking at other entries in the batch of modlog entries it retrieves. If it finds a person object matching that id, it will add it transparently and not trigger an API-lookup. The API lookups are also cached for 5 minutes (too short, and they're not useful, too long, and ban indicators may not show when they should). Attempting to resolve those in the loader, synchronously, caused too much delay in loading the page, so they fill in dynamically/asynchronously after the modlog renders.

However, I should be releasing 1.4.33 with some small bugfixes soon.

All the pan/zoom libraries I tried suuuuuuucked, so I ended up rolling my own from scratch. The pinch zoom isn't quite where I want it, but it's a start. If anyone wants to contribute some code for improving that, please let me know.

• Support zoom, pan, and rotate
  • Mouse scroll to zoom
  • Click/grab to pan
  • Rotate via on-screen buttons
  • Double-click to quick zoom in/out by 2x
• Gesture support
  • Pinch zoom in/out
  • Swipe up to zoom in
  • Swipe down to zoom out
  • Swipe left or right to close the zoom modal
  • Other gestures may be added once I figure out a clean way to differentiate them from conflicting mouse events

That said, I do like waving things (and people) away.

To that end, I've added some gesture recognition in a few places, mostly modals. Any modal can now be dismissed with a left or right swipe in an area not bound by other event handlers.

• e.g. You can't swipe in the text field to dismiss an edit/report/ban/remove modal; you have to swipe outside of that.
• Left/right swipe was chosen as to not interfere with scrolling so it could be used consistently across all modal types.

The only other place, currently, with gesture support is the image zoom modal (described above).

I may add some additional swipe actions where it's intuitive to do so. For now, I'm content with modals being easier to dismiss on mobile without having to reach up to the close button in the top corner.

Actions include:

• Go to profile
• Message in Lemmy / Matrix
• Block User
• Search for alts / simiarly-named accounts
• Ban user from instance (admins only)
• View user on their home instance
• Copy Lemmyverse link for user

• Images can be pasted in the post's URL field as well as in the markdown editor.
• Images can optionally be pre-processed to webP along with a user-selectable quality level. Especially useful if your instance limits the size of uploads
• Can delete post images (only before you save the post; unfortunately there's no way to retrieve the delete token after that even though it is stored in the DB. Yet another API limitation :sigh:)
  • This is addressed in 0.19.4, but I don't have support for that yet.
• Images pasted/uploaded into the markdown editor are tracked in a bar along the bottom of the editor. Individual images can be deleted as needed along with the corresponding markdown code for them.

This setting behaves differently for mods and admins:

• Mods: Filter will be applied to all posts/comments except in communities of which you are a moderator.
• Admins: Filter will be applied to all posts/coments except those made to communities local to your instance or those made to remote communities of which you are a moderator.

Comments made by new users will be hidden, and that includes any replies (essentially behaves the same way as blocked users)

This information has also been added to the instance items at /instances

Please note that the "Activities behind" counter is only an estimate. The value for newest_activity_id is not provided by the API (because that would be useful, so why would the Lemmy devs include it?), so it has to be estimated. The estimation is done by looking at the last_successful_id of all the linked instances and grabbing the highest number and subtracting the last_successful_id for the selected instance. Not all of those activities would necessarily be coming to your instance (votes/posts/comments to communities yours isn't subscribed to, etc), so it is merely an estimation. Just because it shows you are behind by X number doesn't necessarily mean it's behind by that many.

When loading a video via click-to-play, I'm conditionally setting the "autoplay" flag where the embed API supports it, but it doesn't always seem to be honored. This is an attempt to not have to press "play" twice for a video. So far, the only video frontend that seems to honor it is YouTube. Invidious/Piped, so far, do not, and neither does PeerTube.

Ok, so autoplay works if muted (no idea how YouTube's player gets around this; probably some chicanery). I think that's worse because you still have to click twice on the videos, and the "unmute" button is harder to reach than "play". So I think I'm going to just settle on having to click play twice.

This seems to be be a Chrome/Chromium thing (and explains why YT gets to bypass this). In Firefox, the autoplay flag is respected without having to mute the video.

If media embeds are enabed in the feed, only YouTube frontend will show direct embeds. Piped/Invidious will always be click to play regardless of embed setting due to above mentioned rate limiting / performance.

• On posts with links, it currently has buttons to search for the article at Archive Today, Ghost Archive, and 12ft.io
• On Youtube-like posts, can select alternalte links for YouTube, Invidious, or Piped
  • Invidious/Piped will open with your preferred instance (defined in settings)
  • Useful if someone posts a video to an Invidious instance that performs poorly for you and you would prefer to view it on your preferred Invidious/Piped instance or canonically on YouTube.

• Main, Community, and User feed pages: Quick Actions has replaced all discrete menus
• Search Page, Modlog, instances page, and Community Browser: All of the filtering options are in a quick action menu

These will be combined with the built-in list and the admin-extended list and be available for use as your preferred YT frontend and for detection of Piped/Invidious links in posts.

Be aware that those custom instances will only render as embeds for you; they will be thumbnails for anyone else who hasn't added them to Tesseract. If you feel that instance should be added to Tesseract's built-in list, please submit a Github issue with the details.

Tesseract is pre-populated with the official list of public instances for each, but it can get out of date easily.

Note: As of 6/20/2024, I've noticed a lot of Invidious/Piped instances are now requiring login, and embeds through them no longer work. I believe if you have an account with one, log in, and enable 3rd party cookies for that domain, the embeds should work. I have not tried that, but it does work with Spotify. This isn't a Tesseract bug, unfortunately, or I'd fix it.

• Or, more specifically, removed 0.18.x JS client and the extensions I wrote to make that compatible with 0.19.x. Now uses the 0.19.3 JS client.
• Removed the image upload proxy which was needed in 0.18x due to CORS restrictions.

• Added safety check so that the auth token is only ever sent to the profile's associated instance and cannot accidentally send to non-home instance (e.g. when browsing communities on a remote instance).
• Fixed a few chicken/egg situations where the profile store needed to be accessed before it was initialized
• If your auth token is invalid, such as after changing your password on another device, you will get a toast message you can click to take you to the login screen.
• If a profile exists for a username/instance combo, logging in will update the auth token for that existing profile rather than creating a new one.
• User avatars are now fetched when logging in.

• Embeds now have a short timeout when leaving the viewport before they're removed from the DOM and turn back into thumbnails. Fixes annoyance when resizing the window while a video is playing and the video temporarily leaves the viewport and is destroyed. Timeout is 2 seconds and will reset/disarm if the post returns to the viewport before it expires.

• Uses new upload handler for banner/icon
• Can pre-process the banner/icon to webP before uploading
• Shows a live preview of how the community card will look

• Slightly darkened background color in light mode cards (bg-white->bg-slate-100) for better contrast. Did similarly for some button colors
• Added "OpenDyslexic" as a UI font option
• Can now close modals with Escape key, close button, or by swiping left/right
• Added button to reveal password fields
• Some modals can be closed by clicking out of them.
  • I need to disable this or make it more consistent. Some workflows utilize nested modals, so I do need to be able to keep them open when interacting with a child modal.
• Added "share" link for searches.
  • Will generate a URL with the current search params and copy to your clipboard.