Hey ! I hope you're all doing well :) !

I did my first real promotion post for the project yesterday, over on the open source community on Lemmy:

https://lemmy.zip/post/72602770

Felt good to finally put it out there, first time it goes somewhere other than our own corner. Then I read the first comment, and it was about the AI :p

And honestly, this is a good moment to talk about it with you all, instead of only having it written down in a statement somewhere.

One thing I keep coming back to, and I mean it as a real question, is why this topic takes up so much room for some people. My feeling is that it's more of a US thing, but maybe that's just my European view. The numbers sort of go that way: Gallup surveyed 37 countries, and 68% of daily AI users in the US say AI worries them, while in 34 of those 37 countries positive feelings about AI are more common than negative ones.

https://defendintelligence.com/news/news-l-ia-inquiete-68-de-ses-usagers-quotidiens-americains-selon-gallup-bac2c087

Where I am, the mood I see is more "let's learn the tool, understand what it actually does, then decide". And I'm lucky, I have a calm life and work that leaves me time to dig into the things I care about, so I can approach it that way. Not everyone has that.

So I'd really like to hear it from you:

• What do you actually think about AI in TypeType?

• Does the transparency statement answer your questions, or is something missing?

• If you're in the US, or anywhere else, is the anxiety that strong where you live? What's behind it?

• If you use the app, do you care how the code was written, or only that it works and stays maintained?

I read everything, and I'd much rather have this conversation here with you than in someone else's comments ;p

Thanks for being here :) !

Hey everyone!

I’d like to introduce TypeType, because I don’t think many people here have seen it yet.

TypeType is an open-source, self-hostable video app for YouTube, NicoNico and BiliBili. You run one private instance, then use it from the web app or from the native Android client. Your accounts, subscriptions, history, playlists, favorites, watch progress and settings stay on the instance you control, instead of living only inside the platforms.

