notify.moe Support

[akyoto]

Hello,

I am the developer of a modern anime tracking platform that is very similar to MAL / Anilist / Kitsu etc. and was wondering if Taiga is interested in supporting it.

I have done quite a bit of C++ programming in the past so this is something I might be able to add to Taiga by myself if I ever manage to get the free time to contribute.

The anime list API uses JSON: https://notify.moe/api/animelist/4J6qpK1ve

To get a user ID for the user "Akyoto": https://notify.moe/api/nicktouser/Akyoto

An overview of available endpoints: https://notify.moe/api

We have MAL IDs, Kitsu IDs and Anilist IDs. Imports from those services are supported as well.

Let me know if this is something that we could cooperate on! :smile:

Discord contact: Akyoto#6469

[erengy]

Hello @blitzprog,

I've seen the browser extension before, but it seems you're upgrading the website to a full-fledged platform now. Congratulations!

It's too early for me to consider adding it to Taiga, though. I've been burned before by prematurely adding in a new service, so I'd rather not repeat the same mistake. Also, while the initial implementation is not too hard, maintaining the support takes a lot of time, and I doubt more than a dozen people would benefit from it.

Still, I'd like to mention a couple of things regarding your API:

• Getting into it without any documentation is a challenge. At the very least, simple descriptions should be given for each endpoint, and links should go to actual examples rather than a 404 page not found error.
• Endpoints don't have any structure. If that's how you'd like to do things, similar endpoints should at least be grouped together on the documentation page.
• Endpoint names are inconsistent and confusing. EmailToUser has double meaning, Item is too generic, etc. I'd suggest giving more thought into them.
• I couldn't find any information on how to authenticate the user. Is it basic HTTP authentication? Is it OAuth? Is there an endpoint for it?
• animelist endpoint returns list entries, but no information on the anime. Are we supposed to call the anime endpoint for each one?
• user information includes agent and browser fields. Are they related to the browser extension? In any case, they shouldn't be exposed without authentication.

Overall, I think the API is not suitable yet for public consumption. As for some general feedback regarding the website:

• It seems users can only register by signing in via Google or Facebook. Is it not possible to create an account the old-fashioned way? That put me off, so I ended up not registering, not even for testing purposes.
• The overall design (combination of colors, icons, typography) looks a bit too generic to me. The website needs to build some character, in my opinion. Using an anime character as the brand logo doesn't quite help either (says the guy who named his program after another anime character :).
• Search input sends way too many HTTP requests. I see more than 10 requests for each letter I type, not including the images. Could it be that each request (e.g. /_/anime-search/{query}) is sent twice?
• Character images are still linked to Kitsu's servers. I'm not against scraping the information from Kitsu, they mostly get it from other sources anyway, but using up their bandwidth too is not nice.

All that being said, I really like that pages load up so fast. The effort you spent on it definitely shows. Small features such as displaying the average color while loading images, or the Japanese tokenizer, add up to create a rich experience. And I see that you have lots of other things planned too. Good luck!

[akyoto]

I was merely asking if you're interested in a cooperation, not expecting you to assume that the current API is in a final state (far from it), especially because GraphQL is going to be available in the future.

Thank you for the criticism on the current state of the API.

I have applied the following changes based on your feedback:

• https://notify.moe/api/ now links to documentation pages
• https://notify.moe/api/anime/ as an example for Anime, now lists object fields, types and link examples
• Note that human-written text descriptions and subtypes have not been added yet (planned)
• Type Item has been renamed to ShopItem
• User agent based information has been excluded from the public API

Things I have not changed, on purpose:

• EmailToUser because it's consistent (NickToUser, FacebookToUser, GoogleToUser)

Anything you mentioned that I haven't replied to yet, I'll reply to in a future GitHub post. These are only the changes for today. I just wanted to let you know that I've read your criticism and am working on the suggested changes.

[erengy]

Just to be clear, I didn't assume that the API is in its final state. It'd be unfair to expect a stable API at this point, when the platform is relatively new and in active development. I read the FAQ entry where you mention, "the API is an on-going effort and subject to change" too. But since you asked if I'd be interested in supporting the platform, I spent a couple of hours exploring the website, the API and the repository. Then I wanted to offer some feedback, rather than merely refusing to work on it.

My experience with GraphQL has been a good one so far, I look forward to seeing that in notify.moe.

[akyoto]

Update: We had some pretty big changes and I managed to set up the GraphQL server.

The biggest remaining task is authentication. Do you have any preferences for the authentication method? I believe OAuth is the most modern one.

[erengy]

Pretty much everyone (including the upcoming MAL API) uses OAuth 2.0. I've come across some critical articles and discussions about it, but I'm afraid I'm not familiar with any alternatives.

Just make sure to offer an OAuth flow that does not require a client secret, for mobile and native applications.