cross-posted from: https://discuss.online/post/4522403
We are thrilled to announce the upcoming release of Sublinks, a groundbreaking Link Aggregation Social Network, joining the Fediverse. This innovative platform is designed to revolutionize how we share and discover online. Our dedicated team of volunteer contributors has worked tirelessly, utilizing technologies like Java, Go, TypeScript, and HTML to bring this vision to life. Sublinks promises a user-friendly interface and robust features that cater to diverse online communities. Stay tuned for our launch date, and get ready to experience a new era of social link sharing!
Sublinks will have a fully compatible API with Lemmy so all current Lemmy apps will also work with Sublinks. In fact, discuss.online will switch to Sublinks to fully replace Lemmy once we reach our Parity Milestone.
For more information, visit GitHub - Sublinks and sublinks.org.
Stay tuned for more regular updates as we progress.
You must log in or register to comment.
The more the merrier. Thanks for making this, and having compatibility with Lemmy’s API sounds great!
One of the most inportant features that lemmy lacks is the embedding of peertube/invidious/youtube videos . If you manage to incorporate this then what you’d have would be basically a huge improvement for the Fediverse. Imagine someone sharing a song/video he found on YouTube and instead of dealing with redirect and opening an entire other app you just click play. Heck, the user could add an “audio only” tag to their post to just show a music player widget.
I was reading through Thunder’s issues and here one of the devs of lemmy says that youtube/peertube embed links are already supported in the backend with
post.embed_video_url.I’m not sure how easy would be to implement that embed in the different apps/lemmyUI however!
Thanks for the info ! I geuss we’ll just have to be patient .
Java is an interesting choice, this could be pretty good!
Sounds awesome.
Ooh, just this week I started toying with a fork of takahe to see if it could be extended beyond microblogging. Some questions:
- Where have you found a proper documentation of Lemmy’s API? All I found on their website was the documentation of the Javascript SDK. If you have something like a Swagger/OpenAPI description of the API, it would help immensely.
- Why the mix of Java and Go?
- You mention a new API. Is there any chance that Sublinks could be developed as a more “strict” ActivityPub-compliance system? For example: would it be possible to architect the new features in a way that it only relies on the actor outbox/inbox?
A bit more difficult question: the reason that I was looking at Takahe is because it’s the only AP server (that I know of) which supports multiple domains being served from the same instance. For someone providing “managed hosting” like me, it would save me a lot on resources to have one single server for multiple customers instead of having to spawn a new Mastodon server for every one that wants to have their own domain. Is there any “killer feature” on Sublinks planned that you’d say could warrant yet-another tool? Why not contribute to Lemmy instead? Or, if the devs are more experienced with Go, why extend/contribute to GoToSocial?
- 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.
- 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.
- 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.
Not a fan of Java but the way that I see it is that other people coding in Java means less demand for me to. The more compatible open-source implementations, the merrier. Great work so far and I look forward to seeing where your project goes.
That’s interesting.
The demo indeed looks very much like Lemmy, I guess the changes are mostly in the back-end side: https://demo.sublinks.org/
The front-end is coming later. It’s fully compatible with Lemmy’s API so the demo site currently uses the Lemmy front-end.
Makes sense, let us know about the progress on your project, seems promising!
Thanks a lot! There are currently 13 contributors; it’s coming together very quickly. I’m super excited.
Does that mean your frontend will also be compatible with a Lemmy backend?
We are creating a Sublinks specific API that is much more optimized than the Lemmy one. Our front-end will be using that. Also, we’ll have tons more features that the Lemmy core doesn’t support.
Not sure if you’re aware of what happened to .world for a few months. If you decide to ascribe any political philosophy or moderation ethics to sublinks, it may be worth checking out the attack vectors used over there. Optimizing sql lookups extendedly occupied the .world admins so you’re already a bit ahead of the curve there.
The LW admins have helped contribute to Sublinks. They’ve given me full support and access to all resources to help grow it. They’ve been extremely helpful.
as far as I can tell the demo is Lemmy 😅
The front-end is coming later. It’s fully compatible with Lemmy’s API so the demo site currently uses the Lemmy front-end.
That explains it. Thanks for the clarification
Java! Yes please, a language I know sorta how to use so I will at least make sense of the code even if I might not be good enough to contribute to it yet.
Will it be any easier or harder to host/compile yourself than Lemmy or will the recommended way be some Docker image installation?
Hard to get an idea of the project from the intro, IMO!
It’s basically a fork of Lemmy. But rather than forking, we’re rewriting the entire tech stack to something easier to support and enhance. You can see the full roadmap here: https://github.com/orgs/sublinks/projects/1
That’s a nice roadmap
That’d be great to add to the about. As it is right now it’s just fluff. Had no idea what this project is because the demo is just a lemmy instance. How would a user know anything is different?
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.
Honestly this doesn’t really seem like a project targeting users (at least not at this stage). This seems like something an admin would be more interested in
I am excited to see how this grows since the backend is using java and finally I think I can contribute something.
Will there eventually be a means of converting lemmy instances over to sublinks? I know that inter instance software migration is a nightmare though.
Yes, there is going to be a tool that exports from Lemmy via a direct database connection and adds to Sublinks via the API. Sublinks is heavily event driven by design. We’ll want some events to trigger during import.
Please give me one example of how sublinks is better than lemmy currently for use.
(I don’t understand why new software instead of improving lemmy.)
It’s always good to have alternatives. Healthy competition can make them grow better too.
Healthy competition can make them grow better too.
how?
One way would be by implementing features the Lemmy devs have no interest in such as better interoperability with other fediverse platforms. If any added feature turns out to be well received and in demand, it would pressure the others to implement similar.
you are aware that what you linked is up to mastodon to implement? nothing to do with Lemmy.
Not really, Kbin (which also similar to core function as Lemmy) has better interoperability with Mastodon.
Nutomic, Lemmy dev, reject that idea. Quoted from himself: “Like you said, Kbin already supports this. No need to reimplement it in Lemmy, definitely wouldnt be worth all the effort.”
And akkoma works perfectly with Lemmy where mastodon doesnt even understand groups
i’ve never looked into using my akkoma to interact with lemmy, but i quite like using mastodon.
Sometimes improving an existing software is not always possible. One example is when the lead devs do not accept the proposed features. Another scenario is when a dev team is too onerous to work with. I am not involved in this project so I do not know the background here myself so I can only make a few educated guesses.
Java, Go, TypeScript, and HTML
Different technologies. Rust is a more niche language, which is sometimes used to explain why there aren’t that many contributors to Lemmy
Exactly, we already had 13 contributors working on it before it was announced.
Sure, but not one of those is a reason to use it.
There is probably no reason now, but hopefully in the near future Sublinks will reach feature parity with Lemmy, and could even surpass it. Technological stack can have a huge impact on the development speed of a project.
In other words, let’s wait and see
Thank you. That was very clear. I look forward to seeing the results of the developments.
That’s like saying “Watch my new TV show, it’s better than the other shows because our scripts are printed on an Epson printer!”
Not really because these are open source projects. The one that is easier to develop for will likely get more features which leads to more users.
That being said, Java was a questionable choice IMO.
