Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

A case for "Bartering of Internet bandwidth for processor, menmory and storage in IPFS". #422

Open
raslyon opened this issue Apr 1, 2017 · 0 comments
Labels
discuss.ipfs.io Topics that are recommended/better to have on discuss.ipfs.io

Comments

@raslyon
Copy link

raslyon commented Apr 1, 2017

A case for commercialization of processor, menmory and storage for Internet bandwidth

IPFS is a great idea, but if we plan to use it to replace the current internet (http), there are four commercialization components that have made the current internet what it is today and must be taken into account when attempting to build a new internet (IPFS) system. These commercialization components must be part of the core of IPFS or we risked making IPFS into just an advance form of Bittorrent. An advance form of Bittorrent that will remain incapable of replacing the current internet.

These are :
  • Processor commercialization.
  • Memory commercialization.
  • Storage commercialization.
  • Bandwidth commercialization.

In the very core of the current internet (http) is the need that anyone seeking to host content must pay for processing, memory, storage and bandwidth. Processing, memory and storage may be a one time deal if you are using your own machine but bandwidth is continues payment for any server in the current internet system. If we are going to replace the current internet with IPFS we must make sure that these four things are commercialized within the core of IPFS.

Let say for example a company like facebook decides to move to IPFS. As it is now, all the millions of dollars facebook spends on processing, memory,storage and bandwidth will be bored by the public at no cost to facebook. However if we implement the system proposed here facebook will pay nodes and clients for processing,memory and storage with bandwidth.

How will these work?

The idea I propose to commercializing these components is a Barter system, where entities barter bandwidth tokens in exchange for their data being serve to clients by nodes in IPFS. That is nodes are given bandwidth token by an entity each time they serve data belonging to that entity to a client. In turn the nodes split the token received equally with the client they send the data too provided the client is also a node.

Nodes and clients can then supply their tokens to their internet service providers in exchange for internet access. In this way we not only make the internet open but also make access to the internet open. In most cases this amount may only be a subsidy to the client internet connection bill, but it will go a long way to make the cost of connecting to the internet cheaper than it is today especially for mobile devices.

I proposed that these tokens should only be used to pay for internet access. Internet Service providers (I.S.P) would then exchange the token for real money, by exchanging the tokens for real currencies, with an IPFS token issuing Authority.

Tokens should have at least the following properties
  • The identity of IPFS token issuing Authority
  • A node expiration date. After this date I.S.Ps will not accept the token
  • An expiration date. After this date the token will not be accepted by the IPFS token issuing authority
  • The identity of the entity for which the token was created
  • The identity of the node that claimed the token. This is empty until a node claims the token
  • An expiration date after which the token no longer belongs to the entity for which it was issue. After this date but be for the node expiration date of this token, the token can be shared among nodes as reward. 60% of these token should be used as rewards and the other 40% used to finance various IPFS open source projects
  • node can only transfer tokens to I.S.Ps
  • token are not reusable ie tokens can only be used once
  • The exact real world amount of money that the I.S.P will exchange these tokens for. eg $1USD, 0.000001BTC, 0.0001ETH

With such a senario:

Content providers(comercial content providers) will be willing to use IPFS because they have control over how there contents are access and they are not sharing the same bandwidth with every body, as it is now with IPFS.

Client are incentivise to become nodes, and Operating systems may find it convinient to implement IPFS node protocols directly for their clients.

How should tokens be allocated.
In my opinion tokens should be allocated base on the size of data transfered and the closeness of the node and client. Initial tokens should be spread among caretaker nodes which will be in charge of making payment.

Here I envision a scenario where to open an IPFS server you will first buy and amount of bandwidth tokens. Bandwidth tokens will be sold based on the amount of processing, memory and storage an entity needs or already contains in the IPFS system and the amount of traffic it generate within the IPFS system.

There are some few problems that implementing this system raises

  • How do we maintain access to archives.
  • How do we make sure a live entity does not pose as an archive.
  • How do we maintain the free web ideals of IPFS.

These three are those i can think of currently.

1: How do we maintain access to archives.
The solution to this is for the system to give each file an indicator to show weather it is an archive or not. Nodes are forced to always serve archived files and they are not paid any bandwidth token for doing so. They will serve the files according to the current IPFS protocols. if a live entity (commercial entity) request an archive file, within the entity's identity, the entity will have to pay for the archive file as though it was part of its files.

2: How do we make sure a live entity does not pose as an archive.
in this case the must be a minimum duration of time for which and entity must stay without paying their bills before their data is marked as archive. These time may be say 5 years. Until these period,(5 years), elapses data belonging to the entity will not be accessible under that entity's identity but can be access under another entity's identity since it will pay for its access. After these period elapses, if the entity has not renewed its payment, its data will be marked as archived.

Since IPFS splits data into chunks, only the piece of data representing a file is marked as archive not its chunks of data of the file. That way, other entities using the data will still be able to pay for it. File should be mark as Archived with respect to entity identity not the file identity, so that other entity using the file should still pay for it.

3: How do we maintain the free web ideals of IPFS.
The IPFS community could create portals for free web content just as we have in the current internet system, such as Neocities. Such side will then provide free websevices to the public untop of IPFS.

@hsanjuan hsanjuan transferred this issue from ipfs/specs Mar 23, 2020
@hsanjuan hsanjuan added the discuss.ipfs.io Topics that are recommended/better to have on discuss.ipfs.io label Mar 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
discuss.ipfs.io Topics that are recommended/better to have on discuss.ipfs.io
Projects
None yet
Development

No branches or pull requests

2 participants