@CJ_Clippy

Celebrating Three Years

Added 2023-12-15 00:26:08 +0000 UTC

Futureporn started in December 2020. Originally it was a very simple webpage that could only serve one or two visitors at a time. I went on a journey to redesign and I've been iterating on the website ever since.

It's been one hell of a ride and I hope to continue for as long as I can. I love the grind, I love the challenge, I love learning new techniques and implementing them. When I started I was completely out of money but that didn't stop me. I believed Futureporn was a site that needed to exist in the world. To my patrons and all the regular visitors, thank you for making it possible.

Smashing The $600 Goal

You madlads! Thank you so much for the support! We've breached the $600 goal which means that I will be implementing Lovense vibration detection and playback for all VODs.

My plan is to use computer vision to do frame-by-frame detection of on-screen Lovense displays, storing a dataset of timestamps when vibrator(s) were active. With this data embedded in VOD playback pages, a script will interface with buttplug.io which activates the viewer's toy.

As always, ideas are cheap, implementations are expensive. There is a lot of work that needs to be done to make this a reality. In order to train a computer to detect all varieties of Lovense displays, I'll likely need some help annotating thousands of video frames.

I'll be writing more about this on Futureporn Discord when the time comes, but there are a bunch of prerequisite dependencies that need to be implemented first. The most pressing are some backend improvements which I cover in the sections below.

Restructuring for multi-vtubers, multi-vods

Futureporn is on it's way to become a lewdtuber archive with progress indicators showing how many streams have been collected out of the entire known list of past streams.

As I prepare to enable vod uploads, I'm thinking a lot about the situation where multiple vods of the same stream exist. This is an inevitablity because if only a low quality VOD is found, it will be uploaded.

In the spirit of completionism, later on a higher quality VOD could take it's place. Herin lies a problem with syncing up timestamps, because a complete length vod could differ from a lower quality partial vod.

The shortcomings of VODs

There have been a few instances in the past where Mel restarted her stream with a different video resolution than the start of stream. This ultimately meant we had two vods within one stream. Because of the varying resolutions, it didn't make sense to merge the two video files.

Presently, the way this is displayed in the UI is by displaying two separate VOD entries. This is inconsistent with the majority of other VOD entries, each of which normally symbolize one livestream. There is no visual grouping of two VOD entries which came from one stream.

The need for a Stream data type

Streams are an important data point which can be displayed on a page. Streams consist of vods. Some of those vods are uploaded by me, some of those vods are uploaded by community members.

Sometimes it's arguable which VOD is best. Maybe the resolutions captured were below the source quality. Maybe the higher resolution VOD was missing several minutes at the start. It's desirable to have choices in which VOD to play.

My idea is to add an additional page which displays streams, and all the vods that exist from that stream. The best vods can be upvoted and naturally float to the top.

TL;DR: multiple people uploading multiple vods of the same stream means we need a way to display them

This is only an idea at the moment, and any thoughts or feedback is appreciated!

IPFS Experimentation

IPFS can be slow sometimes, and streaming video is not practical. Sometimes it's better to download. Downloading the VOD via an IPFS gateway such as ipfs.io is possible, but error prone. Better ways to download are to use ipget, kubo, IPFS Desktop, but each of those programs come with their own intricacies and gotchas.

I think I can make this process better and more streamlined by putting a helia IPFS node directly in the webpage, so there is no need to run any separate software to download the vod you want.

Instead, a download button could exist on the VOD page which uses the helia node to download the VOD directly from other IPFS nodes.

I ran an experiment of this, but immediately noticed severe performance degradation. As long as helia was running, a lag was present in the UI, which was a major deal breaker. I'll revisit this idea in the future as the software improves.

Fixing things that were broken

I'm on the, "move fast and break things" grindset, and a lot of little things here are there have broken over time. I got to work and fixed a bunch of them.

CDN2 button is restored
gitea is restored
IPFS Cluster is restored
Pager bug was fixed
tags & timestamps were fixed
futureporn-scout was fixed

Improving the backend

futureporn-qa was a program I had been developing for several months. It's purpose was to verify that VOD records contained everything they need. IPFS Content ID (CID), Mux Asset, Thumbnail... If any of them were missing, the program would generate the necessary content and update the record.

The idea sounds simple in theory, but the execution proved difficult. I was spending weeks rolling a work queue system from scratch and integrating it, learning new things and constantly adding more features. Complexity was increasing and I wasn't getting any closer to my goal of building a robust backend to help Futureporn scale.

There's an engineering quote I love. "If the way is long, the way is wrong." One day I remembered this quote when I was feeling burnt out on what seemed like a neverending integration hell. My program lacked structure, I was re-inventing the wheel, and that wheel was spinning in place. I realized that this is not a good way to run a website that needs to move fast and pursue lofty goals.

I found an open source development tool called Windmill which I'm pretty stoked about. It does a lot to help the development process such as aforementioned work queues, but the most important thing for me that it offers is structure.

With Windmill's structure, I think it will help me spend less time worrying about how I'm going to run, deploy, and scale server-side code, and more time implementing features that matter to the user experience. That's the thought anyway. We'll see how this pans out in the coming months.

Learning from mistakes

Last month I experienced some data loss.

In an effort to save money on server rentals, I hurriedly switched VPS providers and lost my project management software (Gitea) in the process. I had backups, but I later learned that they were faulty. I assumed the database included everything important, but that was only part of the data.

The other part was the git source code repositories on disk, which were lost. Thankfully git being the distributed protocol it is, a copy of the most up-to-date code was on my local machine. Together with the Gitea database backup I had, I was able to restore Gitea. Not wanting to repeat the same problem ever again, I took extra time to verify that my new backup strategy was complete and valid.