This is our biggest release yet, including more finished tasks than any of our previous ones. Below is a summary of the highlights:
What’s new
Posts & communities can be labelled as AI-generated and people can choose to hide all posts tagged that way. Very similar to how NSFW works.
Comments can be marked as an Answer, like on StackOverflow.
React to posts and comments with an emoji.
Hide an individual post from yourself, without blocking the author.
PieFed is now in the Yunohost app store, making initial setup easier.
When banned from a remote instance you cannot make local-only posts in their communities.
Honeypot to automatically IP ban badly-behaved crawlers.
https://lemmy-federate.com/ integration, making PieFed communities get more exposure.
“Share on Mastodon” menu item on posts.
Vastly improve docs for new developers, see https://codeberg.org/rimu/pyfedi/src/branch/main/docs/developer_docs.
Language selection is more visible during post creation.
Tag clouds can also be viewed as a list of tags.
View post/comment markdown.
Bot accounts are not included in community statistics.
Footnote support in markdown.
Polish translation.
Better HTTP caching, which reduces dependence on Cloudflare.
Bugs
Passkey fixes.
Polls can now have up to 15 options.
User profile performance improved.
Don’t allow bypassing minimum username length and post title with whitespace.
Polls and Events can no longer be posted into Lemmy communities.
API
Additional user settings can be set through the api, including Extra Fields.
Fetch url metadata.
Sort comments by controversial.
Comment search now works.
Hashtags.
Events.
Polls.
Emoji reactions on posts and comments.
See https://piefed.social/c/piefed_api for more details.
To upgrade
To upgrade from 1.3.x:
git pull
git checkout v1.4.x
./deploy.sh or ./deploy-docker.sh
There is a big database migration that will take a few minutes to run. How long will vary depending on how old your instance is - older instances will have more content to process. It took ~25 minutes on piefed.social so expect it to be less than that.
Donations
PieFed is free and open-source software while operating without any advertising, monetization, or reliance on venture capital. Your donations are vital in supporting the PieFed development effort, allowing us to expand and enhance PieFed with new features.
No, it was not dropped. “do not federate votes” is not a privacy guarantee. It just reduces the exposure of the information from the whole Internet to the server admin. People still need to trust the admin.
If you are one of the developers of the project, you should be quibbling about the implementation. “It is popular” is not a good enough reason to effectively fabricate information.
What I am against is this constant release of poorly thought out features and the prioritization of “easy” vs “correct”.
The more you try to justify what PieFed is doing, the more you are cementing my original opinion:
You might feel offended by me calling it “a pile of hacks”, but I can not think of any other term to describe this.
Well, sure. But it’s still less of an ‘exposure’ so to speak, than a vote federating out.
People don’t see it as fabrication if the community movement is reflected in the public logs - which it would be. I think I’ve only seen one other person object to the mechanic of community migration on the basis of “fabricating” information, other than you. You are in a vast minority. Most people are keen to see it go further and move subscribers too, from what I can tell. The end-game is a situation where most people recognise that communities on the fediverse are functionally modular and can be moved if necessary. Most people would understand, if this was the norm, that communities are modular and can be movied in certain circumstances.
That’s not what I asked you. I said the lemmy-federate functions should instead be opt-in, and you still seemed to oppose it.
We are talking past each other by now…
My point, in one sentence: it’s not up to the developers of a project building on ActivityPub to define policy regarding “exposure”.
ActivityPub is a protocol for public social networks. It’s not about private communications. Anyone looking for privacy should be told that and instructed to not post on a server if they are not willing to accept that will be public.
It’s as simple as that. If the developers of PieFed do not understand the basic principle of “use the right tool for the job” and keep trying to replicate anti-features from centralized websites (such as the fake-privacy that is provided by closed networks), then I will have no trust on their ability to design a good ActivityPub system.
This is a good example of selection bias. You are getting most of your feedback from other PieFed users, who clearly are not aware of the implications of such implementation.
Yes, I am opposed to any functionality being added to the server when it can be solved at the client. Content discovery can be done by the client and using a separate service like Fediverser, fedidb, or anything else. It makes no sense to have this built-in into the ActivityPub server. It is one of the many examples where the piefed devs are adding a feature because they can without thinking whether they should.
As someone who actually opposed the initial implemention of Piefed’s voting being made non-public to non-instance admins (as much as possible) to other users, I completely disagree. Some people don’t like it and don’t want their votes to be easily accessible to the wider fediverse. The only way that can be implemented currently is by removing federation. Rimu serves that.
No, I’ve seen this opinion from others. It’s also a wider criticism of the viability of the fediverse long-term in that communities are only as long as their hosted instance. This does a lot to mitigate that.
Can you tell me exactly what harm this does to the mythical ActivityPub, beyond an instance owner toggling it on in ignorance to their own detriment.
Then why restrict this logic to “like/dislike” activities, and not extend to any type of activity?
A mitigation is not a proper solution, even less so when it violates other principles in distributed systems.
The harm itself will be for the instance admin later on. Still, the larger point is this solution is a workaround that does not bring any meaningful benefit for others in the Fediverse.
To be honest, though: I don’t know what we are arguing about here. I’ve already said it: I am not here to gate-keep anything. If this the way that the PieFed developers want to do their thing, more power to them. But it’s like you expect me some kind of approval from me. You don’t need that. I may not like 90% of things that Rimu and others are doing, but they don’t owe me anything.
Some communities are also, or can be set to local only. What other activities do you have in mind?
So far as I can see, that’s up to the collective fediverse population. You done a poll on this?
It’s not supposed to in this context. It’s for an instance admin who wants to populate the content of their own instance. Although it could be beneficial if it’s an instance for others that is not personal in scope and is supposed to be a wide-use instance.
Any and all of them? What is so special about
as:likeandas:dislike? There is nothing on ActivityPub preventing users to create posts or announce activities for a different target audience.This is tyranny of the majority. If one person is out there saying “I don’t want to have the data I’ve posted on server A to be presented as if I posted on server B”, then this person will be right to complain if they see their requests being respected.
(And before someone comes up and points fingers at me saying that Fediverser was also copying user posts without their consent: it’s true that the bots were recreating the posts and comments, but they were not publishing information on the Fediverse with “actor ids” from Reddit. There is a subtle, but important difference)
Anyway, can we move on from this conversation, please? I am not going to change your mind about it and I don’t want to re-hash past discussions. I’m also not particularly interested in any of the current server-centric Fediverse projects, so you will have a hard time convincing me that anything being done on PieFed is worthy of praise.
Well we already have ‘tyranny of the majority’ here regarding a whole host of functions on the fediverse. On reddit voting is entirely private, mod-logs hidden and people now can even hide their posting history. I am sure a non-zero amount of people here object to that (I know some do). But there’s no support for changing that due to the belief prevalent across the fediverse that these being publicly accessible keep the fediverse honest.
Maybe one could have an opt-out toggle in users profiles for potential community migration. Ultimately, I’m in favour of (if this functionality ever actually exists to completely move a community) being widely known. People would join the fediverse knowing that there’s a possibility that the community they’re posting on could, down-the-line, move to another instance and thus ‘move’ their posts and comments within that community.
And I’m just replying to your points from a community perspective. You’re welcome to reply or not.
Go to Reddit with a bag of money, get the voting history of whoever you want… how is that for “private”?
If we are talking about building an “open” web, then it makes no sense to justify any design based on how the “closed” web works. The incentives are different, the use-cases are different and in the long run it will be detrimental to the open web if we keep trying to mask away the differences.
More than that, I think that the biggest mistake being done by current fediverse projects is that they keep trying to emulate the proprietary networks. Social media “platforms” are bad by its very nature and chasing this idea that we can “fix” them by making open source versions of them is a fool’s errand.
If Piefed continues to implement features without considering the ActivityPub protocol and other platforms, much as Mastodon has been criticized for, it will damage the very interoperability that makes the fediverse valuable.