Mastodon API implementation? #179
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have a half-finished Mastodon API implementation in my Misskey fork, and someone suggested I should PR it to your project. would you be interested in this?
Hmm, depends a bit on how complicated it is. And since as far as I know Mastodon does things a bit different than Misskey I would assume its not super simple. And it may even conflict with the things we are trying to do over in #177. So I'm inclined to say no. Would be interested to know opinions of the other maintainers.
While it would be nice to be able to take advantage of the existing array of MastoAPI libraries, there are significant differences between Mastodon and Misskey.
For example, Mastodon has favourites but we don't really have a 1:1 equivalent of that. Emoji reacts aren't quite the same.
There's more than just that though.
I'm personally not really sure if it's a great idea anyways. We'd basically have to keep up with what Mastodon does if we'd want to maintain compatibility, something Pleroma/Akkoma sometimes has troubles with.
It is a bit hard to judge without knowing which parts you implemented and which you did not. Maybe you can give a rough outline of what you did?
To be honest I might be interested in cherry picking some bits, e.g. if you implemented OAuth stuff or so. But I don't think Mastodon API compatibility is something we are really targeting.
I implemented timelines, notifications, user pages, liking/unliking/boosting/unboosting posts. Likes are implemented similarly to how Misskey implements receiving them through federation: they are converted to the reactionFallback... in config. I would also be happy to implement more things before PRing, if there is something else you would need.
One struggle point is Mastodon clients expect HTML format post content while Misskey clients expect it in MFM format, so a backend service is needed to properly convery between the two (maybe whatever is used for federation would work here? I don't know, I generally stick to plaintext posts).
I kind-of implemented Mastodon OAuth (probably breaking Misskey's own OAuth in the process because I misused the existing database schema, but it'd be simple enough to add a new row/table/whatever is needed for it)
Taking into consideration both what has already been said above and the fact that we moving towards our own OAuth 2.0 implementation I think we are not interested in a Mastodon API implementation.