IF YOU DONT WANT TO READ ALL THE POST (and that's alright no worries), HERE IS A TLDR !

TL;DR: TypeType is an open-source, self-hostable video app for YouTube, NicoNico and BiliBili, with a web app and a native Android client. It’s built on PipePipeExtractor with its own MSE/SABR playback engine. You can import and export your data with a dozen other apps, no lock-in. 1.9.0 is out, focused on playback reliability. Contributions are welcome, in code, translations or testing.

Source code: https://github.com/TypeType-Video/TypeType

Some background, because TypeType didn’t come out of nowhere

If you’ve been around open-source YouTube tooling for a while, you probably know the family tree. NewPipe is the libre Android streaming front-end, and NewPipeExtractor is the library that does the extraction behind it. PipePipe is a hard fork of NewPipe started in early 2022, and it also handles other services, including NicoNico and BiliBili, with its own extractor, PipePipeExtractor.

Then there’s the self-hosted side. Piped and Invidious are the two big alternative frontends, both AGPL, one built around Vue with its own backend, the other written in Crystal. LibreTube is an Android client that supports YouTube content, and it can use Piped for optional account sync. Those projects are the ones that showed a lot of people that running your own YouTube frontend was even possible.

Before TypeType, I had spent years around PipePipe, and that’s really where the project comes from.

The SABR part

My main work this year was on SABR, the protocol YouTube moved to after cutting the older methods used to fetch streams. I started with a proof of concept, the support landed in PipePipeExtractor, and then came the harder parts: live streams, cold start, session recovery, memory growth from segment buffers. I also maintain the PipePipe wiki and wrote the SABR guide there: https://priveetee.github.io/Docs-PipePipe/developer-guide/introduction.html

That work is really why TypeType exists in its current form. Once the extraction and the session logic are yours, you can build an app that owns the entire chain, instead of relying on someone else’s frontend.

What TypeType is in practice

On the web side you get multi-service search, personal libraries, downloads, comments, subtitles, SponsorBlock, administration, and SABR playback in the browser. The Android client adds background audio, Picture in Picture, audio-only playback, native playback controls and notifications, and it works from Android 6.0 without Google Play Services. The web app and the Android app share the same account and the same library, because they talk to the same instance.

One thing I’m quietly proud of is the portability. It works in both directions. You can import and export across TypeType, PipePipe, NewPipe, Invidious, Piped, LibreTube, ViewTube, Materialious, youtube-local, Flow, SkyTube, Grayjay, YouTube Takeout and even OPML, and that covers subscriptions, history, playlists, favorites, watch progress, settings and more.

And to be clear, there’s no competition here. I genuinely don’t care if you leave and use something else. The point is that your data is yours, so you can come from another project without starting over, and leave with it too if you want.

How it works

TypeType is several services rather than one big blob.

The core is a Kotlin/Ktor server. It wraps PipePipeExtractor for the extraction side: streams, manifests, search, suggestions, trending, comments and channels. It also owns the user data, accounts, subscriptions, playlists, favorites, progress, imports and administration, stored in PostgreSQL with Dragonfly as cache.

Next to it, a TypeScript token service handles the YouTube specifics: visitor data, BotGuard challenges, Proof-of-Origin tokens, player signature decoding, and the WEB and MWEB SABR session metadata. Player decoding stays on our own service path, we don’t rely on third-party decoder endpoints.

For downloads, there’s a separate Go service. It takes jobs from the server, downloads the selected streams with concurrent HTTP Range requests or SABR segments, and muxes audio and video without re-encoding, then publishes the artifact to local or S3-compatible storage. No yt-dlp wrapper under the hood.

On the client side, a React and TypeScript web app handles the interface and the library, and playback goes through our own MSE engine, TypeType-Player. It’s written in TypeScript, has no runtime dependencies, and is published on npm and JSR as @typetype/mse.

So the chain is: client asks the server, the server extracts through PipePipeExtractor, the token service supplies what YouTube requires, and the player turns the resulting session into audio and video.

What we built on top

The extraction engine does the hard part, and I credit it every time, because TypeType would not exist without it. But the project is a lot more than a wrapper now: SABR playback sessions with recovery and bounded buffers, opaque media handles, a custom MSE engine, multi-service search, personal libraries, RSS feeds, profiles, notification delivery, downloads and muxing, portability across a dozen apps, OIDC and instance administration.

Around it there are separate repositories: the React web client, the MSE/SABR playback engine, the Go downloader, and the token service. Licenses vary per component: the server is GPLv3 because of the PipePipeExtractor integration, the downloader is GPL-3.0-or-later, and the rest is MIT.

1.9.0 is out

Most of this release is about making playback more dependable rather than adding new screens. YouTube web playback is now SABR-only, and recoverable live requests stay inside the active playback session instead of leaving playback stuck. There’s also work on Takeout imports, subscription groups on desktop, and the self-hosting documentation.

Honestly, the part I’m the most proud of is that this is not a one-person project anymore. Several people sent PRs for this release, on subscription groups, playback and character encoding. That’s still new to me and it makes me really happy :)

And the community around TypeType is something I did not expect. There are amazing people who test builds, report bugs with real details, help with translations, answer each other, and just hang around. It’s warm, it’s genuinely helpful, and I will never thank them enough.

We also published an AI transparency statement, explaining how AI is used in the project and what we expect from contributions: https://github.com/TypeType-Video/TypeType/blob/dev/AI_TRANSPARENCY.md

Links:

Source code: https://github.com/TypeType-Video/TypeType

1.9.0 release notes: https://github.com/TypeType-Video/TypeType/releases/tag/v1.9.0

Android client: https://github.com/TypeType-Video/TypeType-Android

Playback engine: https://github.com/TypeType-Video/TypeType-Player

Self-hosting docs: https://typetype-video.github.io/Docs-TypeType/self-hosting/introduction

Extractor: https://github.com/InfinityLoop1308/PipePipeExtractor

Contributions are welcome, whatever part of the stack interests you: Kotlin/Ktor on the server, the React web client, the TypeScript playback engine, the Go downloader, or the Android app.

And you don’t even need to write code. Translations are handled on Weblate, so if you want to help translate TypeType into your language, you can do it right there: https://translate.typetype.video/engage/typetype/

