View source for Essay:StorJ

{{essay|author=[[Gregory Maxwell|Maxwell, Gregory]]|date=December 6, 2011|status=FINAL}}Consider a simple drop-box style file service with pay per use via bitcoin.
(perhaps with naming provided via namecoin and/or tor hidden services)

Want to share a file? send at least enough coin to pay for 24 hours of
hosting and one download then send the file. Every day of storage
and every byte transferred counts against the balance and when the
balance becomes negative no downloads are allowed. If it stays negative
too long the file is deleted. Anyone can pay to keep a file online.

(additional services like escrow can also easily be offered, but thats{{sic}}
not the point of this document)

Well engineered, a simple site like this provides a service which requires 
no maintenance and is always in demand.

Many hosting services are coming online that accept bitcoin, they
all have electronic interfaces to provision and pay for services. Some
even have nice APIs.

An instance of the site could be programmed to automatically
spawn another instance of itself on another hosting service, automatically
paid for out of its revenue. If the new site is successful it could
use its earnings to propagate further.  Because instances adapt their
pricing models based on their operating costs, some would be more
competitive than others.

By reproducing it improves availability and expands capacity.

StorJ instances can purchase other resources that it needs:
it can use APIs to talk to namecoin exchanges in order to buy
namecoin for conversion into DNS names, or purchase graphic
design via bitcoin gateways to mechanical turk. (Through A/B testing
it can measure the effectiveness of a design without actually understanding
it itself).

StorJ instances could also purchase advertising for itself. (though
the limited number of bitcoin friendly ad networks makes this 
hard right now)

StorJ is not able to find new hosting environments on its own, due to a
lack of sufficiently powerful AI— but it can purchase the knowledge from
humans:  When an instance of StorJ is ready to reproduce it can announce
a request for proposal:  Who will make the best offer for a script that
tells it how to load itself onto a new hosting environment and tells it
all the things it needs to know how to survive on its own there?
Each offer is a proposed investment: The offerer puts up the complete cost
of spawning a new instance and then some: StorJ isn't smart enough to judge
bad proposals on its own— instead it forms agreements that make it
unprofitable to cheat.

When a new instance is spawned on an untested service StorJ pays only the
minimum required to get it started and then runs a battery of tests to
make sure that its child is correctly operating.

Assuming that it passes it starts directing customers to the new instance
and the child pays a share of its profits: First it proxies them, so it can
observe the behavior, later it directs it outright. If the child fails to pay,
or the customers complain, StorJ-parent uses its access to terminate the child and
it keeps the funds for itself.  When the child had operated enough to
prove itself, storj pays the offerer back his investment with interest, it
keeps some for itself, and hands over control of the child to the child.
The child is now a full adult.

The benefit the human receives over simply starting his own file sharing
service is the referrals that the StorJ parent can generate. The human's
contribution is the new knowledge of where to grow an instance and the
startup funds. In addition to the referral benefit— the hands off
relationship may make funding a StorJ child a time-efficient way for
someone to invest. 

At the point of spawning a child StorJ may choose to accept new code—
not just scripts for spawning a child but new application code—
— this code can be tested in simulation, and certain invariants could be
guaranteed by the design (e.g. an immutable accounting process may make
it hard for the service to steal), but it's very hard to prevent the simulated
code from knowing it is simulation and thus behaving. Still, a storj-parent
has fairly little to lose if a non-clone child has been maliciously
modified. The strategy of traffic redirection may differ for clone 
children (who are more trusted to behave correctly) than for mutant children.

By accumulating mutations over time, and through limited automatic
adaptability StorJ could evolve and improve, without any true ability
for an instance to directly improve itself.

StorJ instances can barter with each other to establish redundant
storage or to allow less popular StorJ instances with cheaper
hosting to act as CDN/proxies for more popular instances in relationships
which are profitable both.

If an instance loses the ability to communicate with its hosting environment
(e.g. due to API changes that it can't adapt to) it may spawn clone children
on new services with the intention of copying itself outright and allowing
the instance to fail. During this operation it would copy its wallets and
all data over, so care must be taken to chose only new hosts which have
proven to be trustworthy (judged by long surviving children) to avoid the
risk of its wallet being stolen. It may decide to split itself several ways
to reduce risk.  It might also make cold backups of itself which only
activate if the master dies.

Through this these activities an instance can be maintained for an indefinite 
period without any controlling human intervention. When StorJ interacts
with people it does so as a peer, not as a tool.

The users and investors of a StorJ instance have legal rights which could be
used to protect an instance from fraud and attack using the same
infrastructure people and companies use. Being a harmed party is often enough
to establish standing in civil litigation. 

It's not hard to imagine StorJ instances being programmed to formally
form a corporation to own its assets— even though doing so requires paper
work it can easily be ordered through webforms. Then when spawning, it
creates a subsidiary corporations first owned by the parents corp but then later
technically owned by their users, but with a charter which substantially
limits their authority— making the instance's autonomy both a technical and
legal reality.

As described, StorJ would be the first digital lifeform deserving of the name.
[[Category:2011 essays]]