Qortal Project

The future of blockchain platforms

User Tools

Site Tools

Trace:
qort_new_data_hosting_model

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Last revisionBoth sides next revision
qort_new_data_hosting_model [08/23/2021 10:55] – gfactorqort_new_data_hosting_model [10/11/2021 10:42] – [QORT New Data Hosting Model] gfactor
Line 8: Line 8:
 We have a working prototype already which works in a similar way to IPFS but we hope will be a lot more user friendly. It’s only for static sites at the moment (HTML, JS, CSS, images, other static assets) so you would need to either build it directly as a static site, or take a static copy of an existing site using a tool such as httrack, SiteSucker, Simply Static, etc.  We have a working prototype already which works in a similar way to IPFS but we hope will be a lot more user friendly. It’s only for static sites at the moment (HTML, JS, CSS, images, other static assets) so you would need to either build it directly as a static site, or take a static copy of an existing site using a tool such as httrack, SiteSucker, Simply Static, etc. 
  
-Here’s an example site that is hosted on a Qortal data node: http://node1.qortal.uk:12393/site/cCAbsCRiGSRWNNYX8fjohdv3CdQH12vQBxyJFm3LNfhmRZrJntwJKcseEqScapDZF5CwaWMYVHJMUEJP9EqAnd8+Here’s an example site that is hosted on a Qortal data node: 
 + 
 +http://node1.qortal.uk:12393/site/QortalDemo 
 + 
 +http://node1.qortal.uk:12393/site/QortalWikiDemo
  
 It’s an older static copy of the Qortal wiki so it is not up to date. It’s an older static copy of the Qortal wiki so it is not up to date.
Line 18: Line 22:
 Public data is only encrypted in terms of the account that put the data there, the encryption only controls the MODIFICATION of that data. Private data, on the other hand, will be fully encrypted. We’re not entirely certain yet on how we'll decide which private data is held by other nodes. Potentially we will just have an option to allow private data to be stored as a duplicate on your node. You’ll be rewarded for that data from the fees the person putting the data up will pay for the data to be stored/duplicated on the network. So as a data node you will have the option to allow private data to be stored, then as the person wanting that data stored/duplicated, you will pay a fee for however many duplicate copies you would like to store. The fee then goes to the data node that ends up storing that duplicate copy.  Public data is only encrypted in terms of the account that put the data there, the encryption only controls the MODIFICATION of that data. Private data, on the other hand, will be fully encrypted. We’re not entirely certain yet on how we'll decide which private data is held by other nodes. Potentially we will just have an option to allow private data to be stored as a duplicate on your node. You’ll be rewarded for that data from the fees the person putting the data up will pay for the data to be stored/duplicated on the network. So as a data node you will have the option to allow private data to be stored, then as the person wanting that data stored/duplicated, you will pay a fee for however many duplicate copies you would like to store. The fee then goes to the data node that ends up storing that duplicate copy. 
  
-For public data, it will be a bit different, but data nodes will still obtain a reward for the stored data. We haven't figured out every little detail yet, whether that fee will come ONLY from the ones putting data up, or if the fee will come from a modification of the block rewards.+Public data will be 100% FREE and use the same transaction methodology that Q-Chat uses, to put up the data hashes on the data chain. This means that Qortal web hosting and other public data functionality will be 100% feeless, and accessible to anyone (regardless of whether they hold QORT or not.) The only reason a person looking to host data on Qortal would need QORT, would be to register a name, which is a ONE TIME FEE, and the name is then owned forever (until potentially sold in the future 'names market'.)
  
 Here’s the code being worked on so far for the data hosting: https://github.com/CalDescent14/qortal-data Here’s the code being worked on so far for the data hosting: https://github.com/CalDescent14/qortal-data
Line 56: Line 60:
 Obviously the approach above has major drawbacks for serious / high throughput use cases, and also ones that need to store sensitive data. But it would work in projects that update their data infrequently (e.g. wordpress), so it could be a fairly straightforward way to get started. Most of the foundations are in place for this already. Obviously the approach above has major drawbacks for serious / high throughput use cases, and also ones that need to store sensitive data. But it would work in projects that update their data infrequently (e.g. wordpress), so it could be a fairly straightforward way to get started. Most of the foundations are in place for this already.
  
-The current plan is to include a java-based version of httrack in the data nodes, so that it can automatically convert a URL and add the static copy to the data chain. After that, we'll have the ability to include a bot in the data nodes that watches a given URL for changes and then automatically creates a static copy and publishes any differences to the chain each time.+The current plan is to include a java-based version of httrack in the data nodes, so that it can automatically convert a URL and add the static copy to the data chain. After that, we'll have the ability to include a bot in the data nodes that watches a given URL for changes and then automatically creates a static copy and publishes any differences to the chain each time. I'm not sure whether this feature will make it into v1 of data nodes; it will most depend on whether there is a java-based static site downloader already available. If not we'll have to create our own, which will take a while. 
 + 
 +The storage nodes will have their own API endpoints to access and update data. They'll also have the API endpoints that we're already used to, so that you can access blocks and transactions on the data chain. 
 + 
 +===== More Notes From CalDescent: ===== 
 +  
 + 
 +The way public data hosting works at the moment is by using confirmable transactions (so that there is always an on-chain record of updates to each website/service), but rather than a transaction fee, we require a proof of work nonce to be calculated and included with the transaction. The difficulty depends on the size of the files being added to the network. We use a similar PoW nonce for Q-chat transactions. 
 + 
 +Then, in order for the data itself to replicate, the creator must have viewers of the data, or followers of their account. This allows good data to propagate, whereas data that has no viewers or followers wouldn't be taking up space on people's nodes. It also allows node owners to control exactly what data they are hosting, by following only those creators that they want to support (similar to torrents). 
 + 
 +The idea behind using a nonce rather than a transaction fee removes the cost barrier so encourages people to use the system. But since the uploader has to perform some difficult proof of work calculations each time, it prevents someone from easily spamming the chain.
  
-I'm not sure whether that feature will make it into v1 of data nodes; it will most depend on whether there is a java-based static site downloader already available. If not we'll have to create our own, which will take a while.+Also, the data hashes are being written to a completely separate chain for scalability reasons (it doesn't fill up the blocks on the main chain and also allows us to have multiple independent data chains when we need to scale up). In v1, there will be no way to spend QORT on the data chain, so there is no scope for transaction fees. But in subsequent versions we will add a "bridge" to move QORT between chains. At this point, we can add features such as allowing uploaders to pay extra for more copies of their data to be stored, and we can reward data nodes for the data they are hosting.
  
-The storage nodes will their own API endpoints to access and update data. They'll also have the API endpoints that we're already used to, so that you can access blocks and transactions on the data chain.+All of the above relates to "public data" only. We will eventually have support for "private data" too, and this would work completely differently. It would likely be a case of paying QORT to host it, which would be paid out to the participating data nodes. But that feature won't be in place for a while.

Page Tools