If you want to follow the project, there’s also a community here on Lemmy: https://lemmy.zip/c/TypeType

Thanks for reading :)

Hey everyone!

I wanted to make a proper post, because a lot has happened and I don’t think a simple changelog does it justice.

First, TypeType is more mature than it used to be.

When I started, it was a small wrapper around PipePipeExtractor that I mostly built for myself. Today it has a web client, a native Android app, a native iOS client in progress, a separate playback engine, a Go downloader, and a token service. That’s a lot more surface area, and honestly, a lot more responsibility but im loving it !

The second thing is AI, and how people contribute.

I published the AI Transparency statement.

This one matters to me because AI is now part of how software gets written, including here. I use it myself. My position is simple: AI is a tool, not an author, not a maintainer, and not a decision-maker. You can use it as much as you want, including for complete implementations. What matters is that a human understands the change, reviews it, tests it, and takes responsibility for it.

If you’ve been hesitating to contribute because you weren’t sure what the rules were around AI, now it’s written down. And if you disagree with something in it, open an issue and tell me. It’s my current position, not a dogma.

Third, the community feedback is actually moving things.

Over the last few weeks, more than ten issues have been closed, and a lot of them started with your reports: Takeout imports failing, BiliBili channel errors, the cursor staying hidden over a paused player, configurable grid density, autoplay split between opening and next video, subscription groups, simplified setup, and more. Some were small, some were real headaches, but they’re all in the code now.

That includes fixes from other contributors too, not just me. kapdon worked on subscription groups, Aquarius-Situla on playback and BiliBili configuration, tam1m on character encoding. That’s the part I’m the most proud of, honestly. TypeType is starting to be a real project with several people in it.

Fourth, TypeType for Android has left beta and is stable now.

Android 1.9.0 is out, and it’s a big one for the app: UnifiedPush subscription notifications with a channel bell and a dedicated settings screen (not perfectly perfect but we are getting it there), animated skeleton loading states instead of blank areas, SABR prewarming so playback starts sooner, previous/next player controls, bullet comments on BiliBili, and support for Android 6.0 through Android 17, without Play Services.

You can grab it from F-Droid or the GitHub release.

And finally, recommendations.

This request came back so many times that I’m building it. I don’t want to clone an algorithm blindly. What I want is a system where you can see which signals are used, choose what the feed optimizes for, and turn it off completely if you don’t want it. The user controls the algorithm, not the other way around.

I think I can get something out of the oven soon, but I don't expect it to be perfect so I announce it it will be another service (yes sorry) and it will be optional, if u don't want any recommendation, no problem just don't deploy it, it's that easy.

I’ve been working on it for the past two days, and here’s a quick video: Video

For now it’s just mock data, but by now you know me: I’m picky, and I hate AI slop UI, so I spend way too much time on the UI, the UX, and the clarity...

And just so you know, I’m not starting the algorithm from scratch. A few months ago I had started one and it was honestly awful. A friend who is a data scientist explained to me what I had screwed up. I don’t expect it to be perfect, but lucky me, I know one or two things about reverse engineering, so maybe, and I really mean maybe, I had already built a custom tool to reverse engineer a well-known algorithm, long before I found out how bad I was at algorithms ;p

One last thing. I know some of you are still waiting for a reply from me. I read everything, I really do. I’m just completely swamped with development, reviews and testing right now, and I can’t answer everyone. If I haven’t gotten back to you yet, it’s not because I ignored your message.

Thanks for being here :)

TypeType on GitHub · 1.9.0 release notes · Android 1.9.0

Hey everyone!

Je vous ai compris ! :p

I asked what you wanted, and you answered. Recommendations came up again and again in the comments, and honestly a lot of you sent me private messages about it too. I read all of them.

So let's do it. We're building recommendations.

And I mean "we" for real. TypeType stopped being just my project a while ago. The bug reports, the translations, the testing, the ideas, a good chunk of it comes from you now. So when the same thing comes back from everywhere, it moves up my list.

I don't want to build just any recommendation system though.

