From what I understand dcrtime is no different than a system.remark of some hash of the content. It is exactly performing the same function as we are describing here. At least that’s what I was able to gather reading their docs.
There is no value directed elsewhere. IPFS doesn’t cost anything to use and doesn’t lock us into any other ecosystem. I don’t think this argument is relevant.
There is a cost to IPFS.
Eventually someone has to pay the piper.
If you introduce a secondary dependency, value flows elsewhere.
If every decision in this ecosystem is the ‘easiest’, you are essentially ‘off-shoring’ value creation.
The insane thing about crypto and teams building is how no-one has a grasp of business basics.
Token valuations hide all sins - and a reckoning is coming.
What’s the real cost of IPFS? Does anyone know? One of the biggest problems with IPFS is that it has been treated as a magical decentralized storage network, free for everyone. This has been driven by a couple of factors. Most notably, IPFS storage being subsidized by various IPFS storage providers. Unfortunately, we believe these subsidized practices will replicate the same broken business models that created the current web that we have been trying to fix with blockchain and Web3.
What “value” are you even talking about here? “Value” is an extremely vague word.
The point of IPFS is that contrary to something like AWS, it’s just code. You can just copy-paste IPFS’s code (more realistically clone a git repo), and boom you are IPFS too. Anyone can be IPFS. You don’t have to pay storage providers, you can pay them if you are yourself too lazy to do their job.
Storage providers only offload the storage cost (which for something as small as a treasury proposal is irrelevant) and laziness cost.
IPFS itself is not an ecosystem where value can flow to. It’s just source code.
IPFS is just source code yes.
Filecoin was created to monetise / productise IPFS.
At some point, someone makes money providing a useful service.
There is no such thing as a free lunch.
We’re not talking about Filecoin, we’re talking about IPFS. Nobody is going to use Filecoin to host treasury proposals. We’re talking about a few megabytes. Even if you use Filecoin, it probably costs you a few cents a year to a host that.
Please look at the reality. We’re comparing using IPFS, which has a lot of adoption, tools, and is easy to use, with creating a convoluted homemade hack (I suppose we all agree that using remarks are not a proper long term solution) that nobody who isn’t deeply familiar with Polkadot understands.
And you’re arguing for the latter in order to avoid a potential flow of a few cents a year to a different ecosystem.
every compromise compounds.
unless IPFS or an equivalent solution accrues value to the core network, it is value moving elsewhere.
storage costs are real, and will scale over time.
who pays these storage costs and in what currency matters.
I don’t understand what you’re saying now. How does hosting treasury proposals on Polkadot itself accrue the value of the core network? The Polkadot ecosystem is not going to accrue in value just because it does itself something that is offered by a free service.
who pays these storage costs and in what currency matters
Again, nobody will pay anything to get their treasury proposal hosted. Neither on Polkadot nor on IPFS.
Following your argument, it is even beneficial to use IPFS. If you store data on the Polkadot network itself, you’re making the Polkadot validators sell more of their DOTs to pay AWS or Google Cloud Provider. While if you use the free tier of IPFS storage providers, you’re making them pay AWS/GCP from their own pocket.
But again, it doesn’t matter, because we’re talking about a few cents a year.
If you’re really concerned about the flow of money, I would suggest to start optimizing the source code of Polkadot. Because right now Polkadot validators pay probably hundreds of thousands of €/$ per month to AWS and GCP for their storage, bandwidth, and CPU costs, and the best way to reduce this bill is to optimize the source code.
there are two separate discussions here.
is about appending on-chain invoices
is about on-chain storage.
re 2, i’m not saying hosting an invoice on polkadot/kusama (local sovereign state) is gonna make lots of money, but it is a (tiny) example of a storage problem that needs to be addressed.
the options put forward for using IPFS are based on two reasons:
this is not just irrelevant, it’s backwards. it’s like facebook saying, lets host our video on youtube. the network effects do not accrue to the participants of the primary network (kusama in this case).
no you can’t, you just address it there, then if you want to ensure it stays there, you need to pay. of course, pinning an invoice is not gonna cost much, but that’s not the point. these things add up when people want to store biggerer things.
the main point i made at the start is IPFS creates a secondary dependency, which grows over time, as the sovereign state (kusama/polkadot etc) hosts its media (of any and all sizes) elsewhere.
further, if there is demand for storage, then this will be paid for. either future demand is ‘off-shored’, like US (Polkadot) sending manufacturing to China (IPFS/Filecoin/Arweave etc).
the simple question for any of these emerging network economies, is how do you ensure economic value consistently accrues to central sovereign assets.
the dollar is the benchmark.
This is not a valid comparison. Hosting a video on YouTube means that YouTube now has control over the video, and can choose to delete it. Hosting a video on YouTube gives more power to YouTube.
This is completely irrelevant here. We’re not hosting things on IPFS, we are integrating IPFS. Again, IPFS is just source code. It’s not a company.
No, if you want to ensure that it stays there, you start an IPFS node and run ipfs pin <hash> in your terminal.
Don’t want to do that because you’re too lazy? Then yes you can pay for someone to do it for you.
This discussion isn’t about storing biggerer things, it’s about finding a pragmatic solution to hosting treasury proposals.
Offering a horrible user experience just to die on a hill is way more harmful than what the consequences of using IPFS would be.
ok, so maybe this is my framing issue, but when i hear ‘network effects’ in this context, what i assume is the combination or IPFS and some sort of pinning / storage solution since originally there seemed to be this expectation that hashing on IPFS = permanence, which was the whole point of the thread in the first place.
this is what i outline as the business opportunity in the offshoring analogy.
yes absolutely 
i still don’t know why you wouldn’t want to drive adoption of a simple and native protocol (system remarks) over IPFS, which requires integration if there were a choice?
Tagging in @swader since we’ve discussed this a little.
Because system remarks are fundamentally a hack.
A remark isn’t actually stored on chain. It is only stored in the list of transactions of a block. Nodes are completely free to completely discard old blocks, and as such all the remarks that come in them. They have absolutely no requirement whatsoever to keep old blocks around, they only do it out of goodwill.
Fetching a remark is free exactly the same way that IPFS storage providers have a free tier. It’s free only because it’s a service graciously provided by the Kusama/Polkadot full nodes or IPFS storage providers, and this free service could stop from one day to the next without any warning.
The idea that remarks are permanent is just as wrong as the idea that IPFS is permanent.
To me, remarks have all the drawbacks that IPFS has, but without the advantages that IPFS has, which is that it has a lot of documentation and tooling that makes it intuitive and easy to use.
Remarks are graffiti on blocks that have no effect on block content.
The graffiti are there only when using Archive nodes, because those store absolutely every interaction with blocks - meaningful or not.
Archive nodes are becoming more rare because they have no purpose really, are expensive to run, and near impossible to get funding for.
So, using remarks makes no sense for storage, and using IPFS is always better.
@tomaka is absolutely correct here in that remarks make no sense for anything meaningful, and in polkadot where a “governance” decision can make them stop overnight, it is dangerous to actually rely on them. For examples, see the remark length change of 2021, or the sudden, unannounced fee increase rider bill of 2022.
Thanks @tomaka @swader @lucasvo - pressing these buttons is the only way I know to learn and to pull out little useful nuggets of insight, so allow me one last round of devil’s advocate.
Reading between the lines, if a remark based solution is to persist it needs to address two key issues:
There needs to be a sustainable funding / support / product strategy for archive nodes.
There needs to be assurances as to how governance can/can’t interfere with their parameters.
Solve those two things and system remarks are a viable alternative to IPFS.
Or am I still missing something?
IMO it is a misguided effort. Asking “if we do all this, can remarks replace IPFS” is akin to asking “if I take enough styrofoam, and then glue enough of it together, and also wrap it in nylon, and then put it in water, could it IN THEORY, be a boat?”
I do not think it is a healthy comparison, and even if you go and compare it to file storage, it is probably saner to compare it to Arweave, Filecoin, and similar storage meme chains. Comparing it to a protocol is unrealistic, IPFS advantages are just too big, comparatively.
Here, Remarks are just a spoon you would choose to dig a trench while ignoring the shovel right next to you.
Sometimes all you got is a spoon.
Gotta go to another trench digging company then tbh.
I wonder if the solution here isn’t something like the following:
This raises questions that have some implications and requirements.
@rich this has the property of removing/avoiding the secondary dependency. At the cost of having to create a new category of node. Specifically, storage nodes.
Will the economics of storage nodes work out such that the data fees are not a disincentive?
Need time to process but think I get you, at least it’s directionally helpful thanks
In order to frame this/bring it back: recall the reason blockchains are truly useful - as finite state machines, they are responsible for facilitating the change from one state to another. After that state change has been completed, it’s hard to justify storing the entirety of that state transition - rather, you’d just store the proof and justification of it happening. Blockchains are not databases, and by relation not storage mechanisms. It’s for this reason that remarks are not a long term solution 
Undoubtedly it will be necessary for any meaningful applications that require more ‘rich state’ for more common end users outside of the cryptosphere.
Couple of possible solutions:
A system parachain that is composed of archival nodes, which of course would require its own requirements for being eligible to join. The IPFS layer would also live here as part of this system parachain implementation, which those participants would naturally also be running as part of their client.
Incentivize archivable nodes on the relay network, which is rather complicated and doesn’t really scale to the vision of just allowing the relay network to validate para-activity.
Yes - specifically @taqtiqa-mark:
Which roots us back to plug and play nodes (I’ve owned a variety) that allow community members to both act as personal servers and local storage providers allowing access “Web3” OS more easily.
See Urbit Native Planet, Umbrel, DAppNode, Foggie Max etc etc