On version numbers
Technical users, as well as the developers, commonly refer to the iterations of the platform as a whole based on the API version number that was used by the backend at the time.
V1/V2 Era
The first version of the platform was a quickly put-together TypeScript backend with an Angular frontend, which used Google's Material 2 styled components. This is referred to as the V1 or the V2 version of the platform, due to the fact that the V1 version of the API went away and got replaced with the v2 version at an extremely early point of the development.
The placeholder description of the original V2 website.
At this point, V2 was the version most of the world had been exposed to, due to the website starting to get promoted and shown by various relatively big streamers who knew of it due to Anatole trying to promote it to show it off.
The V2 version of the website wasn't exactly anything special, but if anything, the biggest thing people were complaining about at the time were various errors you'd get on the website if you did pretty much anything.
You could try to add an emote to your channel and get an error, or you could subscribe and get an error, but what was annoying was the fact that the errors returned to you meant nearly nothing, and you could never know if it was an actual error, due to the complete lack of any kind of details or technical information within the errors.
As it was deemed to be unacceptable, that was the point when Anatole and Troy started to develop the V3 version of the platform.
V3 era
The V3 version of the platform used Golang for the backend API, Vue for the frontend, and MongoDB for the database.
Golang was chosen as the language for the backend as Troy was a big fan of Golang at the time and was trying to teach it and it's benefits to Anatole. Seems like it'd be much easier and cheaper to host a platform written in Go instead of Node.js, right?
The API was primarily spearheaded by Troy, and the website by Anatole and Melonify, who also developed the new version of the web extension. MongoDB was chosen as the database for the platform purely off of Anatole's vibes, as he was saying that relational SQL databases felt too "brittle" for him, and, as you may know him, he is an extremely stubborn person, and it is rather difficult to go against his words.
The combination of MongoDB with a rapidly growing user base started causing massive stability issues, where you couldn't properly use the website. While MongoDB is a fairly capable database, in the project it had some insane issues.
At the peak of popularity of the V3 API, the database was using around 70 gigabytes of RAM, while the EventAPI, the API used to update emotes and badges and paints in real time, used around 150 gigabytes of RAM.
What that resulted in were constant restarts of the service when it went out of memory, as well as the project being insanely expensive to run. At the time, the service was spread around a bunch of massive AWS-owned machines. It's not exactly easy to find a server that would have enough RAM to run a database that uses that much RAM, but it's not exactly about how easy it is, more so about how expensive it was, and expensive it was.
As a fun fact, it may seem very unrealistic, but it is also absolutely true; Anatole was manually giving out roles, badges, and paints to users when they subscribed. That is the actual true explanation for why receiving sub benefits took so long.
Some time after release of the V3 version of the platform, Troy left the project. That was caused by Anatole being abrasive, toxic and generally hard to work with.
The website was having a lot of performance and stability issues, though, which is why, at the time, Anatole contracted a developer to work on the backend side of the website, that being @broadeditz (known as, and referred to as Bread).
One big performance issue that was tanking the website at the time was the search engine, or rather, lack of it, within the platform. The website was just using the search capabilities of MongoDB, which meant that all search queries were going through the database. Bread ended up creating a project which extracted data from the Mongo database, and shoved it into Meilisearch, which sped things up drastically.
In addition to that, Bread also ended up disabling the quality of life feature of the website where you could see the roles and all the known users who have added an emote when you go on its page. As sad as it was to lose a feature like that, it was required due to the fact that the query to get that data was extremely inefficient in MongoDB, and was destroying the entire platform.
Bread didn't last long, however, and ended up leaving (/got fired?), right after this. Her performance changes made the website a lot more tolerable to use, however the switch to Meilisearch did result in the search quality being worse, as the searches were now a lot more fuzzy than you'd expect them to be.
You'd get a lot of unrelated emotes which you didn't want, as well as a tiny result size, where if you searched for a name you'd get around 1000 emotes worth of pages, which wasn't super nice if you were trying to search for something in a more granular way.
V3.5 and V4 era
This era started due to the fact that Troy, and his friend Lennart, were hired by the new owners of the platform to work on a new version and to make the platform a lot cheaper to run.
Troy said it was definitely possible to make it cheaper to run due to the inefficiencies in the previous iteration, and started chugging along on a complete full rewrite of the entire platform. Lennart, meanwhile, worked mostly on the frontend, the designs of which were created by ayyybubu.
They used SvelteKit for the website, custom Rust frameworks and libraries for the API, MongoDB for the database (once again), and Typesense as the search engine.
What's referred to as V3.5, is the brief moment in which the newly rewritten API and EventAPI were deemed to be sufficient to run the previous V3 version of the website written in Vue.
V3.5 returned the previously disabled user statistics for emote pages, subscription benefits were now automated and didn't require someone to do manual database mutations anymore, and the search behavior was also different now.
It was called V3.5, due to the fact that it was running the V4 version of the backend with the V3 version of the website.
After being completed, the rewrite featured the return of the previous V3 version of the API as well as the addition of a new, supposedly simpler and cleaner V4 API.
When Troy started working on the project, however, he had a goal to complete it before the beginning of the next year, and he did leave alongside Lennart, remaining the website in a mostly finished state.
This is the era we are in right now.
After Troy and Lennart left, the monorepo of the platform did receive some external contributions, as the platform was source available at the time, however that didn't last long. In the beginning of the rewrite, Troy was asked to not make the rewrite open source, even though he wanted it to be, so as a compromise, he added the Commons Clause to the license that was used for the application code, and a CLA (Contributors License Agreement) to the project as a whole.
What that meant, was that while the CLA ensured that all contributors to the platform had to sign an agreement which waived away all of their rights to their contribution, giving the code away entirely to the project leaving you with no power over the project, the Commons Clause meanwhile, is an additional clause which prohibits anyone unrelated to the project from selling the software, or selling a software which derives from a majority of the project, essentially forbidding any third party from hosting the platform for commercial purposes.
What the CLA is known for, however, is the fact that it is the perfect kind of protection to add to a project if you release it as open source, however plan on taking it down and making it closed source in the future, as it makes it so you don't have to ask all of the people who have ever contributed for rights over their code.
Which is, exactly, why it's funny that the platform became closed source in the future.
Despite being advertised as source available, the monorepo hasn't received a singular contribution from its developers since Troy and Lennart left, which may have some people assume that the platform as a whole hasn't changed in any way, but that is simply not true.
Not only is the website pretty different from the way it was before, the commit hash on the API is different from any hashes you can see on the public GitHub, meaning, the version the website is running is different from the publicly released source code.
Response from the 7TV api at the time of the creation of the article, note the commit hash.
Screenshot of the SevenTV GitHub repository at the time of the creation of the article, note that the commit hash in the response above does not match to any of the commits highlighted in the image.
That is explained by the fact that, at one point, when a feature was added to the source available repository, a developer slipped up, and you could see it originated from a SevenTV-Private repository version on GitHub.
7TV can absolutely, legally, take down the code of the platform and make it closed source, however, despite that, they still use the fact it is advertised as source available to receive occasional contributions from third party developers while not actually releasing any kind of recent versions of the code of the platform.
They are legally in the clear to do this, but it can be seen as disingenuous and false advertisement.
The Browser Extension
As an emote platform, 7TV has to have a browser extension, as most people watch streams in their browser. There have been 3 extensions throughout the lifetime of the platform, the V1/V2 extension, the V3 extension and the new V4 extension.
V1/V2
The V1/V2 extension wasn't remarkable in any way, besides it's "developer art" style, and it's attempt to support YouTube, which is somewhat novel compared to all the other different third party emote platforms.
It was written by Anatole and had some occasional contributions from different people.
V3
The V3 extension was written primarily by Anatole, Excellify and Melonify.
At one point, they were looking at the Twitch website and noticed a big problem. The Twitch website was extremely slow, and the chat even more so.
The frontend for Twitch is made using Next.js and React, and while it's definitely pretty possible to create a performant website/web-app using React, in factuality the Twitch website has got to be one of the laggiest/one of the worst websites in terms of performance, potentially ever.
They found an issue where if you entered even a singular key into the chat, the page was re-rendered by React about ~100 times (which obviously gets worse the more/the faster you type, as it re-renders that many times for EACH KEY PRESS).
As a solution, Anatole wanted to curb stomp the problem in a super drastic way.
The V3 version of the extension replaces the chat with a custom-built chat made using Vue by hooking into the Twitch website directly and emulating/imitating its design.
Controversy
- Incompatibility with other third party extensions.
While the V3 extension did admittedly increase the performance of the chat, what it also resulted in (besides massive memory leaks), was the fact that any other extensions which expect the twitch chat to be the native chat cannot hook into it.
People started complaining that their favorite extensions weren't working, and so Anatole added an on-boarding section onto the website which displayed extensions which were incompatible, thus getting people to uninstall other third party extensions so the only one they'd have would be the 7TV one. - Remote code execution.
When Anatole released the extension for the first time, 7TV got called out for making the extension break BTTV, after which Night, the creator of BTTV, started to block the user agent of the extension.
What this resulted in, was the fact that the users of the extension could no longer see any BTTV emotes, which was a big problem.
Anatole realized that Twitch and anyone could pull something like that on him, and he was worried. So much so, that he ended up making the extension have a fallback state, in which, if necessary, the extension could pull a JavaScript payload directly from the 7TV website and load it directly, bypassing any reviews or checks.
What this means, is that the platform could at any point remotely inject malicious code into the extension, which would result in the compromise of Twitch OAuth tokens of all the users of the extension, which would allow them to do anything with them, which becomes even scarier when you consider how many big streamers use the extension.
What that resulted in, was the fact that the extension got taken down on the Mozilla web extension store, remote code execution is a big attack vector and it is not allowed on any major web extension stores, so as a solution, Anatole tried adding obfuscation to the extension (which is also not allowed on all major browser extension platforms) to hide the remote code execution code from the reviewers of the extension, which seemingly shouldn't have worked, as obfuscation is just as forbidden as remote code execution, however somehow, it did actually work.
After Anatole left, however, while there WAS a decent chunk of time where remote code execution was still possible, to the credit of the later contributors, the remote code execution was axed out of the extension, and so, there is probably no more risk of remote code execution any more.
The New Extension (V4)
Not much is known about the new extension, besides the fact, that unlike the previous extension, it is not source available, and you cannot see its source code publicly. In addition to that, the new extension also started to request a permission to collect your "Browsing activity", and it is not yet entirely known for what reasons.