mlemgroup
Compatibility with KBin/MBin
This has been stated elsewhere, but for the forseeable future, we don't think we can try to aim for compatibility with kbin's API, due to the complexity that brings to the app. We may consider it once things have died down a little.
However, the feature request is still there, so here is the issue to track it.
If KBin decides to become compatible with us by adopting the Lemmy API, then that would be seamless.
Putting under "Future." If we abstract our data models from the API models, this should be pretty doable.
Is this something we'd still want to do? Last I heard, the sole Kbin maintainer left for good and shut down kbin.social. There are of course other instances, and forks such as Mbin. Kbin has 24 MAU currently according to FediDB, and MBin has 989. That's 2% of Lemmy's MAU (45,858).
Demand
Adding support could make Mlem-middleware significantly more complex, and I'm hesitant to support additional platforms if there isn't much interest. Most of the 1000 Kbin/Mbin users probably have Android devices, and the remaining users would probably have switched to Lemmy already if they wanted a mobile client.
On the flip side, it's likely that the lack of Kbin MAU is at least partly due to the lack of mobile clients. Supporting Kbin could drive more interest to the platform in general, which could make it worthwhile.
Implementation
We'd also need to look at how different the API is to Lemmy's. It would probably involve creating a base ApiClient class and subclassing into LemmyApiClient and KbinApiClient or something like that. Methods that are unsupported on one platform or another would throw ApiClientError.unsupported.
Platform support priority?
I don't think we should consider Kbin support until we see how popular Sublinks ends up being. It's not unlikely that Sublinks ends up with more MAU than Kbin. Supporting three different platforms is more complex than supporting two - we may decide that two is reasonable, but three is too much work. If that's the case, we may end up supporting Sublinks instead of Kbin.
See the main issue for Sublinks support here.
I'm one of those iOS users who would really appreciate mbin compatibility in mlem; It's painful to get attached to a client such as mlem and then lose it when switching to an mbin instance as I'm considering doing. The move isn't related to mobile but I am growing to appreciate the single-instance approach to having both threads and microblogs along with the really nice UI/UX that mbin has.
I've also asked for a similar feature request in the Ivory iOS app and for similar reasons.
Agreed, currently there is no stable Mbin iOS app however Interstellar is in the pipeline.
Supporting MBin would take up a big chunk of development time, which would give us less time to work on improving the experience for Lemmy and PieFed users. Personally, I don't think it's worth it at this stage.
Supporting MBin would take up a big chunk of development time, which would give us less time to work on improving the experience for Lemmy and PieFed users. Personally, I don't think it's worth it at this stage.
Why not? I would love to provide help if needed when trying to support Mbin.
@melroy89
Mlem's core goal is to provide the best possible experience as a link-aggregator app. Supporting a platform incurs an ongoing maintenance cost, and we don't currently have the development bandwidth to support a third platform without significantly compromising the quality of our offering.
If in future we have more resources available, we will consider it. For now, it's just not really feasible I'm afraid.
I see. Just for reference then, here is our API fully documented in detail: https://docs.joinmbin.org/api/