You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see issues implementing this, and I am sure the PIVX Developers do too, but perhaps they are easily solved.
We expect that future 3rd party apps (3PA) will like to use the Tier-2 network for various resources. Typically, many MNs will participate, and the 3PA will not want to, or be able to, determine which MNs those are. Further, payments may be small and frequent, or larger and rare. What would help motivate the Tier-2 MNOs to support the 3PA, is a regular income stream from it.
Example: IPFS services
Let's assume a 3PA service is created that accepts data from a user, publishes it to IPFS creating the Content ID (CID), and then pays the PIVX Tier-2 network to PIN that CID for a specific period of time. This 3PA service would be running a local instance of the PIVX Core wallet. Possible steps to execute this would be:
When a MN is set up, the IP address of an IPFS server it maintains is defined. This could be the MN host itself, but I would think that creates possible resource and security issues. As such, it could be forced to be a separate IP. A Shield address is also defined for this MN for receiving payments.
The Network then sees this particular MN supports an IPFS server, and adds that IPFS server to the PIVX IPFS-cluster. This then automatically ensures a CID PINNED there will be replicated across the cluster.
The IPFS 3PA publishes the CID, and determines its size to determine PIN cost per unit time.
A PIVX Core wallet command returns a list of Tier-2 services available. (In this example, the service 'IPFS' is applicable)
A PIVX Core wallet command returns a random IP for a Tier-2 referenced IPFS server that provides the 'IPFS' service, as well as the payment details, which would be a cost per MB per unit time, and the Shield address to send the payment to.
The IPFS front end app then calculates the payment amount, based on the user request.
Assuming the user accepts, the app then sends a Shield payment, with the 'IPFS' service specified in the encrypted memo, along with the CID and expected PIN duration.
The network accepts the payment, and fairly redistributes it to the IPFS servers participating in the IPFS cluster. (Perhaps this happens naturally by way of the IP for the IPFS server being randomly selected and no further payment distribution is required.)
Hope this make sense!
Conclusion:
The front end of the 3PA would be pretty simple to create.
The IPFS server setup and cross reference from a MN would be pretty easy for a MNO to make happen.
All that is missing is the above PIVX Core Wallet functionality, and BOOM, we have a new revenue stream for MNs.
The text was updated successfully, but these errors were encountered:
Preface:
I see issues implementing this, and I am sure the PIVX Developers do too, but perhaps they are easily solved.
We expect that future 3rd party apps (3PA) will like to use the Tier-2 network for various resources. Typically, many MNs will participate, and the 3PA will not want to, or be able to, determine which MNs those are. Further, payments may be small and frequent, or larger and rare. What would help motivate the Tier-2 MNOs to support the 3PA, is a regular income stream from it.
Example: IPFS services
Let's assume a 3PA service is created that accepts data from a user, publishes it to IPFS creating the Content ID (CID), and then pays the PIVX Tier-2 network to PIN that CID for a specific period of time. This 3PA service would be running a local instance of the PIVX Core wallet. Possible steps to execute this would be:
Hope this make sense!
Conclusion:
The front end of the 3PA would be pretty simple to create.
The IPFS server setup and cross reference from a MN would be pretty easy for a MNO to make happen.
All that is missing is the above PIVX Core Wallet functionality, and BOOM, we have a new revenue stream for MNs.
The text was updated successfully, but these errors were encountered: