Missing items/endpoints from api

[jwr1]

Here's a non exhaustive list of missing items/endpoints from the API that would be quite useful.

I'll add to this list once I run into more walls.

Also, whenever I say Content, I mean: thread/microblog/post/comment.

Missing Properties

• Tell if a user is an instance admin or global mod (should be a property in User objects): Add isAdmin and isGlobalModerator fields to user api response #1044
• Tell if the author of Content is a mod of the magazine it was put in.
• Tell if the signed in user has moderation capabilities over Content: Add field to all content response DTOs: canAuthUserModerate #1043
• For single comment requests (/api/comments/{comment_id} & /api/post-comments/{comment_id}), add a property containing the original post so it can be previewed above the comment itself. Edit: unsure if this would even be worth it, the client could easily request the original post on its own.
• Get the reputation a user has (would be a property in UserResponseDto).
• Notification id from the push notification payload: Push notification: add notification id #1451

Missing Endpoints

• List the activities of Content (meaning who upvoted and boosted)
• Filter magazines by abandoned (this could just be another filter on the already existing /api/magazines endpoint).
• Request to become mod of a magazine
• Request to become owner of abandoned magazine
• View, accept, and deny magazine mod requests
• List the magazines a user is a mod of
• Tell what Content a user has boosted
• A combined overview of a person's Content, just like how Mbin profile pages combine their threads, microblogs, and comments together in one tab.
• Retrieve threads, posts, comments, users, magazines, etc. by their ActivityPub ID (wouldn't necessarily have to include users and magazines, though, just here for completion's sake).

Current issues

• The PUT /api/moderate/magazine/{magazine_id} route (edit magazine) does not let you provide an empty description: Fix min length issues for magazine description and rules #1245
• The new_signup notification type is undocumented and the payload does not include the related user. Here's an example object: {notificationId: 4672484, status: new, type: new_signup}, that's it.

If you need help deciding exactly how to implement some of these, I'd be willing to give examples (also taking inspiration from Lemmy).

[BentiGorlich]

Could you split the list in

1. missing items
2. missing endpoints

Because I don't really know for which of these a dedicated endpoint might make sense

[trinitronx]

Related idea: Implement Lemmy-compatible API endpoints for clients to use.

This would open the possibility for already existing clients to login to an Mbin instance account (e.g. Use smartphone clients like Mlem or Voyager to login to fedia.io and other Mbin instances)

Mlem has stated interest, but noted that Lemmy-compatible API would make it easier. The rationale for not giving priority on implementing this on their side is Mbin & Kbin having less active users, but it's a bit of a "chicken and egg" issue. That is to say: Mobile client support would be a precursor to more active users, but their reasoning for not working to add Mbin-specific support is based on not enough users.