> website where people can upload videos and others can play them in their browser. What would be actually involved in doing this?
The minimum would be a stateless server handling <input type=file>, storing it in the file system and responding with the path exposed by nginx or something. The user agent will take care of the playback, be it Firefox, VLC or mpv.
Now if your average users upload high bitrate videos but have shitty bandwidth, you'll need to transcode them down to lower resolution or higher compression to save them from rebuffering. Still, no client-side scripting needed.
In case their connection quality is unstable, HLS is finally necessary for on-the-fly adjustment of playback bitrate. This is the secondary purpose of JS viewers around the web these day (the primary one being DRM). The other possibility with custom viewer is to lighten the server load by enabling P2P transfering, e.g. in case of PeerTube. Realistically, you'd either deploy the barebone one I mentioned in the beginning or set up a PeerTube instance; anything in between is probably a waste of engineering effort.
This is only looking at another siloed alternatives, while ignoring federated protocols such as XMPP or Matrix. The problem can't be solved if an infra has to be the single point of failure:
1. It grows too large then it will get corrupted, e.g. Twitter/Reddit/Discord turning for surveillance capitalism and GitHub going for license laundering.
2. If it doesn't have many users it's likely to be discontinued.
On Matrix for instance, the room is replicated on all members' homeserver, and any admin can create a room alias (e.g. @foo:example.com creates #project:example.com, @bar:example.net creates #project:example.net). Like with emails, conversations can still go on even if some members' server goes down (and unlike mailing lists which are host on a single endpoint, there are multiple aliases).
One thing that has been bugging me for quite a while is that how a Zig library would be packaged downstream. AFAICT all Zig programs have to vendor their Zig dependencies which is a huge turn-off for Debian or Fedora developers. There is not an existing way to install Zig source files and IMHO this hurts reusibility (in a different way).
You missed the ease of digital replication: one needs not participate in a sexual act involving children to replicate child pornography. It's not like it's a healthy thing to consume such material, but the distinction must be made to avoid the concept being abused by digital publishers who think one sharing an ebook with a friend would cause lost in their revenue.
The minimum would be a stateless server handling <input type=file>, storing it in the file system and responding with the path exposed by nginx or something. The user agent will take care of the playback, be it Firefox, VLC or mpv.
Now if your average users upload high bitrate videos but have shitty bandwidth, you'll need to transcode them down to lower resolution or higher compression to save them from rebuffering. Still, no client-side scripting needed.
In case their connection quality is unstable, HLS is finally necessary for on-the-fly adjustment of playback bitrate. This is the secondary purpose of JS viewers around the web these day (the primary one being DRM). The other possibility with custom viewer is to lighten the server load by enabling P2P transfering, e.g. in case of PeerTube. Realistically, you'd either deploy the barebone one I mentioned in the beginning or set up a PeerTube instance; anything in between is probably a waste of engineering effort.