wjs018

joined 4 weeks ago
[–] [email protected] 1 points 4 days ago

I actually kind of like it being a separate endpoint, so I don't mind that. One thing I thought about changing though, that I opted not to, was to make both /ban and /unban the same request method. Right now /ban is a post while /unban is a put. I feel like they should both be the same. However, this felt like more of a bigger change than some field name tweaking, so I held off.

 

As part of our ongoing effort to make our api self-documenting and validating our api input/output, we have been working through the api endpoints one at a time to make things a bit more consistent and logical. I just finished doing this for our existing /community endpoints and thought I would share the changelog here for awareness and feedback.

As of right now, these changes are only live on my instance and on our new, dedicated testing instance, crust.piefed.social. The self-documenting swagger for 1.2 (a WIP) can be found here.

1.2 Community Endpoints Changelog

  • PUT /community
    • input parameter community_id properly documented (was previously erroneously documented as id)
  • GET /community/list
    • made next_page nullable if there is no next page
    • this change was backported to 1.1 already
  • GET /community/moderate/bans
    • banned_by replaces bannedBy - transitioning everything to snake case
    • banned_user replaces bannedUser - transitioning everything to snake case
    • expired_at replaces expiredAt - transitioning everything to snake case
    • expired_at value of null indicates a permanent ban
    • expired_at only returned if ban has expired
    • expires_at field added, only returned if ban is still in effect
    • expires_at value of null indicates permanent ban
  • PUT /community/moderate/unban
    • same field name changes as above (snake_case instead of camelCase)
    • expired_at is now set equal to current time if ban was found (indicating that it was just set to expired) and returned in standard timestamp format found elsewhere in the api (2025-06-07T02:29:07.980084Z)
  • POST /community/moderate/ban
    • Input:
      • expires_at replaces expiredAt/expired_at for input
      • expires_at uses standard timestamp format (2025-06-07T02:29:07.980084Z)
      • expires_at is optional
      • expires_at is checked to make sure it is in the future, raises an exception if it is not
      • permanent is new optional boolean field, supercedes expires_at if true
      • If expires_at is not provided and permanent is either false or not provided, then the ban is set to expire in one year
    • Output:
      • same field name changes as above (snake_case instead of camelCase)
      • expires_at value of null indicates permanent ban
      • standardize timestamp format of expires_at
      • only returns expires_at because it is a time in the future (does not return expired_at)
[–] [email protected] 8 points 1 week ago* (last edited 1 week ago)

And PieFed also supports blurring photos using spoiler flair instead of just relying on NSFW tags as Lemmy does.

This and || inline spoilers || were some of my early contributions to Piefed because I was so frustrated that they weren't in lemmy.

[–] [email protected] 4 points 1 week ago (1 children)

They're different and have relative strengths and weaknesses. Despite being a contributor to piefed, I moderate a handful of communities on a lemmy instance and don't really have intentions of moving them. Overall, piefed is a lot less "mature" than lemmy, which makes sense because it is a lot newer of a project. It is getting better now about being more stable, but there are plenty of things that are still changing quite rapidly, especially on the api front.

As for python/pip/typing, I just don't see this as the major issue that some people seem to think it is. We aren't adding dependencies willy-nilly and the framework in which we are working (flask) is a very mature one that has stood the test of time. The fact that python is used for the project has tremendously helped the project in that it has allowed for a large number of contributions from many different people. Frankly, if piefed wasn't in python, it would not be nearly as feature complete as it is now thanks to the wide range of contributions we have received from folks.

[–] [email protected] 7 points 1 week ago (1 children)

the mobile implementation of the website is surprisingly good

This makes me feel good. I have done quite a bit of reworking the UI to make it more friendly at mobile screen sizes. Thanks!

[–] [email protected] 2 points 1 week ago (1 children)

Either in this thread or simply by pm works. The blahaj admins have been helpful in trying to debug this, so the most useful thing for me would be the number that is in that url that goes nowhere, 15179 in your example. That is the id of the notification that lets me get more info about it from them.

[–] [email protected] 6 points 1 week ago (2 children)

Add ability to use keyword filter on community names

This should already be live. In your user settings on the Blocks & Filters page, you will want to look for these options:

Since you are on piefed.social, rimu has tried to designate basically all the meme communities as "low quality" so that they are easily filterable by checking that box (new ones pop up all the time though). Additionally, the text box below lets you filter based on community name.

[–] [email protected] 5 points 1 week ago (1 children)

I'd like to sort communities by Top X amount of time, IIRC that was already in the works.

This is already live. If you are viewing a community, click Top in the bar and it should be a dropdown menu where you select the timerange:

If you are on a small mobile screen (like using the PWA), the different time options are listed out with the other sort options:

[–] [email protected] 3 points 1 week ago (3 children)

Alright...I don't have a solution for you, but I am going to try some stuff and see if I can replicate this. After talking with some of the involved admins, I don't really know the problem, but I have some leads to follow up on. I was able to confirm it is related to reports, but why you are the one getting a notification, I am not sure yet.

If this happens again, feel free to reach out.

[–] [email protected] 3 points 1 week ago (5 children)

Out of curiosity, what is one of the urls it is trying to link you to that ends up 404'ing?

Final question, have you reported any posts/communities/users recently?

I am wondering if you are getting a notification that your report was reviewed, but because the content was removed, the link is just 404'ing. I honestly don't know if those kinds of notifications are a thing, but notifications linking to deleted content only to 404 is a known issue that we are working on.

[–] [email protected] 3 points 1 week ago (7 children)

I'll have a go and see if I can replicate this. Would you be able to share a screenshot of what the notification looks like for you?

[–] [email protected] 2 points 1 week ago

Yeah, that should work then. I haven't really looked at that portion of the code, but I can try to take a peek.

[–] [email protected] 8 points 1 week ago (6 children)

Hmm, that is an interesting idea...

I might look into this one. Would something like voting buttons in the crosspost dropdown be an acceptable alternative? I think I would prefer to keep 1 action (click) means 1 vote, but making it easier to vote on crossposts makes sense with the way that piefed consolidates comments.

So, voting buttons here maybe? (no promises, just an idea) -

 

As part of our ongoing effort to make the piefed api self-documenting and validate the input and output, there have been a couple tweaks to the api. I realized that I should probably document them here since not everybody is keeping tabs on every codeberg PR that comes through the repo.

  • canAuthUserModerate has been renamed to can_auth_user_moderate in the CommentView schema. This transitioning from camelCase to snake_case will be a theme as I work my way through the endpoints, this is just the first that I ran across.
  • The title field in the PersonView schema will now be equal to the user_name instead of null if the user never set a display name. The way this was handled was a bit inconsistent between local and remote users, but now all users should have this behave the same way.
  • All of the timestamps in the InstanceWithoutFederationState schema have been standardized to the same format. Previously, these were in the standard iso format, but didn't have the Z at the end.
  • The Site schema can now return the site sidebar in html and markdown (if both formats are present). The sidebar field will continue to be html, while the new sidebar_md field will provide the markdown rendition of the sidebar. In the past, the sidebar was only in html, so the markdown version will only become available after an admin updates their instance's sidebar to use markdown instead of html.

That's all the changes that are live up to this point. I will continue to make posts in this community as changes are made to try to keep you all in the loop.

While we are talking about the future, other plans for the future are to have a dedicated development instance for testing bleeding edge code while keeping piefed.social on a more stable branch. In the meantime, feel free to peruse my instance's swagger ui (json version), which is up to date with the api changes as I am working on them (community endpoints are next).

view more: next ›