The BRAIN Network
A proposal to share information anonymously and freely
The current ways of filesharing have problems and flaws, allowing governments and/or copyright agencies to brings down the hammer on filesharers. And that is a thing we should all worry about. Why? Not so much because of sharing copyrighted content. It's more about the entertainment industry, copyright agencies and governments refusing to adapt to a rapidly changing world. Instead of adapting to the new game, they do everything in their power to go full 1984 on the internet and our freedoms. All in the name of copyright. And this, in my mind, is a very bad and dangerous thing. To quote Rick Falkvinge: “My undying question is therefore why people waltz along with it instead of smashing these bastards in the face with the nearest chair.” He makes it very clear that we can never allow them to win.
So, when Peter Sunde said the following: “While it might look like torrenters are are still fighting this battle, We have already lost.” That made me realise that we are in big trouble. We desperately need to fix this.
This document is a proposal to a new way of sharing our files and information.
But first, let us examine the problems with the current methods of filesharing. Right now filesharing is mostly done in two ways.
The problems with torrents
- They rely on trackers. Trackers, as the name suggests, keep track of who is downloading or uploading which file to whom. Take down that tracker and the torrent doesn't work anymore. You also don't want anyone or anything keeping track of who has what and is uploading or downloading it.
- They rely on websites to share them. These websites become a huge target for governments and copyright agencies. We all know about the Piratebay.
- Creating a torrent is not that easy. You need to give it a tracker. And not many people know which tracker they should, or can, use.
- Sharing a torrent is cumbersome. You need to register with some shade torrentsite and upload your torrent there. And if that site is taken down, the archive of torrents goes with it.
- Downloading a torrent is also a hassle. You need to visit (and possibly register with) some shady website, with lots of questionable banners. They will likely try to track you with cookies and possibly do some other nasty stuff.
- All uploaders and downloaders know each others IP-address This allows any copyright agency to share a movie (which is legal for them) and get a list with all the IP's that downloaded (part of) the movie. Then they can demand to know who was behind those IP's at that given time. And before you know it, you have a lawsuit on your hands. Which happens.
The problems with usenet
- You often need a payed subscription with a usenet provider to download anything in the first place.
- It's very chaotic and not very user friendly. This is very discouraging to a lot of users from actually using it.
- Because of it's chaotic nature, you need good indexers to make sense of all the mess. These indexers often charge money too. And in most cases it's (very) hard to get into, because they keep a closed community. Try to get an account on dognzb or, God forbid, nzbs.org. These indexers are also huge targets to be taken down. Nzbmatrix, anyone?
- All files on usenet are only there for a limited time. Sure, it's often several years, but still. Try to download an older file and you're very likely out of luck. A problem that torrents don't have. Or at least, a lot less.
- It's very centralized. If someone uploads a file, the government, or a copyright agency, can demand that file to be taken down. Which actually happens a lot.
I think it's safe to say that the current state of filesharing is a huge mess. It's far too easy to be attacked and puts you at legal risk. Sure, Popcorntime worked great. But it relied on the underlaying torrent network and exposed the IP-address of all it's users, putting them at legal risk. Often without these users realizing it. And of course we all know what happened to Popcorntime. It's dead.
Instead we need a system that protects both uploaders and downloaders, is very decentralized, easy to run, easy to use and hard to be taken down.
The BRAIN network
Imagine a small server, running on the internet. This server takes small messages and shares them with other servers, it stays in contact with. They all act as nodes, together forming a huge decentralized network, constantly exchanging messages with each other. I like to call such a server a BRAIN-cell. A small node on the BRAIN-network. BRAIN simply stands for Broadcasting Ripples And Information Network. It's not at all an attempt to kick Tim Kuik and Brein in the balls. Or maybe it is... You decide.
The BRAIN-network has the following components.
|BRAIN-files:||Files with information about actual files, people want to share. A bit like torrents, only much simpler.|
|BRAIN-requests:||Request for blocks. Blocks are parts of the shared files.|
|BRAIN-reponses:||Responses to the BRAIN-requests.|
|BRAIN-searches:||These are like requests, but are meant to ask for certain BRAIN-files.|
|BRAIN-boxes:||Containers, containing requested (but encrypted) blocks.|
|BRAIN-cells:||A small dedicated and headless service/daemon. It connects to other BRAIN-cells and BRAIN-clients. It handles all the previously mentioned packages.|
|BRAIN-clients:||Connect to one or more BRAIN-cells. They are userfriendly GUI-programs that allow users to interact with the BRAIN-network.|
A BRAIN-cell does several things
- Seek out other BRAIN-cells.
- Accept and broadcast BRAIN-files onto the BRAIN-network.
- Accept and broadcast BRAIN-requests onto the BRAIN-network.
- Accept and broadcast BRAIN-responses onto the BRAIN-network.
- Accept and broadcast BRAIN-searches onto the BRAIN-network.
- Accept and temporarily store BRAIN-boxes. These are not broadcasted onto the network. Instead, a (much smaller) BRAIN-response is broadcasted, informing the network that a BRAIN-box is ready for pickup.
- Communicate with BRAIN-clients.
When reading “broadcast onto the network”, you're probably thinking: “DDOS”. And you would be right, that is an issue that needs to be addressed. And it will be addressed later on. Please, bear with me. We'll get into more details about that later on.
A BRAIN-cell should be simple, small and lightweight. Anyone should be able to run one. Perhaps even behind NAT, without forwarding any ports. If somehow hole puching could be used? And it should have a simple configuration. An example configuration can be found at the bottom of this document.
A freshly installed BRAIN-cell should come with pre-configured settings. Perhaps a user could choose from a few predefined settings. Like: huge, medium, small, very small.
Now this thing comes online and starts broadcasting: “Hi, I'm a BRAIN-cell, running on IP-x and listening on port-y.” Once it finds other BRAIN-cells, they acknowledge each other and start to exchange BRAIN-files, BRAIN-searches, BRAIN-requests and BRAIN-responses. There is no need to catch up with any history, perse. Like, for example, the blockchain. Any BRAIN-cell should be able to just come and go. Become part of this huge decentralized BRAIN-network and leave it anytime it wants.
To be honest, I have no idea how a BRAIN-cell would actually find other BRAIN-cells. Maybe one should give it one or more IP's of some BRAIN-cells that are already in the BRAIN-network. Or it scans the network on a default port. Once it is in contact with some BRAIN-cells, it could request IP's of more BRAIN-cells they know and seek out those. Including ones that listen on a non-default port. And it is of course not needed to actually know all the other BRAIN-cells in the entire BRAIN-network. As long as it knows a few, that should be enough. It can broadcast BRAIN-requests, BRAIN-searches, BRAIN-responses and BRAIN-files to those BRAIN-cells. And they wil broadcast it to the BRAIN-cells they know. And so on.
Dont worry, we'll get to the part on how this broadcasting thing is not a DDOS.
A BRAIN-file is simply information about a certain file. Let's say you want to share Big_Buck_Bunny_1080p.mkv. You just create a BRAIN-file for it and broadcast it to the network. This BRAIN-file is actually a simple text-file that contains information about Big_Buck_Bunny_1080p.mkv.
Big_Buck_Bunny_1080p.mkv gets chopped into smaller pieces, called blocks. It can't be too many blocks, because this would increase the size of the BRAIN-files. And they need to be kept small. It would also increase the amount of BRAIN-requests and BRAIN-responses on the network. And they need to be kept as low as possible.
I think that every BRAIN-file should have a maximum amount of blocks. Maybe around 100 would be right. BRAIN-files exeeding this limit should be rejected. That means an 8GB mkv file would have 100 blocks of 80MB each. I suppose that would work nice. And it is not mandatory to have exactly 100 blocks. Lesser blocks would be better. A 1GB file could be chopped into ten 100MB blocks.
For each block a strong and unique hash is calcultated, that goes into the BRAIN-file. In the rare occasion there is a collision, that shouldn't be a problem. The network can deal with collisions just fine.
And lets split this BRAIN-file into two pieces, to improve efficiency a little. A header and a body. The header would contain something like this:
|Name:||The name of the file.|
|Description:||A small description of the file.|
|Type:||Video, audio, program, text, graphical (jpg,png,etc) image (ISO,etc), other, etc.|
|Category:||Movie,Tvshow,SciFi,Romance,Rock&Roll,Game,PS4, etc. Multiple things can be put here. Like: tvshow,comedy. I suppose a BRAIN-client should offer a buch of predefined options, that can be selected by the user. It would keep things consistent.|
|Size:||The size of the file.|
|Signature:||A cryptographic signature to proof the validity of this BRAIN-file. Upload groups could use this to proof the file came from them. If they sign every file with the same key, the internet would pretty soon know which signatures are good and which aren't. This is ofcourse on a totally volentary basis, because it could be risky. But hey, it's nice to have the option. Right? |
This can also be used to act as a channel, like a YouTube channel. Someone can create content, sign it with their key and send it to the network. This could be a video, a text, it doesn't matter. Anyone interrested in that content can tell his/her client to automatically download anything signed with that signature. And it will act like a subscription to a channel. This allows anyone to say anything, without fear of censorship. Noone can block it. This would offer a very cheap and easy solution to get around the censorship, that seems to get more and more agressive on social media networks.
|Private:||Private BRAIN-files should not be broadcasted onto the network. They can be shared via other means, like email. The default should be no.|
|Hash:||A strong hash of the file.To check the complete file, once you have it.|
|Timestamp:||When was this BRAIN-file created?|
|NumBlocks:||The total amount of blocks that make the file.|
|BlockSize:||The size of each block.|
|Nonce:||A random value, to change the hash of the header.|
A header should have a max size. And any header bigger than that should be rejected by the network. It will prevent people from flooding the network with ridiculously large headers, that have Tolstoys 'War and Peace' pasted into the description. It will force people to keep them small.
The body should contain information about the blocks. Like this:
|Header:||A strong hash of the header, to make sure the body really belongs to the intended header.|
|Nonce:||A random value, to change the hash of the body (or actually, the complete BRAIN-file).|
|Block1:||The hash of Block-1.|
|Block2:||The hash of Block-2.|
|Block3:||The hash of Block-3.|
Yes, these files are basically torrents. But in contrast to torrents, they are much simpler. They don't require any information from the user, to be generated. Except for some trivial information, like a title and a description. For example, you don't need to enter a tracker. The process should be very straightforward and fully automated. A file goes in, a BRAIN-file comes out. Anyone should be able to do it with a few mouseclicks. You also don't need to create an account on some shady website, to share your newly created BRAIN-file. You can just send it to the network and you're done.
But now comes the tricky part.
The hash of the header (the one that goes into the body) shouldn't be easy to create. It should start with a couple of leading zero's, just like the hashes of the block-chain, in the Bitcoin network. Obviously not that hard, that it would require several gigahashes-per-second. Just hard enough that it would take a normal PC a minute or so. While generating the BRAIN-header, your PC will just keep changing the nonce, until it finds a satisfying hash.
Now the body is created and attached to the header, to make a complete BRAIN-file. And for the complete BRAIN-file a hash is calcultated too. This hash should also start with a couple of zero's. After another minute or so, we have a complete BRAIN-file, that gives a certain hash. Beautiful! Now it can be send to the BRAIN-network.
This seemingly stupid keep-changing-the-nonce-until-we-get-a-cool-hash, is proof of work. Just like the Bitcoin-network uses, only a lot less difficult. It won't be much trouble for you, just generating one BRAIN-file. But it will give spammers a much harder time to flood the network with bogus BRAIN-files. The more difficult the hash of your BRAIN-file, the more likely people will trust that your BRAIN-file is actually what you say it is.
It will also be used to assign a priority to your BRAIN-file and keep down the load on the network. More on that later.
I don't recommend the use of SHA-256, by the way. Because there are thousands of obsolete Bitcoin-ASIC's out there. Although they are obsolete for Bitcoin, they could easily crank out a serious amount of bogus BRAIN-files, with some insanely difficult hashes, completely derailing the whole idea. I guess Scrypt would be a better choice.
And I guess the difficulty for BRAIN-requests, BRAIN-responses and BRAIN-boxes should be less difficult. If a file has 100 blocks, that would mean 100 minutes for the BRAIN-requests, 100 minutes for the BRAIN-reponses and 100 minutes for the BRAIN-boxes. Not very practical.
A BRAIN-request, you guessed it, requests a certain block. It should look something like this:
|Hash:||Part of the hash of the desired block. But the entire hash is perfectly valid too. More on that later.|
|Key:||The public key, that should be used to encrypt the block and create a BRAIN-box.|
|Timestamp:||To identify old BRAIN-requests and prevent anyone from flooding the network with old files (without doing any proof-of-work).|
|PrefCells:||Optional. A preferred BRAIN-cell, or a whole list of them, where this BRAIN-box should be posted. If omitted, use any BRAIN-cell. This should be IP-adresses, with the corresponding ports. There should be a limit, to prevent large BRAIN-requests. Maybe 10 would be nice. The order in which they are given also determines the priority.|
|Nonce:||A nonce to change the hash, until the request gives a hash with a certain difficulty. Just to prevent spammers from flooding the network with lots and lots of bogus requests. And to determine it's prority.|
A container, that contains a requested block. It should contain the following information:
|Block:||The actual requested block. Obviously encrypted with the public key, that came with the request.|
|Timestamp:||To identify old BRAIN-boxes and prevent anyone from flooding the network with old files (without doing any proof-of-work)|
|Nonce:||A nonce to change the hash, until the box gives a hash with a certain difficulty. Just to prevent spammers from flooding the network with lots and lots of bogus BRAIN-boxes.|
Requests for certain BRAIN-files. Either a specific BRAIN-file, of BRAIN-files that fit certain criteria. They could look like this:
|Hash:||The hash of the desired BRAIN-file. If omitted, use the other information.|
|Timestamp:||To identify old BRAIN-searches and prevent anyone from flooding the network with old files (without doing any proof-of-work). In contrast to the timestamps on the other packages, it should be generated randomly between the current time and a timestamp in the past, to prevent anyone from determining it's origin with too much precicion.|
|Phrase:||The search-phrase that the name and/or description of the desired BRAIN-file should fit.|
|Nonce:||A nonce to change the hash, until the box gives a hash with a certain difficulty. Just to prevent spammers from flooding the network with lots and lots of bogus BRAIN-searches. And to determine it's prority.|
This informs the network that a certain BRAIN-box is ready for pickup. It could look something like this:
|Hash:||The hash of the original request.|
|Timestamp:||To identify old BRAIN-responses and prevent anyone from flooding the network with old files (without doing any proof-of-work)|
|Cell:||The BRAIN-cell where the BRAIN-box is waiting to be downloaded. This is the straightforward IP-address and port of the BRAIN-cell. No beating around the bush, the whole network knows exactly where this BRAIN-box can be downloaded.|
|Nonce:||A nonce to change the hash, until the respond gives a hash with a certain difficulty. Just to prevent spammers from flooding the network with lots and lots of bogus requests. And to determine it's prority.|
Acknowledging between BRAIN-cells
When a BRAIN-cells finds another BRAIN-cell, they do the following
- Exchange keys, to ensure encrypted communication among each other.
- Echange the heartbeat (see the example configuration file at the bottom of this document).
- Exchange IP's and portnumbers of the BRAIN-cells they know, if requested.
Any BRAIN-cell should honor the heartbeart of other BRAIN-cells. A BRAIN-cell that doesn't do this should be blacklisted and ignored. At least for a while.
The same goes for BRAIN-clients. They too should honor the heartbeat of the BRAIN-cell, or risk being blacklisted.
Broadcasting BRAIN-files, BRAIN-searches, BRAIN-requests and BRAIN-responces should go as follows.
- A BRAIN-cell wants to broadcast something to the network. Lets say, a BRAIN-request.
- It gets a list of all the other BRAIN-cells it knows and starts with the first one.
- Hey, I have a BRAIN-request for you with hash-x and timestamp-y
- Now the other BRAIN-cell can responds as follows
- Alright, give it to me.
- I already got that BRAIN-request from another BRAIN-cell.
- It's to old, I don't want it
- I don't like the hash, it's not difficult enough. Keep it.
- The BRAIN-cell acts accordingly and goes on to the next BRAIN-cell on the list.
This should prevent BRAIN-cells from going back and forth indefinitely and eliminate the need for some central server to keep track of who has what.
If a BRAIN-cells offers a certain hash and timestamp and then gives a package that doesn't match those values, that BRAIN-cell should be blacklisted and ignored. At least for a while.
To improve efficiency, every BRAIN-cells could ask the BRAIN-cells they're connected to, for a list of BRAIN-cells they are connected to. Lets say BRAIN-cell A is connected to Brain-cell B and C. BRAIN-cell C is connected to BRAIN-cell A and B. You know, like a circle. When A gets something from B, A knows he doesn't need to bother C with it. Odds are that C already got it from B.
Every BRAIN-cell keeps in touch with a limited number of other BRAIN-cells. And for every BRAIN-cell it keeps 4 queues, for data it wants to broadcast to those BRAIN-cells. Those queues contain BRAIN-files, BRAIN-searches, BRAIN-requests and BRAIN-responses. Deduplication could be used to avoid storing duplicate data among those queues.
The BRAIN-cell pumps out the data from those queues, to the corresponding BRAIN-cells, with an interval that matches the heartbeat of those BRAIN-cells. A package from one queue at every heartbeat. A package from the next queue at the next heartbeat. And so on. Constantly rotating through the queues and pumping out data at a steady pace. It would do this with every BRAIN-cell it is connected to simultaneously. If that is more than the BRAIN-cell can handle, it shouldn't connect to that many BRAIN-cells.
If the BRAIN-cell receives new data, it puts it in the queues and reorders the queues according to the difficulty of the hashes. If a queue is full, it simply deletes the files with the least difficult hashes. It should also periodically delete files that waited too long in the queue and got too old.
If a slow BRAIN-cell can't send data fast enough to a faster BRAIN-cell, that shouldn't be a problem. As long as the heartbeat isn't exeeded, it should be ok. But a faster BRAIN-cell should be able to disconnect a BRAIN-cell that is too slow, to make room for a faster one.
The heartbeat and the maximum amount of other BRAIN-cells and BRAIN-clients it stays in contact with, ensures that any BRAIN-cell operates withit it's own limits. Some BRAIN-cells can handle a bigger load than others. They could use a low value for their heartbeart and stay in contact with a larger amount of other BRAIN-cells and BRAIN-clients.
With the BRAIN-cells that use a higher value for their hearthbeat, they would have to throttle down a little, to match their speed. But with the BRAIN-cells that can handle a biggler load and also use a lower value for their heartbeat, they can pump out the data from their queues much faster.
Connections between those BRAIN-cells will become the highways of the network and form the backbone. But in contrast to most other networks, the disappearing of such BRAIN-cells won't immediately cripple the network. Sure, it would be inconvenient and annoying as hell. But the network should keep functioning.
The ripple effect
I explained that BRAIN-cells use a heartbeat, limited connections and queues, to prevent a complete overload of data, that would DDOS the entire network into oblivion and bring it to it's knees, collapsing under it's own weight. This means that some (if not most) of the packages offered to a BRAIN-cell and broadcasted onto the network, will never make it across the entire network. With every hop they make, they will be put in a queue, according to the difficulty of their hash. And after a certain amount of hops, it won't be broadcasted anymore, because it became too old. It's like a ripple in the water, that slowly fades away.
Packages with a more difficult hash will be put higherup in the queue of every hop it makes, ensureing it gets further. It's like pulling the string of a bow. The more time and energy you spend on the hash of your package, the further it will make it across the network. However, using an extremely difficult hash is pointless. Sure, your package will make it much further. But it's unlikely someone else is willing to put the same amount of efford in the hash for a response. And that means it will never make it's way back to you. You can pull the string of the bow a little harder, but don't bother using a canon.
And this is ok. In most cases, your package doesn't need to make it across the entire network. Odds are that whatever you want, will be closeby. If it's not, you can try it again with a slightly more difficult hash, to get a bigger ripple. Or you can connect to a different BRAIN-cell and try it from there.
And ripples will overlap. If someone sends out a new BRAIN-file to the network, the first BRAIN-requests and BRAIN-responses are going to be in the proximity of the person who send out the BRAIN-file. But as soon as people downloaded some blocks, they will see BRAIN-requests for those blocks and send out responses. And ripples will originate from them. Slowly working it's way over the network. Until it eventually reaches you.
Maybe you just thought: “But if someone sends out a new BRAIN-file, how does that make it across the entire network? You sure did make it look like that. If it eventuelly rippled it's way to me, wouln't the same be true for the BRAIN-requests and the BRAIN-responses? How could I get my hands on a BRAIN-file that fast, if it originated far away from me?
Well, good catch! But the thing is, the amount of BRAIN-files send to the network each day would be much lower than all the BRAIN-requests, BRAIN-searches and BRAIN-reponses that it would spawn. That is why I used a much higher tolerance for the BRAIN-files in the example configuration, you find at the bottom of this document. And that means that BRAIN-files are going to have a much easier time to make it across the network than all the other packages.
Lets say someone wants a BRAIN-file. Lets call him Larry. This can either be because Larry only has a header. Or Larry simply did a seach for the new Nickleback album in his own collection of BRAIN-files and found nothing. So now Larry wants to search the network. Larry generates a BRAIN-search and sends it to a BRAIN-cell. But Larry doesn't want everybody to know he's looking for the new Nickleback album. He would have to act on a reponse (don't worry, we'll get to that later) and download a BRAIN-file for the new Nickleback album, from another BRAIN-cell. And Larry doesn't know who's controlling that BRAIN-cell. He doesn't want that! So, this needs to be done a little hush-hush.
- Instead of broadcasting a network-wide request, BRAIN-cell-A simply puts it in the queue and sends it to it's peers.
- On receiving, a BRAIN-cell goes through the BRAIN-files in it's cache (it's keeping there for the BRAIN-clients).
- If one or more BRAIN-files match the search, he puts them in the queue for the BRAIN-cell it got the search from. And sends it back.
- At this point it should probably not send the BRAIN-search any further. It would only ignite more BRAIN-files being send onto the network.
- If no BRAIN-file matches, it sends the BRAIN-search to it's peers.
- When the peers recieve it, they do the same.
- If they have a matching BRAIN-file (or more) is found, it's send it back to the BRAIN-cell where the BRAIN-search came from. Because the BRAIN-cell knows it's related to the search. No need to bother other BRAIN-cells with it.
- Receiving BRAIN-cells would broadcast it along just like any other BRAIN-file, because they don't know it's coming from a search.
- The receiving BRAIN-cell could ofcource keep the original BRAIN-search for a while and check if any incoming BRAIN-file matches it. And it that is the case, only send it to the BRAIN-cell where the BRAIN-search came from. That would certainly improve efficientcy. But this should only be done with older BRAIN-files. Newer BRAIN-files that match the BRAIN-search should be broadcasted just like any other BRAIN-file.
- The age of the BRAIN-file shouldn't matter. After all, BRAIN-files remain relevant over time. It's perfectly reasonable to request and broadcast older BRAIN-files. As long as there is room in the queues, it should be broadcasted.
- This keeps going until
- The ripple from the search fades away.
- BRAIN-files are broadcasted back.
- When the peers recieve it, they do the same.
- If one or more BRAIN-files match the search, he puts them in the queue for the BRAIN-cell it got the search from. And sends it back.
- And eventually, Larry should see BRAIN-files appear that match his search, without revealing his identity (his IP-address) to a strange and untrusted BRAIN-cell. Noone knows who originally requested the BRAIN-file for the new Nickleback album. Except for the BRAIN-cell you asked to act on your behalf, of course. But odds are, you trust that BRAIN-cell. It's probably your own, or a friend, or someone you know, or trust. So, no problem.
Wait, what? Where does this come from, all of a sudden? Well, it's a term I'm going to use throughout this document. So, it's probably a good idea to explain it.
When I say “weak hash”, I mean a part of the normal hash of a block. Instead of asking for a specific hash, for a specific block, you can ask for a block with a hash, that cointains the given value. A part of the hash. The trick is to ask for a value that gives a certain amount of collisions. A large collection of BRAIN-files would be helpfull to determine what to ask for. If you don't have a large collection of BRAIN-files, you can look for the length that appears most in the requests you are recieving from the network, pick the first n characters of the hash of the desired block and go with that.
The reason you would do that, is to hide which block you are actually looking for. It does of course mean that you would get false positives. Blocks that match your weak hash, but aren't the block you're looking for. That means that you need to find a balance that gives just enough collisions to hide your true intentions, but not too much, to make the whole thing impractical.
The advantage of this approach is that it's completely dynamic. You can determine exactly how much speed (lesser collisions means lesser false positives, meaning more speed) you want to sacrifice to keep others in the dark about what you want.
There is one problem though. Someone can keep track of all your weak hashes and compare them to all the matching blocks. And he doesn't need the actual blocks to do that. Just a large collection of BRAIN-files. And when that person gets his hands on enough of your requests, he can narrow down exacly what you want. This is the reason why you should never download all your blocks from the same (untrusted) BRAIN-cell. If you use untrusted BRAIN-cells, use as many as possible. Preferably a different one for each block. We'll get into this later.
How it works
Let's go through this step by step, to see how it works.
- A BRAIN-file is generated and send to the network.
- The BRAIN-cell in question accepts the BRAIN-file and checks the hash. If it's satisfied, it will put it in it's queues and broadcast it to it's peers, honoring their heartbeat.
- The receiving BRAIN-cells do the same. Until the ripple fades away.
After a BRAIN-cell has send off a BRAIN-file to all BRAIN-cells it knows, it can do the following things.
- Keep the entire file (remember the KeepFile option, in the BRAIN-cell config?)
Ask it's clients if they want the whole file and give it to them if they do. Maybe one of them was searching for it. And after doing that
- Delete the body and only keep the header, to save diskspace.
- Delete the entire BRAIN-file. Maybe it was an old one, that somebody requested in a search.
A user sees the BRAIN-file, or just the header, depending on the BRAIN-cell it is connected to.
- If the BRAIN-cell still has the entire file, great.
If not, send a BRAIN-search.
If the search gives you nothing
- Generate one with a more difficult hash, to get a bigger ripple.
- Connect to a different BRAIN-cell and try it from there.
- Still nothing? Try Google or ask around on a forum.
- If the search gives you nothing
- Now the user has the BRAIN-file, he can send a request for a block to the BRAIN-cell he is connected to. He could send out multiple requests, for multiple blocks. But remember that creating a request takes some time, because of the proof-of-work concept. So, flooding the network with too many requests is difficult. And there is also the heartbeat, forcing him to calm down.
- The request is now broadcasted and ripples onto the network.
Someone else sees the request and has a block with the requested weak-hash.
- The block is extracted from the original file
- Put in a BRAIN-box and encrypted with the key that came with the request.
- The client generates a response.
- The BRAIN-box and the response are uploaded to a BRAIN-cell
The BRAIN-reponse gets broadcasted onto the network. Hopefully creating a big enough ripple, to informing who-ever that a BRAIN-box with the requested block is ready for pickup.
- If the BRAIN-request made it this far, odds are the BRAIN-response will make it's way back too.
- If not, the original requester can try it again. In the meantime, someone a little more close might have the block and will send a BRAIN-response that is more likely to make it back to the original requester.
The first user sees the BRAIN-reponse
- He contacts the BRAIN-cell that holds his BRAIN-box
- He uses his private key, to proof the BRAIN-box is for him.
- He downloads he BRAIN-box. And when the download is completed, it's gets deleted from the BRAIN-cell.
- He then decrypts the BRAIN-box with his private key and calculates the hash.
- If it matches the hash of the block he was looking for, great!
- If not, send out another request for the same block.
- If noone claims the BRAIN-box within a certain timeframe, the BRAIN-box is deleted.
Now lets look at a more practical scenario. With a nice picture, to visualize the whole thing.
This is what it would look like. In the BRAIN-network are the BRAINS-cells, all connected to each other and constantly exchanging BRAIN-files, BRAIN-searches, BRAIN-requests and BRAIN-responses, that ripple over the network.
The clients can connect to any BRAIN-cell, to download these BRAIN-files, BRAIN-searches, BRAIN-requests and BRAIN-responses. As I envision it, you would periodically connect with your client and download the new packages, to see what the network has to offer. If you run your own BRAIN-cell, you could have it keep these packages in it's cache for a longer period of time, to make sure you don't miss anything. And you can search your own collection for whatever you want. And if you don't find it there, you can send a BRAIN-search to the network. For those who know it, it would work a bit like Spotnet.
The clients connected to a BRAIN-cell never see each other. And any BRAIN-cell only sees the clients connected to it, but never knows what they want or get. Well, never with 100% certainty, anyway. And it makes sense to only connect to trusted BRAIN-cells (likely your own), so that isn't really a problem.
Now, let's say Lisa wants to share Big_Buck_Bunny_1080p.mkv. She generates a BRAIN-file and out comes Big_Buck_Bunny_1080p.brain. She then sends the BRAIN-file to the BRAIN-cell Butterfly, who will broadcast it onto the network. It ripples to other BRAIN-cells, until the ripple fades away.
Debra and Andy see Big_Buck_Bunny_1080p.brain and want to download it. Andy only gets a header, because Satoshi deleted the body, to save some diskspace. But Andy sends out a BRAIN-search and after a while he too has Big_Buck_Bunny_1080p.brain.
Debra now puts out a request for a block with weak-hash-x and sends her request to BRAIN-cell FileStorm, who will broadcast it onto the network. Andy puts out a request for a block with weak-hash-y and sends his request to Satoshi, who will also broadcast it onto the network. However, Andy puts Satoshi, Blazer and Goliath as the preferred BRAIN-cells in his request. He could do this for a number of reasons. To spread the load over multiple BRAIN-cells. Or perhaps he just trusts those BRAIN-cells. Who knows why he did it. And who cares?
The BRAIN-requests ripple from BRAIN-cell to BRAIN-cell, until Lisa sees some BRAIN-requests for some blocks she has. But she has no idea who wants the blocks. She will extract both blocks from Big_Buck_Bunny_1080p.mkv, encrypt them with the keys from the requests and create two BRAIN-boxes and the BRAIN-responses that go with them. She sends one BRAIN-box and the corresponding BRAIN-response to Butterfly, since no preferred cell was requested. If Butterfly rejects the BRAIN-box (maybe because it is already holding too many BRAIN-boxes) Lisa could try any other BRAIN-cell. But let's just say that Butterfly is happy to accept the BRAIN-box.
Lisa sends the other BRAIN-box and the corresponding BRAIN-reponse to Goliath, since that was one of the preferred BRAIN-cells. If Goliath rejects the BRAIN-box, for whatever reason, she can try Satoshi or Blazer. If they too reject the BRAIN-box, Andy is out of luck and has to send another request, after a certain timeout. But let's just say that Goliath is happy to accept the BRAIN-box. Butterfly and Goliath will now broadcast the BRAIN-responses onto network, to inform who-ever that a BRAIN-box is waiting to be downloaded. And those BRAIN-responses will ripple their way back to Andy and Debra. As I said before, if the ripple of a BRAIN-request made it to a certain point, it makes sense that the ripple of the BRAIN-response will make it back. And if it doesn't, that isn't going to be a problem, perse. Yes, it's annoying and inconvenient. But not a direct problem.
Debra sees a BRAIN-response appear on FileStorm and recognises the hash from her original BRAIN-request. So, she knows the BRAIN-response is ment for her. She then connects to Butterfly and uses her private key to proof that the BRAIN-box is ment for her. She then downloads the BRAIN-box from Butterfly. And when the download is complete, Butterfly will delete the BRAIN-box.
Andy sees a BRAIN-response to his BRAIN-request appearing on Satoshi and will download it from Goliath.
Debra can now decrypt her BRAIN-box. And she is the only one capable of doing that, since only she has the private key that matches the public key in her original BRAIN-request. She then extracts the block, calculates the hash and sees if it is the block she wanted. If it is, great! If it's not, she simply requests the same block again.
Meanwhile, Andy does the same thing.
This keeps going on for a while. And before long, Debra and Andy can start replying to requests for Big_Buck_Bunny_1080p.mkv too and start sending out BRAIN-boxes of their own, when they have the blocks someone else is requesting. And Debra and Andy can pickup requests that didn't ripple all the way to Lisa. So they can respond to requests that Lisa couldn't. And so Big_Buck_Bunny_1080p.mkv will slowly move over the network, until everybody has a chance to download it.
But what if something has evil intentions? Lets look into that.
What if someone wants to identify downloaders of copyrighted content? Let's say Tim wants to catch some of those evil people, that download copyrighted material. He puts out a BRAIN-file for TheForceAwakens_f0r_R3a1z.mkv and sends it to Speed Demon, who will broadcast it onto network. But Tim is also the one running Speed Demon. He can see who downloads all the BRAIN-boxes from his cell. And if he is also the one creating the BRAIN-boxes, he also knows what they are downloading. With a list of IP's in hand, he can then go to a judge and demand from the ISP's to know who was behind those IP's.
Lets see what happens.
Dave notices TheForceAwakens_f0r_R3a1z.brain and gets the whole BRAIN-file. He puts out a request for a block with weak-hash-x and sends it to Showdown. Showdown will then broadcast it onto the network. It ripples away and Speed Demon picks up Daves request. Now Tim will see it. He creates the BRAIN-box and the corresponding BRAIN-response and puts it on Speed Demon. Speed Demon then sends a BRAIN-response onto the network. It ripples away and Showdown will pick it up. Dave will see it and download the BRAIN-box from Speed Demon. Now Tim knows that Dave is trying to download TheForceAwakens_f0r_R3a1z.mkv. Dave is busted!
Or is he?
Actually, no. Not really. All Dave did, was reqeust a block with weak-hash-x. A block from TheForceAwakens_f0r_R3a1z.mkv happened to match that request. But since it's a weak hash, it's likely some other blocks, from other BRAIN-files, match that request as well. Dave had no way of knowing what block was in the BRAIN-box, without downloading, decrypting and checking it, by calculating the actual hash. Dave had no way of knowing that block came from a copyrighted movie. And Tim can never know for sure if that was the actual block that Dave was looking for. Tim certainly suspects something, but knows nothing. Not enough to go to a judge, anyway.
And Dave should also notice that all the BRAIN-boxes are only posted on Speed Demon. Something is up... This is why someone uploading something new (that oneone else has, yet), should put the BRAIN-boxes on different BRAIN-cells. This will send a message: “Hey look, I'm not trying to lure you to only one BRAIN-cell. I don't care about your identity.”
Remember what I said at the end, when I explained weak hashes? This is exactly why you should stay away from one untrusted BRAIN-cell. Tim getting his hands on your IP, downloading one BRAIN-box isn't a problem. But too many will be a problem.
Too many responses
There is one big problem that has been ignored the whole time. What if someone requests a block and 1000 people have that block? Who is going to respond?
I suggest clients generate a random time and wait for that time to see if a response from someone else comes along. A client that randomly generates a random short time, will likely be the one to actually generate the response, because noone alse has acted on the request yet. Other clients, that randomly generated a longer time, will see that response and know they can ignore the request. Ofcourse there will be multiple responses to some requests, but it will prevent a massive amount of unnecessary responses to one request.
What about actual communication?
After reading how the Brazilian government shutdown WhatsApp for 48 hours, ordering all Brazilian ISP's to block WhatsApp traffic. And Saudi Arabia shutting down Telegram. I wondered... Is it possible to use the BRAIN-network for messages too? Afer all, it's kind of creepy that governments can completely shutdown a widely used means of communication so easily. Fortunately, I think it's fairly easy to implement this. BRAIN-cells could accomodate an extra queue for BRAIN-messages. They could look like this.
|Key:||The public key that the person you want to communicate with is using. The addressee.|
|Timestamp:||To identify old BRAIN-messages and prevent anyone from flooding the network with old files (without doing any proof-of-work).|
|Name:||The name of the sender.|
|Message:||The message. They hould be short, like a tweet. Bigger messages should be rejected by the network. The message is encrypted with the public key of the addressee.|
|Blob:||A blob that can contain files, like a picture. The size of the blob should be limited too. BRAIN-messages that are too big should be rejected by the network. The blob is encrypted with the public key of the addressee.|
|Nonce:||A nonce to change the hash, until the request gives a hash with a certain difficulty. Just to prevent spammers from flooding the network with lots and lots of bogus requests. And to determine it's prority.|
It would work as follows. Lets say that Elaine and Jerry want to communicate via the BRAIN-network.
- Elaine starts a new chat on her BRAIN-client and calls it Jerry. For every chat that is created, the BRAIN-clients generates a new key-pair.
- Jerry does the same and calls the chat Elaine.
- They exchange the public keys. This can be done via email, phone, USB-sticks, a printed key via old fashion mail, or any other means. They could print it in the newspaper, if they wanted to. The sky is the limit. (Good luck blocking this, governments)
- Jerry imports Elaines public key to the chat he created.
- Elaine imports Jerries public key to the chat she created.
- Now Jerry sends a BRAIN-message onto the network.
The message ripples away from BRAIN-cell to BRAIN-cell, until is fades way.
- Obviously Elaine has to be “in range” to pickup Jerries BRAIN-message. But this can be dealt with. It's like talking to each other using a walkie talkie or a radio. They have to be in range too. But if their BRAIN-cells share a connection, or are at least close to each other, this shouldn't be a problem.
- Elaines BRAIN-client picks up Jerries BRAIN-message, because it recognizes the public-key she is using for the chat Jerry.
- The BRAIN-client decrypts the message and displays it in the chat Jerry. The timestamp is used to order the messages chronologically.
- Now Elaine can read the message from Jerry.
Chats-groups work too. Lets say George and Kramer want to join in on the fun.
- Jerry creates a Chat-group, calls it 'The Coffeeshop' and lets the BRAIN-client generate a new key-pair.
Jerry exports the keys (both public and private) and gives them to George, Elaine and Kramer.
- This has to be done secure, ofcourse, since it involves a private-key. He could share them with the others over a one-on-one BRAIN-chat.
George, Elaine and Kramer now create a new chat-group too and call it 'The Coffeeshop'.
- Obviously they can cal it whatever they want. But not to overcomplicate things.
- They don't generate a new key-pair. Instead, they import the keys Jerry gave them.
If anyone of the group now sends a BRAIN-message, all the others can pick it up, decrypt it and have it displayed in their BRAIN-client.
- The timestamp is used to order the messages chronologically.
- The name is used to show who send the message.
Another way of doing this is, is like the one-on-one chat and simply import multiple public keys into a chat. But that means that all messages have to be encrypted and send for every member of a group. That would be fine for small groups, but could become a problem for larger groups.
I admit, it's not as easy as WhatApp. It would be slow and not 100% reliable too. But it would be hard as hell to block. And it would provide a nice, anonymous and secure way to keep in touch, without governments meddling with your privacy. Or completely denying you the means to do so.
People could use a lightweight BRAIN-client on their smartphone, that only deals with messages and ignores all the other stuff on the BRAIN-network. Generating good hashes for the BRAIN-messages would be a battery-killer though. But hey, this thing can definitely work. It would be fun!
Does this idea serve any other purpose, besides sharing copyrighted content?
Well, sure! Lets say that Han lives in China. Han wants to read an unsensored newspaper. So he pulls NewYorkTimes_todaysdate.brain from the network and sends out requests for the blocks, using a few trusted BRAIN-cells. And a while later he can read the PDF on his laptop. Noone will know. And if he's really paranoid, he can connect to any BRAIN-cell via the TOR-network and/or via a VPN.
Or maybe you want to share some photo's with some friends and family. But you hate the idea to put them in the cloud and you lack the skills to run your own Owncloud-server (or something like that). Instead, you could put the photo's in an (encrypted) rar-file. You then create a private BRAIN-file for that rar-file. And instead of putting it on the network (that wouldn't work with a private BRAIN-file, anyway), you keep the BRAIN-file to yourself and email it to the people you intended it for. And now they can easily download the file from you.
It would also make it really easy to publish a document for the whole world (like this one) and remain completely anonymous.
It would also provide an uncensored platform to many content creaters that face a more and more increasing problem with censorship on Social Media like Facebook, Twitter, YouTube, etc. They can use a private key to sign any content they create and send it to the network. The public key can be shared any way they want and would be very hard to block. People can then use the public key to let their client automatically recognize and download anything signed by that content creater. It would be like subscribing to a channel on YouTube. This allows people to easily, cheaply and freely share information, without the fear for being blocked. And it would also allow them to remain anonymous. There is no need to create an account or anything.
But what if my friends and family live very far away?
You talk about sharing files with friends and family. But if they live far from me, doesn't that mean that their BRAIN-request will never create a large enough ripple to reach me?
Yes, it does. But since it's supposed to be very easy to run a BRAIN-cell, you can simply do that. Run your own BRAIN-cell. When sending the email with the BRAIN-file, tell them to connect to your BRAIN-cell. And there won't be a ripple probem at all.
In fact! You and some friends can run one or more BRAIN-cells, completely seperate from the BRAIN-network and use it to share files among each other. You create your own private little BRAIN-network. And since it's a closed and trusted system, you wouldn't have to bother with weak-hashes either. You can just ask for whatever you want and get it with nearly 100% certainty.
You could even take it a step further and run it on your own (Virtual) Private Network, completely seperate from the internet. Imagine some people in a country like North Korea doing this...
Or how about running it on the LAN of your company? Any sysadmin knows that people ignore any fileserver and email files to eachother, because that's more convenient. What if they could just "BRAIN" files with a few mouseclicks?
What about the bad guys?
Can't this be used by bad guys? Pedophiles could share child pornography! And my BRAIN-cell could actually participate in that, without me knowing!! And what about terrorists!? They can communicate via the BRAIN-network! ISIS is going to win because of this!
Well, yeah. Just like any tech, some people will use it for bad things. It is only reasonable to assume the same will happen with the BRAIN-network. But banning BRAIN, or any other tech, isn't really solving that issue. You aren't going to ban knives, because some people use them as murder weapons, are you? Knives are actually quite usefull. And so is the BRAIN-network.
Maybe governments will finally realize their obsession with encryption and regulating the internet is pointless and not solving anything. And hopefully they will start putting their new found time and energy in things that really matter. Some perverts are out there, abducting and abusing children! And some other assholes are smuggling weapons and explosions, to perform acts of terror! Those are some serious things, happening in the real world. I suggest they start there. You know, with some old fashion detectivework. Out there, in the field. Meanwhile, they can leave regular Joe alone. He just wants to watch a movie after a long day at the office and means no harm to anyone.
How hard is it to run a BRAIN-cell?
I hope that running a BRAIN-cell is easy enough for anyone to participate. My mom should be able to start one. She probably won't use 99% of it's functionality. But the same is true for the phone, the tv or any other equipment she uses. The more, the better. The idea is that it should not be that demanding on bandwidth and diskspace. And if it is, tuning the settings might help to keep it down enough to handle. Anyone should be able to run one. Maybe even behind NAT, without forwarding any ports, if hole punching would be possible.
If you were keeping attention, you should have noticed that all the heavy lifting, for generating valid hashes, is always done by the BRAIN-client and not the BRAIN-cell. So, the BRAIN-cell doesn't need that much power. If you have the bandwidth, you should be able to run a dedicated BRAIN-cell on a Raspberry Pi.
Won't this generate a lot of traffic and consume lots of diskspace?
The BRAIN-searches, BRAIN-requests and BRAIN-responses are small and will exist only for a short time on the network. They will likely be gone within the hour. And with compression, it should be even less demanding on bandwidth and diskspace.
The same goes for the BRAIN-files. They are probably bigger, but that's why I suggest to split them into headers and bodies. The headers can be kept for a longer period, while the body is deleted right away. And anyone running a BRAIN-cell is free to keep the retention time as low as they want.
And the ripple effect should ensure that the network will not be overloaded with too much data being broadcasted around.
Won't this mean the retention time is even worse than usenet?
Well, maybe. Probably with most of the BRAIN-cells. But keep in mind that the headers are small. And the BRAIN-files themselves are probably not that large either. And you don't need to pull them from the BRAIN-network perse. Maybe someone will run a website and post them there. Or you could post a request on a forum, or Reddit, or something else. And hopefully someone would post the BRAIN-file somewhere, where you can download it. And there are probably people who will put 10.000 BRAIN-files into a rar-file, create a BRAIN-file of that rar-file and post that on the BRAIN-network.
And anyone running a client is free to keep any downloaded BRAIN-file for as long as they want on their own harddrive, to use as a personal archive. And I suppose there will be people who will keep the BRAIN-files for as long as possible in the cache of there BRAIN-cell. I know I would. So, I don't see anything dissapearing anytime soon.
I thought you hated torrentsites. Now you suggest BRAIN-sites?
Hey, anybody is free to do what they want. If someone wants to run a website that hosts lots of BRAIN-files, who am I to stop them? They are free to do so. And regardless what I think, it would be a nice alternative to downloading them from the BRAIN-network itself.
How do I know if a BRAIN-file is any good?
Generating a BRAIN-file costs time and effort, because of the proof-of-work concept. I suggested 2 minutes (one minute for the header and one for the complete BRAIN-file, with the body). But this could be more. This should discourage sending lots of bogus BRAIN-files to the network.
I also proposed signatures. Those can be used to proof a BRAIN-file comes from a certain person or group, without actually revealing anyones true identity. Unless the police kicks down their door and finds the private keys on their harddives, ofcourse. But noone forced them to sign any BRAIN-file, before sending it to the network. And they should have stored those private keys more secure, anyway...
People can also setup sites where users can vote on certain BRAIN-files. All they need is a database with the hashes, names, descriptions, etc, of the BRAIN-files. Basically, just the headers. No need for them to store the entire BRAIN-files (which should make it harder to attack them legally). Clients can then hook into those databases, to determine how relevant a certain BRAIN-file is and adjust search results accordingly.
What about the BRAIN-boxes?
The BRAIN-boxes are obviously the biggest thing to handle. But if you want to keep your BRAIN-cell small, you can only accept smaller BRAIN-boxes. Or accept only a few of them at any given time. Perhaps accept only BRAIN-boxes with a more difficult hash? You could also try to keep them on the shelve for a shorter period of time. And people can always divert to another BRAIN-cell, that can handle a bigger load. It's just you, doing your small part. All the little bits help.
I do want to note that keeping the BRAIN-files on hold for a shorter time is tricky. Actually, this is a tricky one anyway. It could allow trolls to setup a BRAIN-box and let it act as a blackhole. It accepts BRAIN-boxes and deletes them immediately. But in my experience, in cases like this (sharing stuff and whatnot), people can show a surprising amount of goodwill. So, hopefully it won't be that bad.
Wat about the legal issue?
I demonstrated that it is not that easy to actually proof someone downloaded illegal content. But that also depends on you and the weak-hashes you are using. Basically people just request blocks with certain weak-hashes. And the idea is that there will always be other blocks with the same hash. It would be impossible to know which block someone actually wanted. There is also the possibility to stick to preferred BRAIN-cells you trust. Or to connect to them over TOR and/or VPN.
What is a trusted BRAIN-cell?
That depends on you and the who is running the BRAIN-cell. If a friend of mine is running a BRAIN-cell and I trust that friend, I trust his BRAIN-cell. If the guys behind The Pirate Bay would run a BRAIN-cell, I wouldn't really know them, but I would trust them enough to use their BRAIN-cell. And if any well known privacy- or freedom- organization (like EFF) would run a BRAIN-cell, I would probably trust that one too.
How do I make sure I keep my intentions and identity hidden?
The client should do that automatically, under the hood, when generating BRAIN-requests and acting on BRAIN-responses. It should notice that all BRAIN-boxes for a certain BRAIN-file keep coming from the same untrusted BRAIN-cell and flag a warning. Or start generating BRAIN-requests with certain (random?) preferred BRAIN-cells.
The balance between privacy and too many false positives (hashes that are too weak, causing too many collisions) could be a simple slider in the used BRAIN-client.
Won't the authorities just declare the whole thing illegal?
I guess some countries will actually do that. If they ban Twitter, Reddit and whatnot, they will definitely ban this. But most countries will probably not go that far. They will hate it, but not ban it. After all, this can be used for lots of legal means too. And the whole BRAIN-network itself is not illegal. It's just a technologie, just like any other. Just like banning knifes is pointless an stupid.
And then there is the question, how will they ban it? It's not like they can block access to some central servers. Like WhatsApp, Twitter or Facebook.
But if they do, can it be taken down?
I don't know. So far they haven't killed the old way of filesharing either. And I have demonstrated how crappy that actually is.
I suggested BRAIN-cells can run on any port they want. So, blocking them should not be that easy. If you run a dedicated BRAIN-cell, you could run it on port 22,25,80,143,etc. I don't see any ISP blocking those ports. People could also connect BRAIN-cells to each other over VPN-connections, which makes it even harder to take them down.
And even if one is taken down, so what? There should be thousends of them out there. And a thousend others should take it's place. It should be like whack-a-mole on a global scale. And why attack a BRAIN-cell in the first place? One cell does so little. And there are so many of them. It makes no sense.
And dragging you to court, for running a BRAIN-cell? For what!? What could they possibly hold over you, to do that? And if it's just you they drag to court, why not all the others running BRAIN-cells as well? Shouldn't they be taken to court too?
It will probably be very messy and give a lot of people some serious headaches, trying to get this thing down.
What about spam?
A completely spam-free network is wishfull thinking. Ofcourse there will be spam.
But to reduce that as much as possible, I proposed the proof-of-work concept. That is why anything posted on the network (BRAIN-files/headers, BRAIN-searches, BRAIN-requests, BRAIN-responses and BRAIN-boxes) should have a hash with a certain difficulty. That shouldn't be a problem for just you, posting 1 BRAIN-file, some BRAIN-requests, BRAIN-searches, a few BRAIN-boxes and BRAIN-requests to the network. But it will give spammers a much bigger problem.
If spam increases, the difficulty should increase with it. And if spam decreases, so should the difficulty. Perhaps the BRAIN-network should periodically vote what the new difficulty should be? Just like the Bitcoin-network does. I don't know.
Of course the difficulty should stay within reason. We don't want it to take 20 minutes to generate anything we want to post on the BRAIN-network, slowly toasting the CPU/GPU of Joe's PC, cranking up his electricity bill and the temperature in his livingroom. Afterall, there are other methods to keep spam at bay. Someone could build an old fashion spamfilter that any BRAIN-cell could use.
The timestamp can be used to identify old BRAIN-requests, BRAIN-searches, BRAIN-responses and BRAIN-boxes. This will prevent anyone from flooding the network with the same data over and over again, without doing any proof-of-work. Older BRAIN-files shouldn't be a problem, because they will remain relevant over time. It's perfectly reasonable to post or request an older BRAIN-file. And if some bad BRAIN-files keep showing up, their hash could be blacklisted.
There is also the heartbeat. That makes it impossible to flood anything anyway. Because violating the heartbeat would result in a (temporary) ban.
Isn't this very inefficient?
Wel, yes. Decentralized solutions aren't very efficient by nature. So this isn't going to be very efficient either. But this is not about efficiency. This is about keeping everyone in the dark about who you are and what you want. And making that as easily as possible.
However, I think/hope it won't be that bad. The biggest load on the network will probably be the BRAIN-searches, BRAIN-requests, BRAIN-responses, and BRAIN-files, constantly rippling over the network. But those are small. And the heartbeart, limited connections and queues should prevent overloading anything. So it will (hopefully) keep things within workable boundries.
As for storage, the BRAIN-searches, BRAIN-requests and BRAIN-responses have a very short lifelime. They will probably be gone within the hour. And everyone is free to keep the BRAIN-files (or only the headers) for as long (or short) as they want on their own BRAIN-cell.
The BRAIN-boxes are of course much bigger. But any BRAIN-cell will probably have to deal with a much smaller amount of BRAIN-boxes, since they wil not be broadcasted onto the network. And they too will have a short lifetime, constantly decaying from the network.
I'd say, lets see how it works out. The least we can do is try, right? :)
But what if one or more BRAIN-cells don't honor the heartbeat of my BRAIN-cell and keep bombarding it with more data than it can handle?
Well, what you've got on your hands in an old fashion DDOS attack. And solving that problem goes waaaay beyond the scope of this proposal.
Why do you emphasize on sharing copyrighted content?
For two reasons
- It's the copyright industry that tries to enforce a dystopian society on us, to preserve itself. This is what Rick Falkvinge writes about. And because of this, copyright fuels the war on our freedom. And governments happily play along and use it as an excuse to justify pushing their own agenda. And we simply can't let them win. If they refuse to change, we should force them. And in order te change the law, you need to break it first.
- It's what people care about. I could write about the freedom of speech and whatnot and most people would just shrug and not care. But tell them they can't download the latest episode of Game of Thrones anymore and you have all the attention you want.
Why did I read this?
I don't have the technical skillset to actually build this. I just want to put this idea out in the open. And hopefully some people will take it upon them to actually build it.
Did I miss anything? Probably. I'm just looking forward to your thoughts.
# This is an example configurion for a BRAIN-cell.
# This is what it could look like.
# All values are just examples, as I envision them.
# But odds are that a real life scenario will proof that other values work better. So be it.
### Generic settings ###
# The IP it's listening to.
# The portnumber it's listening to.
# The name of this BRAIN-cell
Name “Pinky and the BRAIN”;
# The option to only allow a connection with certain cells
# The option to only allow a connection with certain clients
### Bandwidth settings ###
# The max pace in miliseconds at which this BRAIN-cell will pump put out data to other BRAIN-cells. A lower value means a faster heartbeat.
# The maximum amount of BRAIN-cells this BRAIN-cell stays in contact with.
# The maximum amount of BRAIN-clients this BRAIN-cell stays in contact with.
### caching settings ###
# This section defines how long the BRAIN-cell is going to keep data in it's cache, for the clients to download.
# Time in hours of how long is the BRAIN-cell going to keep BRAIN-files/headers?
# Time in hours of how long is the BRAIN-cell going to keep BRAIN-requests?
# Time in hours of how long is the BRAIN-cell going to keep BRAIN-searches?
# Time in hours of how long is the BRAIN-cell going to keep BRAIN-responses?
# Time in hours of how long is the BRAIN-cell going to keep BRAIN-boxes?
# The option to keep certain BRAIN-files entirely, without deleting the body.
# Movies? TV-shows, certain genres? . The default should be none.
# This allows you to connect with your client and catch up with anything cool, you might find interresting.
### Diskspace settings ###
# How much total diskspace are you willing to use for this?
# If this is exeeded, stop accepting anything, until the owner has freed up some space.
# The max amount of diskspace this BRAIN-cell will use to keep BRAIN-boxes on the shelve.
# This is taken from the diskspace set in Diskspace and reserved for parking BRAIN-boxes.
# The max size of each BRAIN-box, accepted by this BRAIN-cell.
### Queue settings ###
# Keep in mind that these 4 queues will be kept for every BRAIN-cel, this BRAIN-cell stays in contact with.
# Deduplication could be used to reduce dupulicate data among the queues.
# Amount of BRAIN-files to queue
# Amount of BRAIN-requests to queue
# Amount of BRAIN-searches to queue
# Amount of BRAIN-responses to queue
# The maximum age in miliseconds of BRAIN-files kept in the queue
# Zero means, any age.
# The maximum age in miliseconds of BRAIN-requests kept in the queue
# The maximum age in miliseconds of BRAIN-searches kept in the queue
# The maximum age in miliseconds of BRAIN-responses kept in the queue