Really depends on what you mean by ‘hard’. There will be use cases where that justification comes easily.
This is another way of saying: “There are no solutions. Only tradeoffs.”
This is a way of saying: Blockchains solve nothing in particular. But they do offer some novel tradeoffs.
This is a way of saying: To get the greatest benefit from all the tradeoffs available… think of the unit of development as the relay chain.
Did anyone actually propose this?
If they did it’s not that we should poke our tongues at them.
Rather, they likely have a set of tradeoffs in mind whereby they can imagine living with on-chain remarks. Some obvious tradeoffs are no vs some storage nodes, don’t tie your staking yield to the chain RoR, etc.
They also possibly haven’t embraced the idea that the relay chain is the unit of development. In which case they are in good company.
Of course, there is another set of tradeoffs involved in deciding whether the benefit to them of on-chain remarks is worth the tradeoffs of a permissioned chain, or a permissionless chain.
Following on to the data availability conversations, is anyone here familiar with Solid / Inrupt and Pods?
Been discussing Substrate integration with them. Inrupt is founded by Tim Berners Lee.
Here’s a simple explaination of solid and solid pods and the problems they aim to solve.
Here’s an example of how the BBC are using solid servers.
Using Inrupt’s Enterprise Solid Server, the BBC Research & Development team has launched a new “watch party” product — called BBC Together + Data Pod — where users’ data is stored in their own Solid Pods and only shared with the BBC if they choose.
An interesting technical challenge has been to design data flows between pods in order to allow users to suggest programmes to watch together. Traditionally the data for this would be stored centrally on BBC databases. However, when using a PDS to support a collaborative experience such as a watch party, the data will be scattered across several pods. Designing data flows in a decentralised world is, therefore, a new and interesting challenge when applied to use cases involving sharing data between users.
We also faced and overcame many challenges in developing the user interface to the service, including communicating in simple and engaging ways why we’re doing this. We sought to make it clear to users what was happening, why it matters to them, and what benefits they get – a complicated task when PDS is not a widespread technology and so much of the data management happens in the background, invisible to users unless they look.
We also ensured that the service, which can be used by any BBC Account holder, was fully compliant with BBC policies around risk governance, information security and editorial policy: this is a live service, open to anyone to join.
Rethinking the road to decentralisation makes the case for a near future where individuals, collectives and corporations will have access to cheap and simple to use personal/local servers, storage and a simple path to clean slate operating systems that can interoperate and communicate through permissioned access using W3C recommended standards like ActivityPub and Resource Description Framework (RDF) which has recently come to the attention of Ethereum devs in relation to Soulbound identities.
This is what we’re working towards with Kabocha seeds, especially in relation to media.
