wjs018

joined 1 month ago
[–] wjs018@piefed.wjs018.xyz 2 points 20 hours ago

Again, pinging @rmayayo@lemmy.world to let you know about these tweaks since I believe you are using the 1.1 version of this endpoint.

 

Me again, here to document some more upcoming api changes as the self-documentation adventure continues. This time, it is the /topic/list endpoint. Similar to feeds, this endpoint exists in 1.1, but it was undocumented. This has led to it not being widely used yet, so I have taken the liberty to make a series of changes to it to help it be more consistent with other endpoints. This has mostly taken the form of field name changes. In the end, this endpoint now looks and functions very similarly to /feed/list by design.

Here is the updated swagger running on crust, and here is the codeberg PR if you prefer to look things over there.

If you have made use of this endpoint in its 1.1 form, I have included a changelog compared to 1.1 below. Let me know if there are any questions/feedback/requested changes.

Changes from 1.1:

  • Added include_communities request parameter. Functions exactly the same way as the /feed/list endpoint.
  • Dropped version field
  • Multiple field name changes for better consistency with other endpoints. I have summarized them in the table below:
Old field name New Field name
num_communities communities_count
name title
machine_name name
parent_id parent_topic_id
show_posts_in_children show_posts_from_children
[–] wjs018@piefed.wjs018.xyz 6 points 23 hours ago (2 children)

It will show up automatically if you meet some conditions (which you won't until 1.2 is deployed):

  1. Running version 1.2 that has the code for the instance chooser (or maybe a custom build like piefed.fan must be)
  2. Enable the instance chooser in the admin settings

I don't know all the details as this is something rimu coded up, but I suspect that your instance would then be listed as a choice for any other piefed instances that have the instance chooser enabled and that you are federated with.

[–] wjs018@piefed.wjs018.xyz 6 points 1 day ago* (last edited 1 day ago) (1 children)

This snippet worked for me when I just tested it:

.post_teaser_image_preview a {  
    max-height: unset;  
} 

Basically, any css rules in your custom css overwrite the rules specified elsewhere.

Edit: I just wanted to add why the max-height was set initially. This is the codeberg issue that caused there to be a limit. Basically, without setting a max-height, really tall and skinny images can take up a huge amount of vertical space.

[–] wjs018@piefed.wjs018.xyz 4 points 3 days ago

Just wanted to ping @rmayayo@lemmy.world to let you know about these tweaks since I know you are using the 1.1 version of this endpoint (I think Boost is the only app I saw using feeds, but I can't claim to have tested all of them).

 

Another post from me as I continue to work through endpoints. This endpoint is present in 1.1, but it is undocumented. AFAIK, only Boost has made use of it so far, so this might be of particular relevance for them. The updated swagger is available here for your perusal. If you have already experimented with this endpoint from 1.1, I have included the changelog below. So far, this is the only feed endpoint in the api, documented or otherwise. I am sure more will be added in the future.

This is still open for feedback/suggestions, so if there is something here that would help/hurt, please let me know!

Changes from 1.1:

  • drop machine_name field as it was redundant with name field
  • rename num_communities to communities_count to better align with other counts fields for other endpoints
  • drop ap_id and ap_profile_id fields in favor of...
  • new actor_id field is the url of the activitypub actor (examples: https://instance.tld/f/feed_name for a public feed or https://instance.tld/f/feed_name/user_name for a private feed)
  • new ap_domain is the instance domain of the actor (example: piefed.social)
  • rename show_posts_in_children to show_posts_from_children. This is purely a linguistic preference on my part and so I am taking the opportunity before this endpoint gets more widely used, to change it now.
  • drop version field as it was not really informative
  • new local field that is a boolean indicating whether the feed is local or remote
[–] wjs018@piefed.wjs018.xyz 1 points 2 weeks 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)
[–] wjs018@piefed.wjs018.xyz 8 points 3 weeks ago* (last edited 3 weeks 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.

[–] wjs018@piefed.wjs018.xyz 5 points 3 weeks 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.

[–] wjs018@piefed.wjs018.xyz 7 points 3 weeks 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!

[–] wjs018@piefed.wjs018.xyz 2 points 4 weeks 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.

[–] wjs018@piefed.wjs018.xyz 6 points 4 weeks 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.

[–] wjs018@piefed.wjs018.xyz 5 points 4 weeks 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:

[–] wjs018@piefed.wjs018.xyz 3 points 4 weeks 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.

 

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 ›