While I anticipated this, it doesn’t make it any less tedious.
Now that the core filtering subsystem is more or less where I want it and applied to all the main spots (still fine tuning as I go, but that’s easy), I’m finding that filtering needs to be applied in a LOT more places than I originally planned.
For example, if you’re filtering instance.xyz or have blocked instance.xyz, then you probably don’t want communities from those instances showing up in search results or the community auto-complete search boxes or other places. Same thing for blocked/filtered users in search results, etc. Even in the modlog, you probably don’t care about entries to/from instances you’ve filtered/blocked.
There’s way more than those examples, but that’s where I’m at: going though and applying the filter preferences in all the various nooks and crannies.
I’ve also yet to start re-implementing user-tagging. I have a bad habit of doing a lot of things at once, but I’m forcing myself this time to complete one major feature before starting another.
What’s New Since the Last Check-in?
-
More bugfixes
-
Finally (properly) fixed Bug 42 where non-Fediverse links that have
/u/{name},/c/{name},/comment/{number}, and/or/post/{number}patterns were erroneously localized. Now, before localizing, the domain is checked against the instance’sfederated_instanceslist and only localizes domains that are found there. -
Fixed the community menu. It was broken since I re-implemented how the groups and favorites are managed earlier in this dev cycle (it’s more or less a copy of the sidebar and mainly used on mobile)
-
Further polished the group management components
- Groups can now have icons and descriptions.
- Can select multiple groups to export/delete
- In the sidebar and community menu, group headings are “sticky” to make it easier to know what group you’re in (very useful if you have a lot of groups)
- To do: Take the community groups I’ve been organizing and bundle them into the application as groups of communities users can import.
- To do: Look into creating some kind of framework to share groups, filter policies, tag lists, etc. These can be exported to JSON and imported/merged, so might as well make them easy to share.
-
Moved the group memberships flairs to the bottom of the post and added them to the community entries when browsing communities
- Added a special “Add to Group” badge button
- Used to easily add communities to groups, and see what groups they’re a member of, while you’re browsing communities on your local or a remote instance
-
Filtering is now applied to inbox items
- Still working on intercepting notifications so replies/mentions/PMs from filtered users don’t show the notification icon
-
Can now disable mentions and private messages. If disabled, these will not fetch in the inbox and won’t show notifications.
- As with the inbox filtering, still need to intercept the notification check to squash notifications for these if you have them disabled.
- If private messages are disabled, the “Send Direct Message” option will be hidden elsewhere in the application (i.e. you can’t send a message to someone if you’re not checking for replies; that’s spammer behavior lol).
-
Duplicate posts in user profiles are now rolled up as crossposts like they are in the main feed.
-
Removed comments can now be (optionally) completely hidden. This can be enabled globally or on a per-community group basis.
-
Re-worked the removed comment auto-modlog-lookup to wait until the comment is in the viewport before fetching the modlog reason
- Still automatically resolves if you have the option enabled, but the comment must be in the viewport for at least 500ms
- This should make any instance rate limits happier.
-
Removed some memory optimization hacks and added some all new ones!
- Post feed component no longer nulls out and destroys itself on unload
- Post feed no longer refreshes on browser refresh. This was causing too many problems because of certain events not firing consistently on both FF and Chrome. The feed will only refresh with new posts if you refresh manually (in the app) or if the snapshot data has expired.
- Unused properties are nulled out in various places:
- Subscribed list no longer keeps the community description in each item
- Moderating list no longer keeps a redundant copy of your Person entry in the
moderatorkey of each item - Posts in the feed no longer keep the community description or creator bio in them.
- Comments no longer keep the community description, creator bio, or whole post body in them. This is a big one. If there are 200 comments on a post in a community with a very long sidebar description, then there are 200 copies of that long sidebar description in memory. And if the post body text is massive, then there’s also 200 copies of that.
-
The
/settingspage has been deprecated and will be removed.- The “Quick Settings” modal now has all settings available and is accessible from anywhere without taking you away
- The default/main filter policy is managed from there as well
- Community Groups and User Tags are also manged from the settings modal
- Tentatively planning to move the instance administration panel there as well
Probably more (I wrote these from memory rather than checking the commit logs), but those are the highlights.
Piefed Support
I’ve had more than a few inquiries about if/when Piefed support is going to happen. I don’t have an answer beyond “It’s on the roadmap but still over the horizon”. That said, it definitely won’t be in this release and when I do get around to it, it will be the sole focus of that version.

