This was the best explanation to date I have seen of what Bonfire actually is. I still think that the ratio of marketing speak to features/users is way too high for me to get excited about it yet. I wish them all the luck and hope for the platform’s continued improvement though.

You are on PieFed, so you can always use a bit of custom css to make them go away. Pop this snippet into the custom css field of your user settings:

.comment_time {
    display: none;
}

TIL Yunohost’s site runs on Flask, just like PieFed! Also, they use TailwindCSS, which is actually really nice. I messed around with it a bit at one point and was a fan.

100% agreed.

I have contributed quite a bit to the PieFed codebase, but the ActivityPub parts of the code are the main area where I dare not wander unless absolutely needed. Trying to make sense of what AP json should look like for specific actions is basically impossible and each software tends to have slightly different dialects anyway because of the a la carte nature of the FEPs.

To that end, I just saw that you (mbin) just published all of your AP json schema. It is so incredibly helpful to have complete schema in one place for each type of activity. So, thank you a lot! I am sure I will make use of it.

It’s just an option available to an admin. Different instances can have different use cases and goals.

An example is that earlier in PieFed’s development, there was a schoolteacher that was experimenting with using PieFed as a forum for the class. This would have primarily been just a local forum with no/minimal federation. In a setting like that, having a public modlog would essentially mean having a log of every classmate’s transgressions and punishments (at least with regards to content). This isn’t necessarily something that would be desirable in a more school-like setting.

As for .zip’s decision not to have a public modlog, it doesn’t really make that much of a difference since they are so heavily federated to other instances that do have public modlogs. The modlog actions are federated similar to content.

You don’t need to use one of these apps. PieFed is perfectly capable of running in a browser, even a mobile browser. Also, you can install PieFed on your phone as a PWA (progressive web application) so that it can be run on your phone exactly like an app.

Some people prefer a different interface though, so these other apps provide options for them. Also, some people are making a transition from lemmy and these apps generally also support lemmy, so it makes the transition easier when the interface stays the same through the transition.

€30,000! I was stunned when I just pulled up their crowdfunding campaign. Apparently that is enough money for software “maintenance”. I think you have severely underpaid me for my contributions to PieFed if that is the going rate. I was just a sucker doing it for free. 😜

pre-blocked instances

Again, this is up to your local admin. Each instance is going to be run differently. The .zip instances (lemmy and piefed are run by the same team) tend to be a bit more open with their defed/block policies compared to some others. I can only really speak about piefed.social for which I am an admin.

Something to note here is that there are two different things going on. The first is user-level instance blocks like you mentioned here. They are removable by the user, and are a kind of softer way of blocking things compared to the second method - defederation. When an instance is defederated, then it is server-wide and the user can’t see content from that instance no matter what their settings are. You can review the defederated instances set by the .zip team on their instances page.

modlog is empty

This means that the .zip admin team has decided not to make the modlog public. One of the settings available to a PieFed admin is to toggle whether the modlog should be accessible to non-admins or not. Other PieFed instances might have a public modlog. On piefed.social for example, you should be able to view the modlog even without an account.

How old does my account have to be to make a community?

An account needs to be at least 24 hours old to make a community in PieFed (or be an admin). This is for spam prevention. There isn’t a reputation requirement for community creation, that page is just what we redirect to for multiple different things, so it is a bit of a broad message.

Is there a way to separate upvotes and downvotes?

I don’t think this is possible in the default web UI. It probably is possible in some apps or alternative frontends. If you hover over the number, it will pop up with the number of up and down votes. There might be some custom css you can apply in your profile to make them show up separately, but I am not good enough at css to tell you what that is.

Why are instances blocked by default

This is purely controlled by your instance admin. PieFed does ship with a default list of defederated instances, but it isn’t baked into the code or anything. It is entirely customizable by admins after the software is set up.

why can’t I see the modlog?

Links to the modlog are in several places:

• on the footer of literally every page
• in the sidebar for every community page
• in the “More” dropdown on a user’s profile page

@moseschrute@lemmy.world FYI

Something about this feature @rimu@piefed.social is showing off is that it is only doing the link substitution in the web frontend. Any links in posts/comments will remain unchanged in the API that clients like blorp and voyager. This lets the different clients deal with this as they would like.

It might be possible to do this substitution on PieFed’s side for API responses, but I think it should not be the default. We would need some way for an API client to indicate that this is what would be desired.

Yeah, I see what you are talking about. I think probably just a list below the cloud would be easy enough to add. The list that is in the sidebar is limited to the 30 most used in that community (iirc), but there isn’t any reason we couldn’t list more if a user clicks through wanting to see the tags specifically.

It also wasn’t working when the ! form was used. Only the full url designation was working (or just a local community name). I updated it so that the other format works as well (also if a user forgets the !).

Commit

This was indeed a bug. I just pushed a fix so that it works properly in the next version of piefed.

Yes, that setting is in the community settings, similar to auto-labeling posts as nsfw if toggled in the community settings.

I can confirm that this is something @Skavau@piefed.social has brought up in the past on multiple occasions. It’s an issue that I am sympathetic to, but so far it hasn’t been a high priority for us to take the time to try to address. One of the biggest complaints we see people have about the threadiverse in general is that there isn’t enough content; that their feed gets stale too quickly. So, having more subscriptions hasn’t necessarily been seen as too much of a “problem” from my perspective.

What I did work on was making it easier to unsubscribe from communities. If you filter the communities page to just communities you are subscribed to, it should be a simple matter of clicking the buttons to unsubscribe to undesired communities. It used to reload the page each time, which made that task immensely tedious.

Frankly, now that Skavau has a third party backing up their position, they will be insufferable about it until we try to fix it 😜

The ~ symbol is how you prefix a feed in piefed. Just like you use an @ for users and a ! for communities.

If this happens again, please make an issue on the codeberg. Also, when you schedule it, make sure you have the correct timezone selected. That might have made things publish before you anticipated.

I agree that would be the hard part of what I proposed; controlling what posts send notifications to activity alert subscriptions vs. not. To get a bit technical, we would have to add an option to the post creation flow where we specify whether this post should trigger activity alert notifications or not. When it is being created as part of a backfill for a newly federated community it would not send notifications, otherwise, the default behavior is that it does (what happens now). I haven’t looked at the code yet to see how difficult this might be to do, but that is the high level of what would need to happen.

As for potential new notifications about communities being added/removed, that is much more straightforward.

Scenario 1 -

That is perhaps less than optimal. Maybe we can have a new notification subtype that just sends one notification for a new community being added to the feed, and not notifications for every single post? Since there are new posts in the feed, I feel like at least one notification does make sense, especially for anybody following the feed that isn’t you (the person that added the community).

This does beg the question though; if we have a notification for a new community added to a feed, do we also have one for when a community is removed from a feed? I think these should only go out to users that have the activity alert turned on; it would be too spammy to send this to every person that subscribes to a feed.

I am going to ping @Skavau@piefed.social as our resident feed power user to see what their thoughts are.

Scenario 2 -

This is something we have talked about in the past and decided to keep it (though always open to more perspectives). As you suspect, this happens when old content that wasn’t originally federated to your instance is either fetched manually or the old post was edited by the OP in some way. The last time a user brought this up we basically decided that it might be confusing, but it isn’t really spammy in the same way that your first scenario is. Also, it is a new post in the community/feed that they are subscribed to, so it isn’t wrong to notify them about it.

The last time piefed.social received an activity from piefed.au is 2025-11-01 03:39:25.107725. I have no insight into their situation, but it might just be gone. Fediverse instances come and go sometimes.