Request for a function in the network software to allow publishing of private files

In all of this post I may make mistakes and hopefully people will correct me real quick if I do.

From a discussion with David private data has to be uploaded again in order to publish it (Make Public).

The purpose of the function is to allow someone to upload/edit private files and when the files are ready for publishing or being made public the user can issue a request to make the file(s) pubic (ie publish)

I would expect the function sends requests to the vaults to take the chunk and write it to the network with the chunk’s public address. The client then iterates through the chunks requesting them to be “published”.

Obviously the user pays for each chunk as if they uploaded it.

Reason for the request. Many users use phones for everything and their upload quota/bandwidth/battery is usually limited, So the purpose is to allow users to upload once the initial file privately, then work on it until ready for going public and not be required to download and upload the file publicly.

This will save on unnecessary bandwidth usage in the process of downloading each chunk and the bandwidth to upload. The bandwidth will be in going from the vault holding the chunk to the vault that will be holding the public chunk. Much less overall bandwidth usage by the network and the user - win/win.


This also has the benefit of putting more safecoin back in the pool by requiring payment for each edit as the private data evolves while readying it for public cunsumption. Security benefits include not having to host the files locally while refining something like a website.

I have had this EXACT idea since I first discovered this forum in late 2014. I just thought it was so intuitive that the team would naturally incorporate such a feature. I considered bringing it up but felt it might be too early. As usual @neo , you leave no stone unturned. :v:


Seems like such an obvious thing to have that I’m surprised it’s not part of the roadmap! :wink: Great catch @neo


The files must be re-uploaded because addresses are not the same:

  • when the data is unpublished the address is based on the content plus the owner

  • when it is published it is based on content only.

This has a cost that must be paid for.

That said, the user can then delete his former unpublished files and get a refund for them (I suppose). But if he keeps both he must naturally pay for both because the storage used is doubled.


I have to say this is the point of a function to exactly that, write the chunk to the new address because the addresses are not the same. And do it directly from vault to vault saving the additional bandwidth the network has to do to hop it to the user and then hop it to the new vault from the user. Only one set of hops rather than 2 sets. And is why i said it would have to be paid for. I did say all that above.

Not in the pipeline at this time, but maybe a option. Although the user will have paid for any edits/updates to the file while private. So it would only be a portion of the overall payments that could have any refunds


Omg, no refund please. Any kind of refund brings shitload of complexity and options for gaming the system.


Sorry, I misread this. I thought this was a problem and I mentioned the possibility of a refund on delete of unpublished data to reduce the total cost of the operation.


The fact that public reupload has to be paid again together with the fact that private data is seldom read compared to public data can be solved by different pricing of public vs. private data. Of course I have no idea, what kind of complexity this brings, but I think much less than any refund strategy. Same price for both private chunk and public chunk is as artificial decision as any other fixed ratio. So any fixed ratio will be bad. The only question is how bad. Maybe cheaper private data than public will help fighting with other storage solutions(dropbox, google drive) which are private too, and don’t have heavy read traffic costs.
Also public data are usually business data. And if I can upload once and never pay for traffic, it is way cheaper than to operate heavy server architecture. As a result I expect people will be willing to pay more for public data than for private data.


Looking at only this case of upload->private, edit-private, private->public we see that the user will be at a minimum paying twice for each chunk and at a maximum a lot more considering edits etc. So if no refunds which I suggest is good or refunds are 1/10 of chunk costs, then that public data has then had a lot more cost than public data that is directly uploaded.

Maybe to make it seem fair to users who wish to go the private first route, we make private data at cost of one unit and public data at the cost of 2 units to upload. Unit is dependent on what method used to determine the cost of uploading one chunk.

There is no opportunity for people to cheat this since to go public first is 2 units and to go via private is 2 units. Refunds at 1/10 would allow users to cheat slightly by 0.1 units. And this would be an argument for no refunds.

I try to not tag any of the dev team but @dirvine, this presents a logic problem of the 2 ways/routes (not roots) people will be uploading public files. In it we see that there is a case to charge twice for public data than for private data uploads due to downloads usage. Early on (years ago) when there really was basically no difference between private and public in the eyes of the network the different charging could not be justified or sustained since it would be cheated. But now the network is enforcing the difference and thus charging double for public files is justified and enforceable.

If you read the OP then the path where the user uploads to private and edits, then uses this new function to transfer the chunks directly to public then the user is charged once for upload to private (and charged for edits) and then charged singularly for the transfer making a minimum or double to finally get the chunks to public.

Without the new function then i would argue you cannot charge differently since that would greatly discourage the sensible case where the user uploads privately edits then downloads and uploads to public costing a minimum of 3 times. They would continue to use their local drive then upload to public and any mistakes means doing that again. Whereas with the function they can do all their testing on the network and have it correct more often before publishing it.


It is something we must consider post Fleming for sure. The pricing and farming rewards need to be tested from all angles. This seems like a reasonable approach (have a free make private/public function). I would agree with this for sure, but need to get space to consider it among all the other parts of payment. I think there is even space to make private more expensive, and going public then refund a cost and so on.


Why should be private more expensive? Private has very few reads, public is heavy on read. I would expect exact opposite.

Incomplete thinking (from me I mean), but private has less reads but is only beneficial to a single person, whereas public is beneficial to (usually) more that that.

1 Like

Isn’t that what we really want? To make a place where everyone can keep his secrets at reasonable price? Hardware infrastructure costs are mostly on public data. Storing something what is never loaded is much cheaper than data that has to be cashed on thousands of computers. Storage itself is not a bottleneck, but bandwidth is. Average public data costs can be easily 10x higher than private data. Many will be million times more expensive. Private data uploaders have to pay extra money to cover others public data costs already. If we want people to switch to this network, costs have to be comparable with dropbox/google drive costs. But if people have to pay for public data costs, than it is impossible. Renting server with 1 TB HD, enough CPU, RAM and bandwidth is much more expensive than just storing 1 TB of data on amazon S3. And that is the difference between public data vs private data costs. I would suggest the opposite, and make private data less expensive than public data. Simple to adjust it to dropbox pricing level for private data. Or calculate the ratio from costs of full server vs just S3 storage.

1 Like

100% it is. I don’t think private costing more than public makes it necessarily expensive though. We will see as we move on though as the value to the consumer has to count as well as private data being as cheap as possible.