Updated 2023-12-25.
In this doc is a list of ideas that I’ve had that I’m pretty sure I’ll never have the time to work on. But I wanted to list them out so that someone else that’s looking for a project to pick up can work on them.
If you start working on one of these projects in a way that I like and have gotten it to a sufficiently mature state, then send me a message and I might update the entry with a link to it. Only FOSS projects accepted.
PeerTube is pretty cool. It’s a video hosting software package with the goal of allowing popular videos to be shared between viewers to reduce load on the upstream server and to allow videos on one instance of PeerTube to be mirrored to other instances of PeerTube, in a way that allows all of the viewers across the network to share with each other. It does this with BitTorrent and a port of it to operate over WebRTC called WebTorrent. There’s also options that an instance administrator can specify specifc instances or users on other instances to always mirror all videos.
So I was thinking that someone ought to develop something that does mirroring like this but from YouTube. Different people would configure their instances to download from channels they watch, then maybe the streams would be signed, and then could be mirrored to others’ instances. Since it’s hard to authenticate the videos like how BitTorrent allows, this would take the form of a “friend-to-friend” network where you have a modest level of trust in the parties you’re peering with. This would be necessary since if it took off then it would probably invite frivolous litigation and would get YouTube pissed off. This kinda resembles a private tracker or a private Usenet newsgroup where you have to be invited to a close circle but then have free access to the content.
This would be especially useful in the coming years where it seems like YouTube might really take steps to kill adblockers. Someone on HN mentioned that if they keep it up too much, that people will regress to downloading videos from channels/topics that they’re interested in ahead of time so they can be streamed as needed.
Because so many people think that blockchains are the answer to auditability, someone outta show how they’re not.
The point is that there’s a ton of use cases where you really just care that some data was posted publicly around a certain time. There’s no settlement operation or anything like that, like maybe what you’d use a blockchain for. This includes all of the “supply chain” applications people are ascribing to blockchains that they absolutely should not be.
I’m imagining a core data model where you have users (or “actors”, maybe) and collections. Users post messages to a collection, and the server could share all the messages that have been posted to the collection. Users could also attach cryptographic signatures to their messages, if they wanted to have higher authenticity.
The server would continually be maintaining commitments of every message each user has published in merkle tree or some other convenient accumulator, as well as a commitment to an index of messages posted to each collection. Perhaps we could add a “tag” construct that can be attached to messages and indexed by the server separately.
On top of these core constructs, you could build anything. The simplest thing is a messageboard, where you can create threads (collections), post a reference to them to a forum (another collection), and users could post messages to the thread by adding messages to the collection. The supply chain example is another one that ought to fit into the data model pretty easily. The server can enforce well-formedness constraints for the high-level application it’s configured for, rejecting messages that don’t semantically match the data model for the collections they’re supposed to be for, the same as any web platform would. Optimizations to present a nice UI quickly can and should be made around the core constructs.
Generality is the key, the core foundation libraries should be very generic and make it easy to program whatever use case you’d want on top of it.
If you wanted to implement some basic voting system, you could extend this to support messages with anonymous senders you could have the server enforce that users specify cryptographic keys. Then questions would each be their own collection and the messages would be votes that include a ring signature over all of the users allowed to vote on a particuar question. Similarly, the server should be able to sign that it acknowledged a message when it’s submitted so that if the message isn’t present in a later dump/commitment, an alarm can be raised that the server might be misbehaving. This could be triggered automatically.
Periodically the server would take the master commitment to the whole system and post it in a public place where you can externally observe it. The purest place to do this would actually probably be OpenTimestamps, but it would also make sense to toot it on Mastodon, or put it on a Lemmy board, (or twitter or reddit), maybe email it to a public mailing list, or any other countless things that it could do.
Then bulk database dumps could be provided along with the updated commitment as a torrent, so anyone can mirror and crossreference the state. Anyone could take the database dump and reconstruct the state of the high-level application using it.