CompleteNoobs Genesis: A Long, Long Time Ago, on a LAN Far, Far Away…
I used to be a computer hobbyist, hopping from one shiny new thing to another. I’d dabble in everything, flashing routers, flashing phones, building Linux Live CDs, setting up virtual machines, learning as I went. Sometimes I’d find a golden tutorial online that walked me through the process perfectly. Other times, I’d wander the internet wilderness, cursing through “how do you fecking work?” moments, followed by “why don’t you fecking work?” and the dreaded “you were working yesterday, why are you fecking broken now?” But I kept at it, piecing together clues from forums and blogs until I finshed the quest.
One day, I needed to reflash my router. I couldn’t remember how I did it last time, and my trusty tutorial had vanished from the web. Search results turned up half-baked guides or dead links. Frustrated, I started writing my own tutorials, storing them in CherryTree, a note-taking app. As my collection grew, CherryTree got sluggish(indexing), so I switched to Zim, which was faster.
Some tutorials were copied from the web (the ones that actually worked), some were tweaked, and others I wrote from scratch. Writing docs is tedious, especially with dyslexia, and I’d reformat my computer over and over to ensure the steps worked from a fresh install. But through iterations—draft after draft—and reiterations—retesting every step—I turned “what idiot wrote this?” into guides so clear I could follow them intoxicated. That became my standard: if I can do it SuperBaked, it’s noob-proof.
Over the years, I learned some cool stuff:
Restoring just my windows 7 (gaming) partition, to a clean install with all drivers and games installed from clonezilla backup on a trible boot without risking my linux and freebsd partitions.
On FreeBSD i could built Raspberry Pi images from source on my x86/64 desktop, created a jail (lightweight virtual environments) to compile software from the ports tree for the RPI arm architecture, chroot into image to config everything i needed (local IP address, username, ssh-key, config PKG to use repo/jail, and more) so all i would need to do is insert the sd card into the RPI, plug in ethernet and power and was ready to go headless, already knew which IP it was going to be assigned to login with.
On FreeBSD ran VirtualBox with networking configured so each virtual machine had its own IP on my local network. (pain to workout, easy once learned and noted)
I made a custom Linux Live CD from Knoppix 7.2 for crypto (at the time unaware it had the Heartbleed vulnerability) .
This was some of the many things i learned both the hard way and easy way over the years.
Some of these projects took ages to master and document. But I didn’t share my tutorials, not realizing their value. Then disaster struck: I lost everything. I won’t bore you with the details, but it was devastating.
With a good walk through it was sooo easy to reproduce something (a walk in the park).
With my docs gone and a memory like a sieve, I was back to square one, scouring the internet for answers I’d already found, hitting the same bugs, knowing I’d solved them before but forgetting how (a longer journey, filled with side quests).
I stepped away from computers for a few years, doom-scrolling on my phone. When I returned, I missed my docs. One day, When i needed to transfer files from one computer to another I forgot how to use scp and looked up the man page. The man scp page was a wall of jargon—no simple example in sight, all i needed was a simple example and i was good to go.
So i started from scratch again, because there is great value in good docs and walk throught which can be hosted locally, that you own and can edit freely and privately and easily.
Got the Name 'CompleteNoobs' from a friend during a walk and talk, perfect fit for the project (we all start as noobs), and perfect name to expand project to cover pretty much any subject at later date.
And now/currently its a mediawiki called CompleteNoobs.com.
Why Mediawiki? Well its the best option i can find at current time.
After all these years why is completenoobs still at this poor grade state?
Many reasons.
Well thats much of the Genesis story/history of completenoobs to current date
The YouTube Wake-Up Call
YouTube’s been a lifesaver for hosting content videos, no cost and super easy to use. But when one video got a copyright dispute, poof—all my content went offline for 2-3 days. Even though it resolved itself, it showed me we need control over our videos, images, and files (like block.tar.gz backups). Relying on services with more power than us isn’t the best idea, especially if the rumours about lizard peope turn out to be true. CompleteNoobs is about empowering you to self-host, and this side quest is our step toward that.
The Dream: IPFS + Blockchain
Plan A: Use IPFS to store our files and a blockchain to track them. I thought, “Sweet, I’ll knock this out in a weekend!” Nope. I’m a noob, and this could take months at best but probably years. But it’s worth it to make CompleteNoobs unstoppable, and we’ll write a tutorial to help you reproduce it, also content creation, double win.
Here’s the plan: Store file details on a blockchain in a database with these fields:
signing_key: A digital signature proving CompleteNoobs signed the file.
file_name: The file’s name (e.g., tutorial.mp4) for easy reference.
file_size: Size in bytes to check if it fits on our servers.
ipfs_hash: A unique ID (called a CID) to find the file on IPFS and verify it’s legit(also counts as a checksum - another sha256sum field maybe added).
split_ratio bitcoin_address/s: A way to tip creators via Bitcoin (maybe using Lightning Network for fast, cheap payments). If multiple creators made the file, split_ratio divides the tip (e.g., 60% to Alice, 30% to Bob, 10% to gramma_nazi).
The Tools We Need
To make this work, we’ll build two programs and a wiki plugin:
IPFS_NODE Program:
Runs on a server (probably in Python or Bash).
Takes a list of IPFS hashes, downloads the files, and hosts them on the server.
Example: Tell it to grab tutorial.mp4’s hash, and it keeps the video online.
NODE_MANAGER Program:
Runs on one server (or two for backup if one crashes).
Manages 8 IPFS_NODE servers, splitting files so each is hosted on at least 3 nodes for redundancy.
Checks hard drive space and warns if it’s low (e.g., “Yo, only 10% left!”).
If a node goes offline, it copies files to a new node. It could auto-spin new nodes on a VPS (like vultr, DigitalOcean, cloudzy) if we get fancy.
Example: If tutorial.mp4 is on nodes 1, 2, and 3, and node 3 dies, NODE_MANAGER puts it on node 4.
MediaWiki Extension:
A plugin for CompleteNoobs’ wiki to:
Play IPFS videos like YouTube embeds (e.g., <ipfs_video>CID</ipfs_video> tag).
Show IPFS images (e.g., <ipfs_img>CID</ipfs_img> tag).
Offer download links for files like block.tar.gz.
Pulls files using their IPFS hash, keeping the wiki lightweight (eg., <ipfs_download>CID</ipfs_download>).
This setup is Good for two reasons:
Forking Freedom: CompleteNoobs’ XML export includes all content, so anyone can fork the wiki (e.g., FooWiki). They can copy our signed files, add their own signing key, and run their own IPFS_NODE and NODE_MANAGER. Forking is as easy as cloning a repo!
Signed and Secure: Every file we host is signed with the completenoobs key, so you know it’s ours. Forkers can sign their own files, building their own database while keeping ours intact.
If we wish to pull anything into CompleteNoobs, we just sign the content and its added to are database, maintaining meta data as to who donations go to for page content we pulled in.
Why i am not doing it!
Turns out its a feck load of work with trial and error (why are you not fecking working you fecking feck) moments. Limited time and working solo, with no capital to hire assiants, too many ropes to pull, does not make this realist at current time.
One of the biggest problems with open-source free software and projects is funding and rewards. Working for free is rewarding in its own way, but it’s not sustainable—being burned out and broke is no fun.
As Adam Curry (the Podfather) explains in the Value for Value model (V4V), you put your full product out there for free, and if people find value in what you do, they can return value through Time, Talent, or Treasure. Everyone involved is a producer, even consumers. If people consume your content and don’t return value, that’s fine—it’s their right. By putting it out there for free, everyone can discover and use your product or content. The more people discover it, the more likely you’ll receive value back.
Consumers who find value in a project can contribute what they can afford, while creators benefit from a broader, more inclusive audience.
The problem with current donation models is setting and distributing a budget. I can’t buy everyone a coffee! Years ago, Flattr had a great model where I could put what I could afford—say, $20—into an account and select all the services or projects on their platform that gave me value. At a set time, the money would be split between those services, projects, or developers. It wasn’t perfect—not all the software, podcasts, or other free/libre content I used was on the platform—but for budgeting and contributing something, everyone I selected got a piece of the pie. It was the best platform out there (before they changed their model) for returning value to projects, people, or content that gave me value within my budget.
Flattr was pre-Bitcoin. Now, with Bitcoin Layer 2 (Lightning Network) and the Podcasting 2.0 platform, we can see micro-donations in action again. You can see the split of a transaction—money dropped on a project, release, or podcast, divided among co-producers of the creation.
This model can extend beyond podcasting. It can include stablecoins and cover all free/libre software projects and content. With certain licenses (libre), the content is owned by everyone, so if you get value from it, you can contribute something back in return. This helps improve and maintain the software and content you co-own.
Instead of building everything from scratch, we can work with existing libre content.
MediaWiki is basically hosting and editing software for a wiki’s XML file. Since it’s libre content, we can modify MediaWiki to create a version that fits our needs.
Can be modified to skip username and password logins, using a username (display name) and public key instead, only accepting content or edits signed by that key.
MediaWiki can be updated to include [username[pubkey]] in the XML file.
Can also modify MediaWiki to check a blockchain, verify the public key, and see if the user holds tokens or coins for editing rights before allowing an edit or creating a page.
The amount of coins or tokens held gives seniority for editing, moderating, voting or admin rights.
Non-token holders can suggest page edits or new pages, which token holders can vote to add to the wiki. If a suggestion is accepted, the user who suggested it gets credit and can receive tips or tokens as a reward for their contribution.
To tip content, we need a database to track each piece as an asset with a unique identifier and info on how to send and split tips.
Wiki Pages: Use the page title, revision ID, or a content hash. MediaWiki already gives each page a unique ID, so these are ready to go.
Media and Code: Pictures, videos, and code (like .tar.gz files) are hosted on IPFS, which provides a unique ID called the IPFS hash.
Unique Identity: Every piece of content—like a wiki page, a code block (each block in a walkthrough can have its own wiki page if needed), picture, video, audio, etc.—gets a Unique Identity to track it.
Bitcoin Address(es): Each Unique Identity is linked to one or more Bitcoin addresses for receiving tips.
Share Split: For each Unique Identity, store the Bitcoin addresses and a Split Weight to decide how tips are divided if multiple people (like co-creators) share the tip.
A wallet (or a feature in a wallet) does the following:
Make a list of assets the user selects (a MediaWiki extension adds an “Add to Producer Wallet” button on each asset).
Checks Database: Takes the asset’s Unique ID and Bitcoin address from the wiki page and checks they haven’t been changed by a bad actor by verifying the asset is linked to the same address on a blockchain backup.
Score each asset from 1 to 100, since not all assets have equal value.
If an asset has funds split between two or more people, users can see the suggested split ratio for each contributor and what each person did for the asset. Users can override or tweak the suggested split—every user is the boss of where their funds go.
Set a date and time for sending funds, with an option for recurring tips (like weekly, monthly, etc.).
On the set date, the wallet’s funds are split based on the asset scores and sent to the linked Bitcoin addresses.
All transactions are recorded on a public ledger for transparency and to track things like top tippers or trending projects.
Adding [username[pubkey]] to the MediaWiki XML is simple, and I like simple, but there’s a catch. Bitcoin’s transaction fees can make micro-donations tricky. Appending other blockchains and their keys to the XML isn’t ideal either—new chains keep popping up, and we’d have to keep updating the system. But the Bitcoin pubkey/private key pair is super valuable. The pubkey isn’t just a Bitcoin address; it’s also an ID that comes with a password (the private key) we never need to see, store on our servers, or have leave the user’s possession.
We can use this to create a new service on tipshares.com:
For each unique pubkey, we create a [email protected] address that can receive donations in different coins or assets, like Bitcoin Lightning, XRP, Ether, EOS, stablecoins, and more.
The [email protected] address can be watched to track if it gets donations and in what form (e.g., BTC, stablecoins).
Only the holder of the private key paired with the pubkey can control these donations by signing requests (like transfers or withdrawals).
This lets contributors receive all kinds of coins or assets, even ones not compatible with Bitcoin, while still using the Bitcoin pubkey as their ID.
A backup of the [username[pubkey]] list is signed and stored on a blockchain, so anyone can verify the link between usernames and pubkeys without trusting our servers.
Donating should be fun, rewarding, and benefit everyone involved, not just a one-time thing.
There are ways to make tipping more exciting for patreons and creators.
Lottery: A percentage of tips for an asset goes into a lottery pool, run by a smart contract. Tickets are given based on how much you tip, and winners are picked randomly (daily, weekly, monthly, or yearly). It could be one big winner or split among a few—lots of ways to play! This makes tipping fun and gives everyone a shot at a bonus.
Badges and Recognition: Tippers get digital badges or shout-outs on the wiki for supporting projects. For example, a “Top Tipper” badge or a mention on the asset’s page (like “Supported by [username]”). This rewards tippers with community cred and encourages more people to join in, boosting visibility for creators.
Voting Power: Tippers who donate more (or hold tokens) get a say in project decisions, like voting on new wiki features or which suggested edits get added. This gives tippers influence, helps creators prioritize community needs, and keeps the wiki open to everyone (non-tippers can still suggest edits).
Creating or liberating educational courseware can be crazy expensive for one person or a small group, but with crowdfunding, we can make it happen together and benefit everyone. Here’s how TipShares can use crowdfunding to commission new courses or free up existing ones under libre licenses, making learning accessible to all.
Why Crowd Fund?
Raising funds as a group is way easier, especially for subjects tons of people value—like homeschooling, self-study, or school curriculums. If there’s a hot topic with a big market (think coding, math, or language courses), we can pool money to create new courseware or liberate existing ones. Libre licenses mean anyone—schools, businesses, or language groups—can tweak the content to fit their needs, with most of the heavy lifting already done. For example, imagine commissioning a computer science course under a libre license that everyone can access and adapt.
Option 1: Liberating Existing Courses
There are awesome courses on platforms like Udemy, like the 100 Days of Code course. We can ask the creator (the rights holder) how much they’d need to release their course under a libre license, so we can host it on our downloadable wiki and anyone else can too. Say they ask for $500,000 (just a guess—market prices unknown, we are noobs). We’d launch a blockchain-based crowdfunding campaign with a smart contract: if the $500,000 goal is met, the funds go to the creator, and the course is released under a libre license for all to share, fork, or edit. Funders’ public keys are recorded, and they split 50% of any future donations the course earns on TipShares, with the original creator getting the other 50%. If the goal isn’t met, funds are returned.
Option 2: Commissioning New Courses
If a group or creator wants to make new courseware but needs funding, they can pitch their idea—say, $50,000 to create a libre coding course. They’d show their past work or a plan to prove they can deliver. People choose whether to fund them, and if the goal is met, the course is created and released under a libre license. Future donations could split 50/50 between funders and creators, or even 40/40/20 (20% for new contributors who improve the course). This gives creators a clear budget and backers a stake in the project’s success.
Why It’s a Win for Everyone
Crowdfunding libre courseware can be cheaper than buying proprietary courses, especially when more people chip in—$10 from 10,000 people adds up fast! Backers might earn some money back if the course pops off and gets tips, or they can just feel the karma of being a producer. Libre content means anyone, anywhere—whether they earn $500 a month or $500 a day—can access it. If a course has flaws or needs updates, anyone can fix or improve it and share the changes. Plus, there’s an open market for hiring folks to add new modules or features to the course, keeping it alive and growing.
Delegated Proof of Stake (DPOS) is our pick for running the CompleteNoobs wiki and TipShares, at least for now—we’re still learning as we go! It’s a great way to keep things fair, open, and spam-free while giving the community control.
Why DPOS?
DPOS lets token holders vote for delegates to manage the wiki, balancing openness with security. If bots or bad actors buy tokens to spam, we can ban their accounts and freeze or burn their tokens—a costly deterrent for troublemakers. If someone’s banned by mistake, they can appeal to delegates for a fair review.
Token-Based Editing
Users with a certain number of tokens get rights to post, edit, or add content to the wiki. More tokens can also grant voting power to set suggested donation splits (like the 80/20 or 40/40/20 splits in Beyond Tipping and Crowd Funding). But the end user is always the boss—they can pick the suggested split or decide their own when tipping, keeping full control over their funds.
Open to Everyone
Non-token holders can still suggest new pages or edits, which token holders vote to approve for the wiki. If a suggestion is added, the non-token holder gets credit and can earn tips or tokens for their contribution. This lets them build up tokens over time to post or edit directly, making the wiki inclusive for all.
