Piefed contributor and part of the piefed.social admin team.

  • 17 Posts
  • 199 Comments
Joined 1 年前
cake
Cake day: 2024年11月20日

help-circle



  • Some of the other bigger instances out there federate with one or both just fine

    I mean, the same is true for other PieFed instances. piefed.zip, for example, is federated with both (same admin team as lemmy.zip).

    Like I said, this is inherently opinionated as any kind of defaults would be (themes, colors, user settings, etc.). I just don’t agree that just because an instance is old and active means that it is a positive influence on or provides a positive experience for the average user. Just like I don’t think forums like 4chan should be looked at positively just due to its age and activity. I know there are many that disagree with this, and there is nothing wrong with that.

    Specifically, the piefed.social instance is a bit more opinionated than most other instances out there because rimu has pretty strong feelings about social media. Some of my contributions to the code have been to make PieFed less opinionated or to take some of those very strongly opinionated options/filters and make them configurable or optional at an admin level. So far, rimu has been pretty receptive to this kind of contribution.

    At the end of the day, I am glad that all three threadiverse software platforms exist (people too often forget about mbin) and have been able to maintain a cordial working relationship. They each have different opinions, defaults, and features that might appeal to some users over others.


  • Here is the list of defederated instances when a fresh install happens. This is editable in the admin UI after installation is complete. So, if you really want your instance to federate with the good folks of cum.salon, you are more than welcome to.

    This is really just intended to provide what we think of as a good set of defaults for a typical user. Of course this is somewhat opinionated, just like something like an operating system has a set of opinionated defaults for stuff like default programs, window styling, etc.



  • The language really doesn’t have much to do with things like performance; at least not at the scale that most fedi instances operate at. For PieFed we are using the Flask framework and the overhead of an interpreted language and rendering jinja templates is absolutely negligible compared to the speed of the postgres database. Most of the performance optimizations we have had to make have been related to crafting better db queries or moving things like federation tasks to background workers.

    Might Flask have trouble scaling to the size of reddit? Sure, but I don’t think that we necessarily need to optimize for a use case that may never happen and can also be alleviated by scaling out (more instances) rather than up. I know that rimu is already feeling like piefed.social is too big compared to other PieFed instances and has thought about closing registrations because of it. It is one of the reasons he made the built-in instance chooser, to try to move new users to other instances.

    I wrote more about my thoughts on the pros/cons of python/flask in another comment.




  • I can’t speak for rimu (he is the one that pulled the defed trigger), but I don’t disagree with the decision. I personally don’t view the radical transparency of votes provided by lemvotes as helpful or useful. Admins and mods already have access to voting data that is relevant for their moderation purposes. So, often lemvotes data is simply used as a way to call out people that downvoted but didn’t reply or as a way to sleuth past votes from another user to find some rationalization that their vote shouldn’t count. It also more easily enables things like a user voting in one community prompting a moderator in another community to preemptively issue that user a ban.

    I understand that all of these things are certainly possible without lemvotes if you run your own instance and just harvest/analyze all of the activitypub data. Defederating from the lemvotes instance may be futile, but I guess I just see more negatives than positives of providing all that voting data to lemvotes.


  • Asks for feature in software

    Dismissive reply to, and ignores content of reply from one of the developers of said software

    Good luck with that…

    To bluntly answer your request, I am not going to put any of my time into implementing this feature (can’t speak for the other devs) as I don’t think it is a good one generally. Used responsibly, it might be better for how you specifically want to use social media, but I think this is too ripe for abuse if used maliciously. I have, in the past, advocated for less vote transparency instead of more. That is why I suggested to you an option of just disabling downvotes altogether as that is probably the closest you are going to get for the foreseeable future.


  • If you really don’t want downvotes, and their existence is harming your experience, then my suggestion would be to either run your own instance and disable downvotes at the instance level or to join an instance that disables downvotes (like blahaj).

    I think pretty much everybody in the threadiverse seems to agree that voting certainly has some issues, but nobody agrees on a solution. Votes are a simple binary up/down and there can be a lot of nuance as to why somebody might choose to upvote one thing or downvote another thing. In other words, there are many different reasons somebody might hit the downvote button, some more helpful/harmful than others; being off-topic, spam, personal grudge, etc.

    This was one of the things we were trying to address with something like emoji reactions. It is a much more expressive form of feedback without requiring somebody to overcome the barrier of actually authoring a reply. Also, as a side note, every emoji reaction is counted as an upvote to other fediverse platforms that don’t have emoji reactions (lemmy), even “negative” emoji like 👎. Also, emoji reactions do show the usernames of those who reacted that way when you hover over the reaction.

    In general, most general users (of social media, not just the threadiverse) don’t really like their votes being public to every other user. This tends to come up every couple months when a post about lemvotes gets popular and sparks a discussion about it again. I have been in many discussions with Skavau about vote visibility in the past. I actually think that community moderators shouldn’t be able to view votes, reserving it just for instance admins. However, with the way lemmy allows mods to view votes, my stance is kind of moot and PieFed now also allows mods to view votes.






  • rimu talked about this a bit in a fireside fedi chat a while back (~24:00 for tech stack discussion and ~33:00 for python specifically).

    As for async, all of the federation work happens asynchronously through the use of celery tasks. Federation work is actually a pretty sizable portion of the computational demand, so offloading that to workers in the background helps a ton. So, the only thing that flask is really responsible for in terms of serving pages is the web UI and the API. It might not scale to the size of reddit very well without a ton of work, but it has been fine for piefed.social. Just like lemmy (or honestly most other applications like this), the main bottleneck is the database rather than any kind of computational overhead for the python framework or rendering speed.

    A big advantage of the stack is that it is relatively simple. If you know some python and some pretty standard html/bootstrap, then you can make meaningful contributions (I wrote the dev docs and I am not a professional developer for example). This has led to a large number of contributors that have worked on the features that they feel are important to them since the barrier to contribution is fairly low.

    I think the primary disadvantage of using a framework like flask is that it led to PieFed being initially created as just a web interface without an API. Trying to tack an API onto the application after the fact has been a pretty heavy lift, and there are still areas where the API is lacking compared to the web interface. It is something that we have gotten better at now, we add things to the API at the same time as the web interface, but there is a decent backlog of features yet to be added to the API.