I don't know Flow Neuro yet, and let's be honest, TypeType was never built in a vacuum. It stands on other projects: PipePipeExtractor for the extraction, the whole NewPipe/PipePipe family it comes from, Piped, Invidious, Jellyfin for the spirit of it, Komi Store for some of the Android look... I borrow, I adapt, and I credit, that's how open source works and I love it.

But that's not a reason to blindly clone whatever already exists. What bothers me with most recommendation systems is that you can't see what's going on. No idea what they optimize for, which data they use, or why you're seeing what you're seeing. And you can't change any of it. You just take the feed. A feed built to keep you watching, not to help you find what you actually want. That's exactly what I ran away from when I started TypeType.

So here's what I want instead:

• You should see which signals are used. History, subscriptions, favorites, or whatever you choose to give it. Nothing hidden.

• You should choose what the feed optimizes for. Channels you watch the most, smaller creators, discovering new things... your call, not an invisible algorithm's.

• You should be able to turn the whole thing off. Completely. If you don't want recommendations, TypeType works exactly like today, and there's no dark pattern where the "recommended" feed quietly becomes the only feed.

The user controls the algorithm, not the other way around.

I don't know yet how long this will take or what it'll look like in the end. I'd rather do it right than ship something half-baked that turns into the exact thing I hate. But we're doing it.

One last thing. Someone sent me a private message warning me about it: there's already a company with the same name as TypeType. Thx to you, you'll know who you are :p because I'd rather deal with this now than get into trouble later. So I've been thinking about renaming the project to TypeType-Video. Nothing is decided yet, and if it happens, you'll be the first to know.

Thanks for the comments and the messages. This thing is ours, and I love it :)

Tell me which signals you'd want it to use, and what it should optimize for.

I'm listening :)

Hey everyone!

Hope you're all doing well, all two or three of you hanging around here ;)

I've got a few ideas in mind for the future of TypeType, and before diving into another mountain of code, I'd like to hear what you think.

Nothing is set in stone yet. These are just a few things I've been thinking about, and I'm still trying to figure out which direction to take.

Anyway, here are the three main ideas!

1. Twitch integration?

I've been thinking about adding Twitch livestream support to TypeType.

But I'm not sure whether it makes sense to integrate it directly into TypeType, build a separate application dedicated to livestreams, or just make a small POC to see how it goes.

There's also the option of dropping the idea entirely if there isn't much interest in it.

For now, I'm just exploring the possibilities.

2. Building a proper video downloader CLI

This is something I've wanted to do for quite a while :D

I'd like to build a command-line tool for downloading videos from YouTube, NicoNico, and BiliBili.

But here's the interesting part: it would FINALLY NOT be yet another yt-dlp wrapper!

The goal would be to build an independent tool, with its own extraction logic, download engine, and format handling.

TypeType already has some of the technical foundations needed for this, thanks to the work I've done on extraction and downloading.

I'm still thinking about the technical side. I could build the whole thing in Go or TypeScript, or maybe use Go for the backend and TypeScript with OpenTUI for the frontend.

Nothing is decided yet, but I'd like to make it a standalone tool that anyone could use directly from their terminal, without having to deploy the entire TypeType stack.

3. Building a recommendation system

This one is probably the most complicated of the three.

I've been thinking about adding a recommendation system to TypeType to help users discover new videos and creators based on their interests.

But I don't want to turn TypeType into another YouTube algorithm.

One of the reasons I started TypeType was to have my own personal video space, where my data stays on my own instance and I remain in control of my experience.

I don't want to compromise that just to add recommendations.

Ideally, recommendations would be generated locally, using information already available on your instance, such as your subscriptions, watch history, or favorite videos, without sending your personal data to an external recommendation service.

The system would also be completely optional. If you don't want recommendations, you should be able to disable them and continue using TypeType as you do today.

There are still quite a few technical questions to figure out, especially when it comes to discovering relevant content across different platforms without relying entirely on their own recommendation algorithms.

And honestly, I haven't decided yet how I would implement this.

So, what do you think?

