stor

See: chat, cloud, P2P, storage

We must store both data and potato.
And we must also store the sources.

Sources are the LAND and WORK required for production.

If we can share both Sources and Storage,
we can ensure production and availability.

Shared Data Storage
    Allow none, some or all to Read.
    Allow none, some or all to Write.

When A "sends a chat" to B,
    A stores the data locally and waits for B to read.

But if B tries to read while A is offline, the system fails.

We can store on C to increase resilience.

The more nodes we add, the better it gets?
Up to some point, adding nodes helps.

We can own LAND in Groups_of_Groups
and trade future WORK for future GOOD
to produce and store all we need.

to share the storage that requires.

reciprocal compensation

BeakerBrowser.com >>An experimental peer-to-peer Web browser.

SolidProject.org

FileCoin.com uses for IPFS.org

A pure P2P chat system can be tricky.

For example, imagine node 'A' chats to 'B', but 'B' is offline, then 'A' goes offline before 'B' is back online...

One solution is to store data on node 'C' "in return for" 'C' being allowed to store data on node 'A' and 'B'.

This reciprocal compensation model allows us to "pay" each other at any quality-of-service level without passing tokens (without using any form of 'money').

Video needs more storage and faster networks, so a pure P2P system may struggle to deliver when all Nodes are small.

To overcome this, each Node could initially contact a central Registry server (DNS name or IP address could be "hard coded" into each client) to report their availability, and to find other Nodes.

which use a location-based naming convention to quickly discover other Nodes near them.

promote
(Federation)

and also to be a Registry for naming and Node discovery.

to host Video and other big files

To promote MetaNodes, each Node offers reciprocation in the form of:
. Storage
. Original content (new Video, for example)
. Skills (by signing Work_Contracts)