README
¶
archit
Distributed archival environment
Initial concept creation as of 12/24/2016
Archit will be a PC based distributed environment whereby users can encrypt and archive objects to a shared infrastructure. This differs from current commercial implementations in that "farmers" will rent space on their PCs and "renters" will store their files distributed across a number of networked computers.
Initial coin usage will be via IMACREDIT (https://github.com/imacredit/imacredit). Coin usage is required as a method of resolving deliberate sabotage of the network by request flooding, since each request will have a small transaction charge.
This project was inspired by the kind folks over at Storj (https://github.com/storj). It differs in a few key areas:
-
The project will be written primarily, if not exclusively, in the Go programming language in order to provide speed, portability, and a relatively bug free environment (less chances for memory leaks and assocaited environmental issues).
-
Go's inherrent ability to both multi-thread and communicate over the Internet is heavily utilized, with an emphasis on IP connectivity between distinct processes. For instance, the environment splits off network management from other core features - to the point that such a service could run on a seperate machines if that feature was enabled and a farmer desired to do so. Likewise, there is little benefit to running more than one instance of archit - that instance should take full advantage of the server its running unless restrictions are specified via confirguration (for instance, to only use 4 cores of an 8 core system via the GOMAXPROCS variable).
-
Self-tuning is an inherent code design goal, within the configuration limits. e.g. issues like concurrency will be automatically adjusted over time to attempt to best utilize offered resources.
-
Files stored in the archit ecosystem will be sliced, encrypted, and broken into shards for storage across multiple systems. Shards will always be private and fetchable only from the renters machines (where the tracking database resides) when combined with a PIN (which is normally prompted for, but can be specified in a configuration file). Archit itself will have renter side checks that prevent more than one shard per slide from existing on any one farmer, and will strive to distribute each shard to a seperate farmer.
-
Raptor like coding techniques will be utilized to provide file recovery redundancy across farmers.
-
Initial effort will be to create a linux based CLI. However, since the project will be written in Go, a Windows port should be relatively easy to provide. Support for a GUI interface is not intended until after Alpha testing, if then.
-
This project will be invitation only/private until Beta release, when limited public support will be offered.
-
This code looks nicer if you make one modification to the standard github.com/btcsuite/btcutil/amount.go file:
Lines 36->44 should be changed from "BTC" to "IMAC"
Documentation
¶
There is no documentation for this package.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
hmac.go is located in db instead of util to avoid import cycle issues
|
hmac.go is located in db instead of util to avoid import cycle issues |
|
Announce announces to the network that this node has joined It does so by telling the first seed node it finds active Cron.go - deal with all things that should happen occassionally Filename manipulation routines initially written on 5/6/17 Try and prevent spamming by limiting the number of request to once every 10 seconds (unless someeone else connects) This function is only set for External connectionings in run.go
|
Announce announces to the network that this node has joined It does so by telling the first seed node it finds active Cron.go - deal with all things that should happen occassionally Filename manipulation routines initially written on 5/6/17 Try and prevent spamming by limiting the number of request to once every 10 seconds (unless someeone else connects) This function is only set for External connectionings in run.go |
|
Code compliments of http://stackoverflow.com/questions/21060945/simple-way-to-copy-a-file-in-golang Filename manipulation routines initially written on 5/6/17 Hash.go, based the the goarchit/sample/hashfile.go routine Black2B is significantly faster than other hashes for our need Routine is called per 1GB slice and to create an authentication hash for each 32mb encoded slice
|
Code compliments of http://stackoverflow.com/questions/21060945/simple-way-to-copy-a-file-in-golang Filename manipulation routines initially written on 5/6/17 Hash.go, based the the goarchit/sample/hashfile.go routine Black2B is significantly faster than other hashes for our need Routine is called per 1GB slice and to create an authentication hash for each 32mb encoded slice |