These are just ideas for now, not official announcements or promises for the next release.

TypeType is still a project I develop mostly on my own, in my free time, and there's already quite a bit to juggle between new features, bug fixes, testing, and everything else.

I'd rather take my time and release something I'm genuinely satisfied with than rush to add features just for the sake of filling up a changelog.

That's also why I'm sharing these ideas with you. Before spending weeks or months working on something, I'd like to know whether it's actually something people would use.

So, I'd love to hear your thoughts on a few things:

• Twitch: Would you use Twitch livestreams in TypeType? Would you prefer having them integrated directly into TypeType, a separate dedicated application, or should I just make a small POC first? Or maybe it's simply not something you're interested in?
• Downloader CLI: Would you be interested in a standalone video downloader for YouTube, NicoNico, and BiliBili that doesn't rely on yt-dlp? What features would you want from it?
• Recommendations: Would you actually use a recommendation system in TypeType? What kind of recommendations would you want, and how do you think such a system should work while respecting user privacy?

And more generally, which of these three ideas interests you the most?

Feel free to share your thoughts, suggestions, or even completely different ideas in the comments. I'm always interested in hearing what you think, even if I don't always have the time to reply to everyone.

And as always, thanks for supporting TypeType :)

Stay tuned, and I'll keep you posted ;)

Hello folks out there!

I know there really aren’t many of us here, honestly maybe almost nobody, but I’m writing this anyway. You never know, maybe someone will stumble across it someday.

So, first piece of news: a new app is coming, TypeType-RPC. I’ve spent quite a bit of time figuring out how Tauri works, but I’m finally making good progress. So what is TypeType-RPC actually for? Basically, it’s for people who want to share their TypeType status through Rich Presence.

And why did I build it? Well, mostly because I needed a good excuse to finally start building a proper user API. And honestly, I think this is a pretty damn good excuse. It gives me a real use case to build the API around, test integrations, and who knows, maybe someone else will actually find it useful too.

As for TypeType itself, the project is still healthy. We’re moving slowly but surely, and I really like where things are going. There’s activity, people are contributing, people are testing things, and I genuinely want to thank everyone involved.

Now, about the roadmap. First of all, we need to actually make a roadmap. The plan is to publish a proper public roadmap on the website so everyone can see what we’re working on and where the project is heading.

I’d also really like to find a few people interested in helping with the community side of the project, because right now, let’s be honest, it’s mostly me and a few fellow users keeping things alive. And thank you to those people, by the way. You’ll know who you are if you’re reading this.

We’ve also set up a Git mirror repository, because apparently I’ve learned the hard way that you can never be too careful. After what happened to us on Reddit, I’m slightly traumatized now, so better safe than sorry.

iOS is also on the roadmap. Android is honestly pretty mature at this point, but iOS is still very much under development. It takes an absolutely ridiculous amount of time, especially because I’m working on it under some... let’s say not exactly orthodox development conditions. But it’s moving.

There’s also something I’d love to improve one day, the whole visual identity of TypeType. I would honestly love to have a real graphic designer or illustrator join the project someday and create a proper visual direction for it, something that really gives TypeType its own identity. But yeah, for now that’s somewhere in my wildest dreams, we already have enough things to build before getting there.

And finally, there’s something else I’m preparing for the next release: an AI Transparency statement, or whatever final name I end up giving it. The idea is simple, I want to clearly explain TypeType’s position regarding AI, how I use it, where I think it is useful, where I think the limits should be, and what I expect from contributors when AI is involved in contributions to the project.

And just to be clear, this is not going to be some religious doctrine. It will be my current vision for the project, and thank God, you’ll still be allowed to disagree with me. You’ll be able to debate it, criticize it, discuss it, and propose something better. I think people who have followed the project for a while already know this about me, I’m not particularly interested in shutting down discussions. I’d rather hear different opinions and figure things out together.

So yeah, there’s quite a lot on the program: TypeType-RPC, the user API, a public roadmap, more community activity, the Git mirror, iOS development, hopefully one day a proper visual identity, and the AI Transparency document.

