Talk about a project that was almost abandoned and recent open-source plans.

Foreword

Since StarBlog and SiteDirectory, I haven't written a new series about open-source projects. Recently, I've accumulated many ideas, so it's a good time to write a blog post to summarize them.

The project that was almost abandoned is the single sign-on (SSO) system I've been working on recently (IdentityServerLite).

IdentityServerLite

The reason for developing this project was that our team's internal systems gradually increased in number.

In fact, there was already a "single sign-on" solution in place before, but it was extremely rudimentary. It even lacked application management features, with multiple systems sharing the same token. User permissions were then checked within each system, which was neither elegant nor secure.

Planning for this single sign-on project began at the end of last year.

Initially, I conducted some technology selection and research, originally intending to stay within the C# ecosystem. However, single sign-on projects in the C# ecosystem are quite scarce. The only relatively comprehensive open-source option was IdentityServer4, but this project has stalled at the .Net6 version, and its team has since shifted to developing a commercial version.

I tried IdentityServer4 for a while and found its features to be comprehensive but heavy. It was also very complex, making the cost of secondary development to add the features we needed quite high.

Next, I looked at OpenIddict, a newer addition to the C# ecosystem. Compared to Ids4, it is more like a library implementing the OpenID Connect protocol rather than a complete single sign-on solution.

Since the C# ecosystem didn't work out, I turned my attention to other tech stacks, trying out the Go-based Casdoor and the Java-based Keycloak. Neither felt quite right. The former's code was a bit messy, and using it revealed some bugs, making the thought of developing on top of it mentally exhausting. The latter still had the same issue: it was too complex.

And so, I ultimately decided to develop it myself. I then spent time studying OAuth2.0 and OpenID Connect, reviewed some of IdentityServer's code, and began development of the single sign-on project. At the time, I named it IdentityServerLite—as the name suggests, a lightweight IdentityServer.

The related tech stack is:

• Backend - AspNetCore, MediatR, AutoMapper, RateLimit, etc. (There might be some others I can't recall at the moment; I'll write a separate article introducing this project when I have time later.)
• Frontend - Next.js, Tailwind CSS, AntDesign

Upon starting development, I realized the challenges were immense. A single sign-on system is far more complex than I had imagined. Of course, this was also related to my insufficient understanding of OAuth2.0 at the time. Furthermore, the need to integrate multiple external login methods added additional complexity to the project.

So, I nearly abandoned this project. I almost considered switching to an existing single sign-on solution. Fortunately, I persevered later and completed the project, although the code is quite messy as a result.

Later, I will find time to refactor it and release it as an open-source project. I've also come up with a new name, continuing the style of StarBlog—let's call it StarSSO~

Extensions

Additionally, I later discovered another single sign-on project based on C# and projects from other ecosystems. Here is a list:

• C# - SimpleIdServer - https://github.com/simpleidserver/SimpleIdServer
• NodeJS - loginto - https://github.com/logto-io/logto

Some Additional Ideas

The following are some additional ideas that will be put into practice when time permits.

• EchoSubs - Video subtitle recognition and translation service
• SnapMix - Random image API service
• AIHub 2.0 - An upgraded version of AIHub
• StarBlogHub - Implement a decentralized blog aggregation platform where different personal blogs can connect to share traffic

EchoSubs

I previously used a tool that automatically extracts subtitles from videos and translates them, which was implemented based on OpenAI's Whisper model. It worked quite well and was very useful for watching untranslated anime (referred to as "raw" content) and online courses. However, that tool was built using PyQT and couldn't support automated operations.

I want to create a service that provides an interface. Users would upload audio to OSS, then a task would be created in Celery to use the Whisper model for speech-to-text transcription (taking advantage of idle hardware available). After that, it would call the translation interface.

Currently, the core Whisper-based subtitle recognition and translation parts have been completed. The next steps are to build the interface and integrate Celery and OSS, and it will be done.

SnapMix

This is a random image API service.

My StarBlog previously had this feature.

However, I think a blog should be more focused and pure.

Moreover, I want to make the random image functionality more comprehensive.

For example, it could support user registration, allowing each user to create different albums and applications.

Each application can be associated with multiple albums, which include both public shared albums in the system and private albums.

When using the service, you simply request a random image by providing an appid and secret.

Additionally, I plan to incorporate AI capabilities, such as using multimodal models to describe images, identify people in images, and automatically categorize images.

It would also check for similar images to optimize storage space, among other features.

PS: Actually, I implemented a similar image search feature in C# last year using relatively simple perceptual hashing and histogram methods. At the time, I was planning to use Avalonia for the GUI, but later shelved the project because WPF-like development was a bit too challenging. I might use Blazor Hybrid for this in the future.

The technical selection for this project and the initial version are now complete (since these features already exist in StarBlog).

Initially, I implemented versions in Go, Python, and C#, but ultimately found that C# offered better performance.

Summary

I don't want to elaborate too much on the other projects.

After all, none of them have even started yet.

Let's call it a day~ hhh