TankieTube is out of “beta” and everyone’s invited! feast-1feast-2

Definitions:

  • TT = TankieTube
  • PT = PeerTube
  • YT = YouTube

OpSec

  • Email - Make sure to register using an email detached from your legal identity (remember Stonetoss?).

    The software requires an email address, however, I’ve disabled the verification requirement. This means you can register using something like cum@fart.com and it will totally work—unless the address is already taken (in which case you should get better material!).

    You would need a real address, of course, to have the option of resetting your password. The only other thing I use email for is explaining and notifying users of any moderator actions I take against them, as a courtesy.


  • P2P - The peer-to-peer feature allows the software to scale tremendously well when serving the same viral video to many people at the same time (supposedly at least 1000 concurrent viewers, easily, with a wimpier server than ours).

    A downside of the feature is that it can reveal your IP to a subset of people watching the same video at the same time as you. [Read more]. Therefore, it is recommended to either:

    1. Use a VPN. Or,
    2. Deselect the P2P participation feature in the user settings menu.

Federation

TT users can search and view any videos from instances on the subscriptions list, and the instances following TT can view our vids. I occasionally browse the public index and look for new instances to follow (sometimes they’re a bust). LMK if you find any cool ones.

Mirroring vids, as in multiple copies on multiple servers, is done when instances implement something called redundancy, but I haven’t looked into that much yet.


Fifty Channels!

The major difference from YT is that TT users can create up to fifty (50) channels (the default is 20 but I bumped it up). Channels are analogous to Lemmy communities, except that PT doesn’t yet support shared channels with more than one author/user (I believe it’s a planned feature). Create a channel for every weird niche topic that you want!

I’ll eventually create a style guide. If you want to sync or archive a YT channel, then I’d prefer that you create a unique TT channel that corresponds to it for better organization.

PT has an automatic channel syncing feature, but I have it turned off right now because it was overloading the transcoding queue.


The TankieTube Homepage

The YT homepage is built by a sinister algorithm customized to distract and exploit you. The TT homepage contains whatever-the-fuck HTML I choose to type with my paws. Determining what to put on it will be a big and ongoing decision. If you’ve made a channel relevant to the site’s theme, send me a message and I’ll probably pin it!


About the Outro

The music is La Danse Des Bombes, a great song about the ecstasy of armed combat in defense of the Paris Commune of 1871, which I discovered thanks to comrade exotiquematter@tankie.tube. PT is French software, so I think that’s neat.

The sound effects are sampled from a video of the Al-Qassam Brigade resistance fighters in live armed combat against Israeli occupation forces. The sound effects correspond to a :hamas-red-triangle: hamas-red-triangle scene in the video.

Underneath it all is a 140bpm beat by “K1 The Producer”.


History & Goals

I started out with a $15/mo VPS (run by Nazis, as it turned out) and have migrated/upgraded the server twice since then. It’s now using the most powerful dedicated server available from Freakhosting at ~$230/mo💰🥴, because I wanted it to not suck. It has a Ryzen 9 7950x3D, which is ~32 times as fast as the first server. It still doesn’t have the transcoding throughput to keep up with YT syncing without creating a double-digit hour backlog.

The transcoding power can be boosted by renting additional servers for use as remote runners. It all depends on the amount of support the project can get…

Donation Link 🥺👉👈

I’m afraid to add it up, but I’m sure I’ve sunk at least $600 into various TT expenses since I registered the domain on 2023-10-27 and started playing around. I didn’t want to ask for donations until I was sure I knew what I was doing.

