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.
It’s this kind of thinig that makes me think of PieFed as just a pile of hacks with no serious consideration for the Fediverse
{ "id": "https://piefed.social/activities/answer/hgb4iO4b8UAFRTn", "type": "ChooseAnswer", "actor": "https://piefed.socialz/u/rimu", "object": "https://piefed.ngrok.app/comment/224", "@context": ["https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1"], "audience": "https://crust.piefed.social/c/linux_questions", "to": ["https://www.w3.org/ns/activitystreams#Public"], "cc": ["https://crust.piefed.social/c/linux_questions"] }There are at least three different ways to implement this in a way compatible with ActivityPub:
And even if this type of new activity was a necessity, they could add their own extensions via a proper JSON-LD context definition. But they completely disregard JSON-LD, which means that they expect other servers to either (1) adopt their ad-hoc vocabulary or (2) ignore it completely and keep this idea that “Only PieFed has these features”.
Was it necessary ? I invite you to rewritte.
Off the top of my head, piefed is:
I am not here to gate-keep anything. If the devs are having fun working on it and if the users are happy with the product they are getting, more power to them.
It might be that piefed gets enough users and outside interest to force the team to be more discipline and mature about their practices, but to an outsider this looks more and more like a bunch of amateurs building stuff for fun, and not something that can become a viable alternative for a open social web.
This has long been scrapped. You can choose to not federate out your own downvotes now for maximum anonymity, but this was widely disliked so it was dropped.
Yup. Although this isn’t complete in many cases, but is an entirely transparent process. I’ve told you this has vast fediverse support because it enables community modularity, which is needed in a world where instances will go offline, causing communities to be orphaned.
This was agreed with the moderators of said community.
I’m not quite sure how this specifically functions for new instances, but I have suggested this be opt-in rather than opt-out.
Maximum anonymity is a lie. Users still need to trust the server admin. The truth is that the Fediverse is not a secure/private messaging platform, and attempts to hide this from the users might be well-intentioned but will bite the devs in the ass, sooner or later.
To solve this it would be better to have the PieFed team pushing/implementing the appropriate FEPs (FEP-7952 and FEP-EF61) instead of an-hoc hack.
Not the point. The point is that the devs are taking the “everything and the kitchen sink” approach to features, prioritizing any type of functionality that is minimally useful to the users instead of putting some effort on the harder stuff.
Doesn’t matter. Admins will see it, think “that is nice!”, turn it on and only realize later that their database is completely bloated with data that is not really needed. Meanwhile, the real problem of content discovery could be solved by implementing pull-based federation and client-side caching, but again this type of work is not being done because it’s not something that the users see directly.
Sure. Pseudonymity. Again, it was dropped.
I’m not here to quibble about the mechanics of the implementation, but purely noting that it is popular. You seem to be opposed to it on principle.
Then attach with it an explanation that it could cause data bloat and increase costs for them which might be unwelcome if they’re designed as a personal instance. You’re against admins having the ability to turn this on if they want?
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.
Feel free to open a PR: https://codeberg.org/rimu/pyfedi
This is not a matter of “opening a PR”. The fact that they are adding features in this completely ad-hoc manner shows that they are prioritizing features for piefed over interoperability with the wider Fediverse. If my job was to go around convincing every AP developer that their approach is flawed and to fix their mistakes, I’d be doing nothing else with my life.
What I can do though is to create a framework that makes it easy to work with JSON-LD and occasionally file bug reports.
An aside: this “feel free to open a PR” - without any justification or discussion about the merit of issue at hand - is the standard passive-aggressive response from every developer who is not interested in making the change. It’s sad to see that it’s also becoming the go-to retort for the project cheerleaders…
How is creating a new Activity type preventing compatibility with the rest of the Fediverse? Is there any other Fediverse platform that has a similar feature that Piefed could have been replicated?
When you’re the first one doing something with ActivityPub, you have to create it yourself. This is not perfect, and you raise valid points, hence my suggestion to engage on the Codeberg.
On the other hand, for other Piefed features inspired by existing implementations such as the emoji reactions, the feature is compatible with those platforms which already supported the feature.
Regarding your last paragraph, picking the one feature for which the implementation can be improved and saying “It’s this kind of thinig that makes me think of PieFed as just a pile of hacks with no serious consideration for the Fediverse” while it’s clearly not true seems fully aggressive.
If they chose to use any of the 3 solutions I described, there would be no changes on the other servers to receive and parse the message. But because it uses a different type, now those serves that want to store the information about an answer being accepted have to write code specifically to handle messages from PieFed.
It also works in the other direction: if I want to send an “accept” activity for a comment, I could do it from my server and PieFed could easily understand it as well. But because they want to create their own ad-hoc solution, then they won’t be able to.
No, you don’t. The whole point of Linked Data and RDF is that nodes can send data to each other without having to agree on any new protocol
You are only making my point. Emojis have already a defined extension, this is why it’s easier to adopt it.
It’s not just that. They also proposed some ad-hoc activities for moderation in the past and their “import community” works by taking posts and rewriting them as if they originated in the piefed instance. These are all signs that the devs either don’t understand or don’t care about JSON-LD as an standard.
This is just my personal opinion, so feel free to disregard.
But I feel you raise some decent points. But you‘re commenting them in such an adversarial manner that it makes it unlikely the piefed devs will take you seriously.
No more time for this today.
Merry Christmas everyone.
There are people whose concerns it is worth listening to. I’m sure they will show up eventually.
Happy holidays!
What ad hoc activities?
And community migration being fully realised has massive fediverse support.
‘ChooseAnswer’ is not an object type defined by activitystreams, and the json-ld context provided by PieFed server has no extension referring to it.
This means that any server ingests messages to an inbox using RDF will see this document and think “this is invalid” and drop it. If it sent as:accept instead, it would work without any modification.
Re: community migration, there is at least one other person besides me that said “when I post something to one community, and PieFed says that I also said that on another place when I didn’t, then the server is fabricating Information”.
To illustrate the point: if suddenly we adopted JSON-LD signatures as a message authentication system, then all messages from imported communities would fail.
Yes, there are some people against it. But the majority of the fediverse support the idea of modular communities.
You can have “modular communities” without violating basic compatibility with the standards. But it is harder to do it and the end users don’t see the potential issues, they will gladly cheer you to do it in the easiest way.
Because there is no real need for Piefed to create their own activity type besides it being slightly easier for their devs to do everything exactly the way they want.
But this is very detrimental to the fediverse because it means that everyone would have to change their software to suit the needs of Piefed.
This could be warranted if there was no way to do it with existing protocols. But as the other user stated above there is no real need for the way they are doing it. It is very hacky and prevents the rest of the fediverse from viewing this Piefed specific content unless they implement this unnecessary message type.
Man, the entitlement. Especially coming from the only person I know of who is here with the explicit goal of monetizing the platform.
There’s a way of voicing concerns and criticisms in a way that is constructive, helpful, and in good faith, inviting to an open discussion with concerned parties. Yours is not that.
Believing that the we need professional hosting providers to have a sustainable Fediverse != “Monetizing the platform”.
Besides, I’ve already voiced similar concerns through different venues. The devs made it clear they are not interested in developing software with a focus on standards compliance. They care about throwing as many features as possible to their system.
It’s fine, it’s their project, they can do whatever they want. It doesn’t mean that I don’t have the right to have an opinion about it.
I’m confused - this seems like idiomatic way to add new features in activity pub? What’s actually missing here?
At the very least, it is missing a context definition in the JSON-LD document that describes the term. What does a document of type
ChooseAnswermean if the provided @context entry only makes references to activitystreams and security/v1 namespaces?More than that, it is missing a clear need. There is no need to specify a new vocabulary term when
as:acceptis right there: Why define a new term when something like{ "id": "https://piefed.social/activities/answer/hgb4iO4b8UAFRTn", "type": "Accept", "actor": "https://piefed.socialz/u/rimu", "object": "https://piefed.ngrok.app/comment/224", "target": "https://piefed.ngrok.app/post/123", "@context": ["https://www.w3.org/ns/activitystreams", "https://w3id.org/security/v1"], "audience": "https://crust.piefed.social/c/linux_questions", "to": ["https://www.w3.org/ns/activitystreams#Public"], "cc": ["https://crust.piefed.social/c/linux_questions"] }can represent the information that a comment has been accepted as a good answer to the question?