Now that Pawb.Social has forked Lemmy, I thought it would be appropriate to go ahead and compile a list of changes or additions that have been suggested, or that have been spotted by others or myself. This is hardly a comprehensive list, and down below will be two comments by me, one for changes to back-end changes or additions and one for the front-end suggestions as well.
A quick note before I start
One important thing I do want to stress is that any changes or additions made should not render our fork incompatible with other Lemmy instances, the apps that allows for easy usage of Lemmy (Jerboa, Thunder, etc), nor cause issues for interacting with, or interactions from, the rest of the Fediverse. To take a quote from Linux Kernel development: Don’t Break Userspace!
Now, let me specify for any who aren’t in the know about the differences between back-end and -front-end are:
-
Front-end: focuses on the user interface, designing the visual elements, and ultimately the UI elements that a user will interact with on the web page.
-
Back-end: deals with the server-side functionality, handling data processing, storage, and communication with databases and external systems (The rest of the Fediverse) using server-side programming languages and frameworks. For Lemmy, this is done with the Rust language.
Now, with that summary done, here is a (still WiP) list of changes:
Back-end
- Addition: Individual community blocking (as opposed to the current instance and user-only blocking).
- Addition: Ability to follow entire instance (or at least follow all communities on an instance).
- Addition: Allow for individuals to block instances and communities, instead of requiring instance-wide action to block them.
- Addition: Give instance admins better moderation tools (hashed IP address, etc. Needs to be GDPR compliant)
- Change: Better support for automatically linking other communities (and instances) back to your primary instance for easier following and interaction.
- Change: Better cross-compatibility between Lemmy and the Mastodon/Pleroma side of the Fediverse.
- Change: Better cross-compatibility with KBin.
- More to come
Back-end & Front-end
(For things that will require changes on both ends to function properly)
- Addition: Post flaring - To allow for better post management, sorting, viewing, and moderation.
- Addition: Ability to sort communities into groups (similar to multireddit).
- Addition: 2FA during login/sensitive actions like password changes.
- Addition: Mark servers and people as “friends” so they display a marker by their name elsewhere.
- Addition: Better nsfw post handling, more specific viewing settings, etc.
- Addition: Adding notes to users (for moderation purposes)
Front-end
- Addition: Add more themes/theming support to the UI.
- Addition: Add better support for widescreen displays.
- Addition: Ability to pick a default sorting method (perhaps per community).
- Change: Refresh and organize some of the UI elements for Lemmy (somethings are just a bit outdated looking…).
- Change: Alter donation button at the top to point to the donation portal for the/an instance (this should be the default tbh, the prominent button shouldn’t direct to the Lemmy devs to begin with…)
- Change: Move all information about Lemmy and the Lemmy devs to one, out of the way location, potentially as a citation in the footer.
- Change: Add link pointing to the GitHub fork for Pawb.Social
- More to come.
Please see below for the two threads to add your own thoughts or comments on things you want added, changed, or even removed. All comments and thoughts are welcomed!> ability to sort communities into groups (similar to multireddit).
Comment here for any suggestions for Back-end development!
Addition: Allow for individuals to block instances and communities, instead of requiring instance-wide action to block them.
Don’t we already have the ability to block individual communities on an user level? We certainly have a ‘Block Community’ button available, and it seems functional from what I can tell.
I’d love the ability to better filter and sort the communities list. In particular, I’d like to be able to filter (or sort) by communities I haven’t subscribed to, or by communities by instance, or by their NSFW flag. I get that we can go to another instance and see their community list, but it’s a bit of a PITA to subscribe or unsubscribe from there; ideally, we’d be able to do this within this community, so the sub/unsub links are present and functional.
So, I don’t disagree with the decision to fork (especially because of the hardcoded donation URL). I am concerned about fracturing of the codebase, so I have a few questions:
- Will this fork always be a sequence of commits based on some Lemmy version, or do you expect history to diverge (git rebase vs merge)?
- Will there be an effort to upstream useful changes into Lemmy proper (a lot of the changes suggested are things that might be desirable for Lemmy in general).
- There’s a number of other communities with a desire to use a forked Lemmy version, do you intend this fork to be useful for them, or is this purely for pawb.social?
And perhaps most importantly:
- Will the name be changed from Lemmy to something else if there are significant changes.
When there are changes to the base Lemmy project, those will be implemented in our fork, and when we feel there’s a feature to push back upstream, we’ll gladly do so.
We’re also not making the fork specific to Pawb.Social, so things like the donation link will be customizable.
I have an idea, but I’ll be honest, I don’t know the difficulty of this idea. For back end & front end: The ability to sort communities into groups (similar to multireddit).
I also wonder how we’ll implement all the changes on pawb.social to existing apps such as jerboa. While pawb should still be usable through the apps, features that don’t exist upstream probably won’t be available on the app either. We could fork these apps, but that would take too much resources.
Comment here for any suggestions for Front-end development!
Not sure where the settings actually live, so I can’t say whether this is backend or frontend, but I have been thinking that nsfw post handling could be improved.
Specifically, I’ve been thinking about (and actually been considering implementing) some new per-user settings:
- Don’t show nsfw posts from other instances in the “all” feed.
- Don’t show nsfw posts in the “local” or “all” feed at all.
- Always show nsfw posts from communities the user is subscribed to, regardless of the above two options.
Should cut down on any drama caused by someone registering on a random instance and subbing to gfur. :P
EDIT: Looking at the replies, it looks like a simple site wide toggle a-la Furaffinity might be easier to implement and more egonomic.
I think we can simplify your idea as a setting or toggle to allow user to enable or disable NSFW on “Local,” “Subscribed,” and “All” feed separately.
To add to that, a simple NSFW toggle above the feed (such as near the sort options) should help, so user can enable and disable NSFW with one click on the feeds page, instead of having to go through settings. I don’t really like seeing nsfw posts when I’m not in the mood.
This probably requires a bit of backend to store the data too but maybe a way to mark servers and people as “friends” so they display a little marker when you see them in the wild.
I’ve been using this userstyle to do it on a server-basis and I love seeing friends in unexpected places. I’ve seen a few one-off people that posted really great content and thought “wow I wish I could keep track of them”. Marking them so I can spot them in the wild, and maybe being able to scroll through my marked people’s comments in a feed would be neat.
This sounds similar to the user tagging feature in Reddit Enhancement Suite, which I believe is done client-side. I’ve found it useful for lots of reasons and having it built-in might allow for even more functionality. Another similar feature I’ve seen elsewhere is the ability to add private (only visible to you) notes to profile pages.
I’d love to be able to pick a default sorting method (perhaps per community).