Another goal: making the PT vids embed properly in Lemmy!

  • Zorothamya [she/her, he/him]@hexbear.net
    link
    fedilink
    English
    arrow-up
    12
    ·
    2 days ago

    The software requires an email address, however, I’ve disabled the verification requirement. This means you can register using something like cum@fart.com and it will totally work—unless the address is already taken (in which case you should get better material!).

    fart.com:

  • ReadFanon [any, any]@hexbear.net
    link
    fedilink
    English
    arrow-up
    10
    ·
    2 days ago

    Very cool stuff, thanks for all your hard work!

    Just wondering if there’s a workaround for uploading where the format is one of the accepted ones listed but the upload fails with the error message that the file type is not supported?

    My instinct is to convert and try again but do you have an idea of what might be going on there? I’m not using a container file like mkv with some bizarre, obscure format within it either so I’m not sure what’s going on.

  • LarmyOfLone@lemm.ee
    link
    fedilink
    English
    arrow-up
    17
    ·
    2 days ago

    Just some random thoughts:
    It would be nice if firefox would support encoding to av1. Then the user could handle the upload conversion. Or maybe have a special app for peertube uploaders.
    And then you could just use a (cheaper?) seedbox to boost the video hosting instead of a dedicated server.

  • ProletarianDictator [none/use name]@hexbear.net
    link
    fedilink
    English
    arrow-up
    24
    ·
    2 days ago

    Also, a kind, certified security expert contacted me by email and offered me a FREE assessment of my private keys and he said they meet “top standards”!

    Please tell me this is a joke and you didn’t send some rando your private keys.

        • TankieTanuki [he/him]@hexbear.net
          cake
          OP
          link
          fedilink
          English
          arrow-up
          23
          ·
          edit-2
          2 days ago

          Okay, yeah, maybe I shouldn’t joke about this stuff (I love jokes though).

          The only person or thing that ever “sees” my decrypted private keys is my ssh agent (his name is Stanely—kidding!—it’s OpenSSH), and only for brief moments. I use ed25519 and they never leave the home Linux PC that generated them.

          I’ve hardened the server’s /etc/ssh/sshd_config by disabling password login and root login. It only accepts PubkeyAuthentication and MACs sha2-256 and sha-2-512.

          Only one user is on the allowList to use SSH, and I’ve double-checked the file permissions of/in the corresponding ~/.ssh directory: authorized_keys has a chmod of 0600.

          nftables blocks all inbound traffic except for the obviously necessary ports 80 and 443, 51820 for WireGuard, and my super secret, random port for my ssh logins (I know that doesn’t do that much but, meh). The standard SSH port 22 is blocked.

          • ProletarianDictator [none/use name]@hexbear.net
            link
            fedilink
            English
            arrow-up
            11
            ·
            2 days ago

            This is good practice for something like a desktop machine.

            Servers, especially explicitly communist peer-to-peer filesharing servers, require a degree of bulletproofing beyond this. Every chud or lib who can use the command line is gonna want to own your box, let alone more capable people or entities. All it takes is one CVE, and a PeerTube instance, nftables, and openssh is a lot of exposed surface area.

            Idk, maybe I’m more paranoid than most, but I’d at least look into containerizing this setup. There’s a lot of hardening that can be done, but containers probably give you the most bang-for-buck effort-wise.

              • ProletarianDictator [none/use name]@hexbear.net
                link
                fedilink
                English
                arrow-up
                2
                ·
                15 hours ago

                Not sure why, but I’d assume it’s because the devs don’t use docker in the development process, so it’s less tested. Also might be WebTorrent having networking quirks, but idk. Docs also say something about not being able to handle changing hosts, which might be relevant, but that wording is ambiguous, so I’d normally think they mean “hostname”

                • TankieTanuki [he/him]@hexbear.net
                  cake
                  OP
                  link
                  fedilink
                  English
                  arrow-up
                  2
                  ·
                  14 hours ago

                  They don’t (officially) support changing the instance domain name or object storage providers. It was probably trying to say that. The developers are French so the English translations are sometimes a little off.

          • Zvyozdochka [she/her, comrade/them]@hexbear.net
            link
            fedilink
            English
            arrow-up
            15
            ·
            edit-2
            2 days ago

            Exposing SSH to the public internet, key authentication only or not, is kind of scary. I’d really recommend only allowing SSH connections through a private VPN.

            Ignore the double post, website broken for a second and threw an error so I reposted boohoo

            • TankieTanuki [he/him]@hexbear.net
              cake
              OP
              link
              fedilink
              English
              arrow-up
              11
              ·
              edit-2
              2 days ago

              OH! nftables also drops any incoming ssh connection unless the IP matches the two or three VPN endpoints I use. They are public (paid) VPN endpoints though.

              I have another, smaller webserver where I plan to create a private WireGuard endpoint. Then incoming ssh could be restricted to the local 10.x.x.x whatever subnet used. Is that closer to what you had in mind?

              • ProletarianDictator [none/use name]@hexbear.net
                link
                fedilink
                English
                arrow-up
                9
                ·
                2 days ago

                Firewalling always seems so finicky. I’d say binding SSH to the wireguard interface is a better bet. I don’t let anything route outside wireguard unless I’m explicitly hosting it for the public.

                Highly, highly recommend containerizing your setup.

                Keeps your runtime environment nice and consistent:

                • Execution environment defined entirely in the container image
                • Networking confined to only the container interface
                • Data persists on only the very specific paths you mount into the container

                No need to fuck with root privileges because it’s all stateless. Just SSH as a user in the docker group to talk to the docker socket, and bind that to your wireguard interface. And if shit gets owned, you can nuke everything since it all comes from images and just restore a backup.

              • Zvyozdochka [she/her, comrade/them]@hexbear.net
                link
                fedilink
                English
                arrow-up
                12
                ·
                2 days ago

                Then incoming ssh could be restricted to the local 10.x.x.x whatever subnet used. Is that closer to what you had in mind?

                Something of that nature, you could instead bind SSH to that subnet so you don’t have to worry about the firewall shenanigans.