Great summary!

Easier but not what I thought was needed. We need more choice!

That's not true, I wrote a blog post about it: https://jasongr.im/blog/why-i-started-sublinks/

I tried that the but API lacked a lot of features that they were too busy to add, like proper pagination to find the latest changes, etc. I started a project like that first called socialcare.cloud but have since shut it down in favor of Sublinks.

Java isn't my preferred language. I did learn Rust to try to contribute but found the code base in less than ideal state and the process of contributing to risky. They don't always accept all PRs. I also have low faith in the success of Lemmy due to it's poor QA process and it's major lack of features.

I believe Java is the best option for this type of application, I almost did it in PHP. My goal was to attract as many people as possible to want to contribute. It's worked, I have a ton of people contributing in some way, Sublinks roadmap is clear and organized, and we have a super-motivated and driven team.

We won't fail.

There is talk of having post types. This would allow for further fediverse integrations to function better.

To answer your questions:

1. Sublinks isn't a copy of Lemmy. There used to be a greater focus on multiple post types, but now it's not a main feature to work on. Sublinks is an alternative to Lemmy that adheres to the Lemmy API to capture the client base for that API. Sublinks has its API for its front-end and any apps being developed for Sublinks.

Being long-term compatible with Lemmy isn't a priority either. We set our first milestone to be parity with the Lemmy API contracts to allow for apps to work from the start. As we grow our footprint Lemmy would have to display it the best they can. We don't plan to add support for Sublinks into other applications.

2. Yes, we're building our federation service to include as many services as possible.

People were reaching out to me to try to understand these details so I just made a blog post to just point people to.

We have 13 contributors with Sublinks so far. I expect more will come after the announcement.

A new front-end is coming too. We need a new front-end to support all the new features we’re adding.

I'll get it on there on the sidebar. Thanks a lot for the feedback. The demo site has been up for so long that I didn't think of it when I announced it.

1. I referenced the Rust code to determine what was sent and received. We're implementing better code logic; we're not just copying their API. We want to be compatible to attract users and support all the hard work used to create Lemmy phone apps.
2. Java is for the core Sublinks API/core. Golang is being used for the federation service that operates independently. Once it's done, it will be platform agnostic if someone else wants to use the federation service for their fediverse project. They communicate through a message bus.
3. Yes, we plan to do the new API correctly. We will support Lemmy's API for as long as it is relevant, primarily for mobile apps.

Multiple domains aren't possible yet, but that doesn't mean we cannot add it later.

I'm unhappy with the Lemmy roadmap, development speed, and quality. I wanted to contribute but found it difficult to. I did the next best thing and created a somewhat drop-in replacement with a much larger community of developers who are willing to support it.

You can see the complete Sublinks roadmap here: https://github.com/orgs/sublinks/projects/1. The first release of parity (v0.10) will use the existing Lemmy front-end. All releases after that will no longer support the Lemmy UI because that's when the enhanced features start to roll in. We don't want to support or fork the current Lemmy UI.

Exactly, we already had 13 contributors working on it before it was announced.