MbinOrg
Missing items/endpoints from api
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
- [x] Tell if a user is an instance admin or global mod (should be a property in User objects): #1044
- [ ] Tell if the author of Content is a mod of the magazine it was put in.
- [x] Tell if the signed in user has moderation capabilities over Content: #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).
- [x] Notification id from the push notification payload: #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/magazinesendpoint). - [ ] 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. Basically resolve_object from Lemmy.
Current issues
- [x] The
PUT /api/moderate/magazine/{magazine_id}route (edit magazine) does not let you provide an empty description: #1245 - [ ] The
new_signupnotification 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).
Could you split the list in
- missing items
- missing endpoints
Because I don't really know for which of these a dedicated endpoint might make sense
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.
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.ioand 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.
Because Lemmy clients are starting to support PieFed, that has forced them to introduce a compatibility layer that makes it easier to support different APIs. I don't think implementing the Lemmy API exacting will be necessary.
I'm the maintainer of https://github.com/christianjuth/blorp and I'm staring to look into MBin support. While I don't need the API to match Lemmy, I do need the features of the API to roughly match Lemmy (e.g. resolve object endpoint). I also need a way to get activity pub id for all objects, regardless of if they are local or federated.
I know Voyager has shifted to using https://www.npmjs.com/package/threadiverse. If you add MBin support to that package, you should get support in Voyager pretty easily.
I have not really reacted to this, but: our dev resources are very limited and since we are organized differently form lemmy it is not an easy task to implement their API. I know this hinders app development, but my personal priorities lie in improving mbins code and building new features. That also means that I will not be investing the time to add Mbin API support to the threadiverse package.
I am very happy to work on missing endpoints as I did the other day. All endpoints listed in this issue will eventually be there, I just cannot promise a timeframe for it. If you think one of them missing prevents you from building the API I can bump it on my personal priority list.
If you have any questions or wishes regarding the existing API, feel free to ask here or on Matrix :)