How does it compare with Piped ?

[seigneurao]

Hello !

I discovered this project through your SABR work on PipePipe, obviously.
Absolutely not trying to start a war or anything here, just curious. Every new alternative gives the user more choice and makes the OS community active and also more resilient, so it's most definitely welcome.
Why did you feel like writing your own implementation, and what would you list as its upsides, compared to Piped (which I currently use) ?

Thanks in advance, and thanks again for the amazing work overall.

[Priveetee]

Hello!

And sorry for the late response, I took a little break :)

Short answer: TypeType came from a different personal need,

I wanted a self-hosted video app that felt more like my own video space: my history, playlists, favorites, subscriptions, watch progress and settings, all living on my own instance,

Not just a public frontend replacement, and not just another UI for the same idea,

I also wanted a stack and architecture I could move fast with: React web app, modern Kotlin/Ktor backend, PostgreSQL, Dragonfly, token service, downloader service, and PipePipeExtractor,

The backend being Kotlin/Ktor matters to me, I can keep the server-side code typed, structured, and modern, while still benefiting from the historical Java extractor work already done in PipePipeExtractor,

The extractor philosophy is probably the most important part for me,

TypeType wraps PipePipeExtractor on purpose, when TypeType exposes an extraction bug, I can fix it upstream when possible, and that helps PipePipe users too 😊

A real example: TypeType public playlist work exposed that some YouTube playlists returned metadata but no videos because YouTube now serves entries as lockupViewModel items, that became this PipePipeExtractor fix:

InfinityLoop1308/PipePipeExtractor#70

Another TypeType issue exposed wrong uploaders in mixed YouTube playlists, and that also became an upstream fix:

InfinityLoop1308/PipePipeExtractor#72

That loop is important to me: TypeType benefits from PipePipeExtractor, but TypeType feedback can also improve PipePipeExtractor,

Feature-wise, TypeType focuses more on the “personal app” side:

• OIDC login
• public and saved playlists
• playlist reorder / shuffle
• watched status in playlists
• advanced search filters
• channel search
• Return YouTube Dislike
• SponsorBlock controls
• YouTube remote login / session flow
• family-friendly allow-list mode
• downloader service
• one-command Docker stack
• docs: https://priveetee.github.io/Docs-TypeType/

So I would not say it is universally “better” or “worse” than another project, it is just a different direction,

TypeType is a more personal, library-focused, actively moving self-hosted video ecosystem, built around my own needs first and shared after :p

[arcoast]

This was really really interesting to read, so I'm grateful for the detail, did get me thinking, is there a possibility of a native mobile Android app to connect to TypeType? Could this be a feature in PipePipe?

[Priveetee]

Native Android client connected to TypeType is definitely something I would love one day, @arcoast. Everything in TypeType already goes through an HTTP API boundary, so the web app does not have to be the only client forever. Video history, playlists, favorites, subscriptions, progress, settings and account data could all be used by another client if the API and docs are clean enough. Even if the community ever wants to start a native TypeType app initiative, I would honestly be very happy with that. Really, I would gladly help with API details, docs, feedback, testing and integration work.

Going from “cool idea” to “real mobile client” is a lot of work though. Of course, having that kind of integration inside PipePipe would be really cool too :p Not something I want to push into PipePipe from my side. No pressure at all, PipePipe has its own direction and @InfinityLoop1308 is the one who should decide what fits there. And if Infinity likes the idea and wants to explore it someday, I would be very happy to discuss, help, and even integrate it properly.

Getting a proper native app right is not something I can promise alone. I actually tried a native TypeType client before, but doing that alone was too much for me at the time. Video playback on Android is already a whole world by itself. Every little thing adds complexity: background behavior, downloads, auth, sync, offline state, player lifecycle, Android weirdness... Yes, I like the idea, especially as a community effort someday.

Obviously it would need to grow naturally, with people actually wanting to work on it. Until then, my priority is to keep making the TypeType API and docs cleaner. Ultimately, that is what makes future clients or optional integrations possible without making everything painful. Probably the best path is to keep building the foundation first, and let the community energy decide where it goes :p

[arcoast]

I absolutely understand the work involved, the thought only occured to me as TypeType is so modular I saw the potential, thanks for the reply though, I love it when devs explain things for us mere mortals to understand!

[Priveetee]

Thanks! :)

Yeah, I like breaking problems into smaller pieces. There’s no point in making things more complicated than they need to be it’s better to keep things simple and talk clearly.

In the end, most things are simple; it’s usually us who make them complicated :p

[seigneurao]

It would honestly also make a lot of sense to have an integration into LibreTube, which I personally use at the moment.
But yeah, it's a lot of work, and I'm guessing it's better to have TypeType somewhat stabilized before that happens, anyway.

[seigneurao]

No problem for the "delay", we're not in some kind of hurry here.
Thank you for the comprehensive and crystal clear answer, I see what you mean perfectly.
I'll follow development closely, the project is indeed very promising, especially with Piped sometimes being a bit on the slower side of things (which is absolutely fine for a free project, I don't blame anyone).