Qortal Project

The future of blockchain platforms

User Tools

Site Tools

Trace:
qdn_updates

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
qdn_updates [07/21/2022 05:35] – gfactorqdn_updates [05/16/2025 19:16] (current) – crowetic
Line 2: Line 2:
 {{:qortal_official_logo_transparent_.png?400|}} {{:qortal_official_logo_transparent_.png?400|}}
  
-Listed from most recent to oldest:+NOTE - This information is here for archival and historic purposes only. QDN is now FULLY FUNCTIONAL and has a plethora of functionality, allowing both websites and applications to be built that can leverage the entirety of the function provided by the Qortal API. Via the use of 'qortalRequest' functionality, all websites and applications published to QDN (Q-Apps) may leverage the Qortal API to facilitate nearly any tasks.
  
-===== Notes From CalDescent 11/19/21 =====+**As of May 2025**, QDN is capable of providing completely decentralized storage, hosting, encrypted communications of multiple kinds, and replacements for esesntially anything that 'The Internet' can accomplish, other than 'real-time voice and video communications'. Those real-time voice/video communications will be possible after the implementation of Reticulum, and allowances provided therein.  
 + 
 +====== HISTORIC DATA ====== 
 + 
 + 
 +===== Developer Notes 11/19/21 =====
  
 The idea of a separate "data node" was a possibility in the early stages of development, but we have now reached the stage where it's all merged into one. So every node will be "data enabled", they just won't participate in the hosting unless they view or follow. You won't have to run a separate node for data. And it won't matter if you're a minter or not, or whether you're running a full node or top-only node. It works in all scenarios. The storage location for the data is configurable so you can host the data on a separate drive if you want to. The idea of a separate "data node" was a possibility in the early stages of development, but we have now reached the stage where it's all merged into one. So every node will be "data enabled", they just won't participate in the hosting unless they view or follow. You won't have to run a separate node for data. And it won't matter if you're a minter or not, or whether you're running a full node or top-only node. It works in all scenarios. The storage location for the data is configurable so you can host the data on a separate drive if you want to.
Line 18: Line 23:
 (or, we can fit more data transactions in each block if we increase chunk sizes and keep the total file size limit the same). (or, we can fit more data transactions in each block if we increase chunk sizes and keep the total file size limit the same).
  
-===== Notes From CalDescent 11/17/21 =====+===== Developer Notes 11/17/21 =====
  
 Each website is broken up into chunks (currently 1MB each but will probably increase to 2MB+ at some point), and these chunks can be distributed in any way we choose. You could have one chunk per node, or all chunks on all nodes, or anything in between. The system pieces them together from all over the world when it needs to build the website back into its original state. The actual logic of the distribution of chunks is yet to be implemented; it currently attempts to store all chunks on each node that follows the name or views the content. But soon this will become more intelligent. I imagine we will have a total storage limit per name that is being followed. Once we reach the limit, we'll start dropping chunks evenly so that no-one is holding the complete set. The node owner will have full oversight. By default, no content will be hosted by each node. They will only store the hashes of the data which are on the chain that everyone has a copy of. Once a node owner either views some content, or follows a content creator, they will then start hosting a copy of the content that is viewed or followed. The idea behind following is that you can support creators on the network that you trust, without having to view every single piece of their content. Each website is broken up into chunks (currently 1MB each but will probably increase to 2MB+ at some point), and these chunks can be distributed in any way we choose. You could have one chunk per node, or all chunks on all nodes, or anything in between. The system pieces them together from all over the world when it needs to build the website back into its original state. The actual logic of the distribution of chunks is yet to be implemented; it currently attempts to store all chunks on each node that follows the name or views the content. But soon this will become more intelligent. I imagine we will have a total storage limit per name that is being followed. Once we reach the limit, we'll start dropping chunks evenly so that no-one is holding the complete set. The node owner will have full oversight. By default, no content will be hosted by each node. They will only store the hashes of the data which are on the chain that everyone has a copy of. Once a node owner either views some content, or follows a content creator, they will then start hosting a copy of the content that is viewed or followed. The idea behind following is that you can support creators on the network that you trust, without having to view every single piece of their content.
Line 32: Line 37:
 We may have an opt-in setting to allow you to become a "relay" - this allows data outside of the criteria to be relayed via your node but not stored. That will be disabled by default so it is entirely an opt-in feature. Relay nodes will help the network function more smoothly, so anyone that does it will be helping content to flow more easily. The whole thing is going to be a bit of an experiment. But I think we've covered enough of the basics for it to succeed, after a few rounds of fixes of course. We may have an opt-in setting to allow you to become a "relay" - this allows data outside of the criteria to be relayed via your node but not stored. That will be disabled by default so it is entirely an opt-in feature. Relay nodes will help the network function more smoothly, so anyone that does it will be helping content to flow more easily. The whole thing is going to be a bit of an experiment. But I think we've covered enough of the basics for it to succeed, after a few rounds of fixes of course.
  
-===== Notes From CalDescent 10/26/21 =====+===== Developer Notes 10/26/21 =====
  
 The files are "grouped" by the transaction that they are contained  in. So in the case of a website, you would have to download all files relating to a transaction (and potentially past transactions) in order to access any file contained within it. For example: The files are "grouped" by the transaction that they are contained  in. So in the case of a website, you would have to download all files relating to a transaction (and potentially past transactions) in order to access any file contained within it. For example:
Line 54: Line 59:
 I’m planning on having a “storage policy” setting with various different possible values such as following only / viewed only / following and viewed / all / none. Then we can default to following and viewed, and people have the option of increasing or reducing the scope of their storage. I’ll be working on this part in the next few weeks. I’m planning on having a “storage policy” setting with various different possible values such as following only / viewed only / following and viewed / all / none. Then we can default to following and viewed, and people have the option of increasing or reducing the scope of their storage. I’ll be working on this part in the next few weeks.
  
-===== Notes From CalDescent 8/18/21 ===== +===== Developer Notes 8/18/21 =====
- +
-For anyone interested in checking out the progress, you can do so here: https://github.com/CalDescent14/qortal-data/commits/master+
  
-You will see that we already have a fully operational decentralized storage system.+We already have a fully operational decentralized storage system.
  
 The most recent feature introduces layering - similar to Docker - so that on-chain updates can be published to existing sites/resources without having to upload the entire file structure again. We can also now access sites via registered names (will demo this shortly). The most recent feature introduces layering - similar to Docker - so that on-chain updates can be published to existing sites/resources without having to upload the entire file structure again. We can also now access sites via registered names (will demo this shortly).
qdn_updates.1658396135.txt.gz · Last modified: 07/21/2022 05:35 by gfactor

Page Tools