Now that I've annouced my plans to create the Forever Goldberg archive, I need to start applying my time towards the very large amount of work that it will entail. To make sure I don't get lost down the first (and every subsequent) rabbit hole that I'll encounter, I need to spell out a project plan and break down the learning and tasks such that I can always be moving forward.
Here's a first shot! I'm putting this out there so that smart (hive) minds can share any pointers with me that might save me time.
Milestones:
- Curate the archive: This one is pretty obvious, and I've already begun, but the terrabytes of files dumped on my hard drive don't count as an archive that would be useful to anyone. I'll be culling the files, renaming them, converting videos, standardizing the directory structures, and writing metadata about all of it. The big structures need to fall into place soon, but the detail work can extend for as long as needed. The archive can (and will) be released progressively.
- Develop a front end experience: Using Web2 or Web3 techniques, I can start to produce the front end that will be used for browsing the archive. This will include music players (hello OSMD!), an extensible but organized navigation structure, a concept for video playing and embeds (hello @threespeak and later @spknetwork), a music player (Audius?), and some cool goodies, like a mixer so that you can make your own mixes based on the many microphones we had present at each recording.
- Develop the NFT concept: While there are many approaches to take to creating NFTs around the archive, the one that seems the most obvious to me is to mint an NFT that represents the stewardship of one file or a collection of files. For example, an NFT that is the steward for the Aria of the Goldberg Variations, or an NFT that is the steward for the photos from a concert. The price of the NFT would be enough to guarantee a generous amount of permanent storage for that asset. Say 50-100 years. I'll use Arweave as a benchmark for this and the minium price would be at least as high for the Arweave storage of that asset. Other benchmarks would be to get contract quotes for Filecoin or Sia storage. The NFT minting and management will need tooling or I'll never get through creating thousands and thousands of them. And eventually, the tokens that come in through NFT sales will need to automatically go towards stewardship. Thus we'll need the DAO.
- Create the DAO: The DAO will manage the treasury long term. That means it needs to be able to monitor the archive and its assets to know which assets are at risk of losing permanent storage, and creating stewardship NFTs to sell to avert that risk, and to use the funds to secure more storage for the assets.
- Go to market: This will be done on a rolling basis. I hope to have ample functionality in place in 2022 to make a serious push for at least a significant part of the archive to be available and stored permanently, even if some of the above pieces have to be done in a more manual way.
So... what's my learning path through all of that ambition? Well, sadly, my skills on all fronts are either rusty, or outdated, or non-existent! So the path is going to be long.
The things I'm currently going to work towards learning and understanding:
- Typescript: OSMD is in Typescript, and there's a lot of front end work to be done in general, so TS will be useful. I'd recently started refreshing my JavaScript skills, and I think I'll continue by simply doing a bottom-up TS course instead.
- Then, with my TypeScript skillz in place, I will build on the work by jaredjj3 on the stringsync app which does basically exactly what I want to do, but with an architecture that is incompatible with my decentralized goals (go away, Docker!)
- An interesting side note at that point might be to look into generating pure client-side site search so that I can make the search index when I generate the archive's front end, and store it along with the archive itself.
- I will need to learn how to master ipfs.js so that the archive files can be pulled in via IPFS, and so that the same files that serve the web front end can also be served via SPKNetwork and Audius and Fission.codes etc. Creating multiple experiences for the content, all glued together by IPFS, is one of the fundamental design principles of the archive.
- NFTs: I need to learn a LOT more about NFTs in general:
- All the ERC721 test cases and structure
- How cool things like Async.music do their thing.
- Look at OpenLake: "Openlake supports the streaming of Music NFTs to hardware players and wearable devices"
- Master the Unlock Protocol or learn to do similar so that NFT holders can have unique experiences on the archive site.
- The DAO: This thing will need to do a lot, and a lot more clarity has to emerge before I can plan and architect it properly, but the basic idea is:
- The DAO owns the treasury
- The DAO can pay for $FIL or $AR or $SIA or XXX storage for any of the assets
- The DAO has an overview of how long storage is guaranteed and for what assets. Has triggers to take action if any asset risks disappearing.
- The DAO should use $DeFi and donations as a first line of defence against losing assets from the archive (ie ideally the treasury would be large enough that interest from staking could pay for ongoing storage renewals)
- The DAO can take measures to protect assets, namely issue new NFTs to denote stewardship of the assets.
Yo! Lots to learn! Looking forward to any suggestions you have.