Quite a lot of work, but honestly, I’m still having a lot of fun building this thing.

Thanks to everyone who’s following, testing, contributing, talking about the project, or simply hanging around. It genuinely means a lot.

See you around.

Hey everyone!

First release announcement from our new home, and it feels good to write it here :)

Before the good stuff, a quick note.

You probably saw the announcement popup if you opened the app recently: TypeType itself now tells users about the move to Lemmy, in English, French and German, with a permanent dismissal option if you already know.

I wanted the app to carry the news, not just the community posts, because a lot of people self-host TypeType for family or friends who never read release notes. Now they know where we live :)

Now, let's get into 1.8.1, because there's a lot.

The setup just got way simpler.

If you deployed TypeType before, you might have squinted at the container list and wondered why there were three little init containers that run once, succeed, and then just... sit there in your Portainer forever.

You were not alone. This whole section of the release exists because people pushed for it:

• #226 started the conversation about the init procedure, complete with a screenshot of just how cluttered the container list looked
• #254 documented how painful a redeploy was (multi-page guide, written with a lot of patience) and asked for a simpler setup
• The same thread suggested cutting the init containers in favor of plain env secrets

That feedback stung a bit, but it was fair, and it went straight into this release.

Everything is now consolidated into one short-lived typetype-init service. It generates the secrets, writes the Garage configuration and prepares the downloader database automatically, then exits cleanly. No more busybox one-shots scattered around.

On top of that, service URLs are now configurable, which fixes the hardcoded URLs reported in #261. Podman users and custom network setups aren't fighting hardcoded names anymore.

And the hardcoded nginx DNS routing is gone, a compatibility bug reported in #251.

Is the install perfect yet? No.

But this is the beginning of the end of setup pain, and the next releases keep pushing in that direction. Thx to everyone who pushed for it :)

Account profiles are here.

The idea came from #234: when you self-host, everything ends up mixed in one feed, and tech videos and craft content don't always belong together.

So now you can create multiple profiles on the same account and switch between them. Each profile is a real, isolated space: its own avatar, its own data, its own identity inside your instance. Authentication and service notifications follow the active profile.

Thx for the idea :)

Search went panoramic.

Search got a full redesign on desktop and mobile: a wide, immersive results view instead of the old cramped one.

And more importantly, it's now service-aware. YouTube, BiliBili and NicoNico are very different worlds, and they don't deserve the same one-size-fits-all results page.

Each provider now gets relevant results and recommendations, and the recommendation logic knows which service a video came from.

Playback: the dependability release.

This one is less flashy but honestly the most important part.

A lot of it comes directly from the reports people sent with detailed logs: #248 on the buffering and seek side, and #262 for the BiliBili videos that stopped playing.

Logs genuinely make the difference, keep sending them :)

• Stalled and evicted SABR segments now recover instead of leaving you buffering forever with no way out except a page reload
• Stale HLS requests can't overwrite your current playback on Chromium anymore (that one was sneaky)
• Your exact playback position survives provider changes and source reloads, no more restarting at 00:00
• Firefox seeks while paused got smoother, and the playback buffer fills before the seek lands
• BiliBili got a proper round of love: the videos that stopped playing are fixed, audio track selection works, bullet comments behave, and range caching plus connection reuse make it snappier
• NicoNico got better reload behavior and segment caching too

Under the hood, the media player moved to MSE 0.1.60, provider media now lives behind expiring opaque handles, and playback, retry and cache memory is bounded so long viewing sessions stay healthy.

And the rest.

The floating player gained fullscreen and return controls (yes, you can now escape the mini-player with dignity).

Videos in RSS feeds finally have thumbnails.

Notification delivery got more reliable, and notification state survives feed refreshes now.

The German interface keeps improving (thx Toastienergy), and English and French got polish passes too.

For the server folks: the downloader shuts down cleanly now, job snapshots and artifact persistence are more solid, and Garage moved to 2.4.1.

As always, follow the update guide and you're good. No drama, no manual surgery.

Full release notes | update guide | rollback guide | source code

More cool stuff is coming ;)