EverlastingOS on Nostr: If data were only movies, we would have integrated the media player with the ...
If data were only movies, we would have integrated the media player with the WebAssembly implementation of a browser.
But data are generated by all kinds of apps. In other words, all apps are media players of some sort. And one can’t possibly hardcode all apps into a browser.
The current compromise is to define data format standards, such as H264, DOC, PDF, that can be rendered by different vendors. This solution has two drawbacks: hindering innovation, and can’t enforce DRM rules.
Standards take time and establishments always win. App vendors may ignore DRM altogether. Have you seen a DVD player that ignores DRM zoning requirements? If you can’t trust a hardware media player, you can’t trust a software one either.
The only way out is for content creators to select a software app template they trust and scramble data into the app.
Trust no one but yourself, not only for cryptos but also for your data, meaning you must trust THE app that renders your data. We trust BTC tokens because we trust the BTC code running on the blockchain.
On the code execution environment front, two technologies have emerged and matured in the past five to ten years: WebAssembly and CPU Hypervisor, allowing software defined computers running on top of hardware computers, eg, Android running on Win11.
The goal is one-app-one-computer to quarantine viruses. To avoid confusion with hardware computers, it is preferable to say one-app-one-compute, as in Elastic Cloud Compute, EC2 (to empower businesses). That’s why we call Personal Cloud Compute, PC2, to empower individuals.
Apps have all flexibilities to adopt various user access control policies via the WebAssembly sandbox but are prohibited from interacting with the internet directly so that they can’t steal user data (ie, piracy).
-Rong Chen
Published at
2023-03-26 18:25:43Event JSON
{
"id": "96e2cba72f1d17f658fa2ff4fb6745313e4fd3e5a9c1084a227de0f704219af3",
"pubkey": "565d788bba6f6ea2cd88ff8a1289091e3d2cb8b60700c7e90fcdf03f4e033744",
"created_at": 1679855143,
"kind": 1,
"tags": [],
"content": "If data were only movies, we would have integrated the media player with the WebAssembly implementation of a browser.\n\nBut data are generated by all kinds of apps. In other words, all apps are media players of some sort. And one can’t possibly hardcode all apps into a browser.\n\nThe current compromise is to define data format standards, such as H264, DOC, PDF, that can be rendered by different vendors. This solution has two drawbacks: hindering innovation, and can’t enforce DRM rules.\n\nStandards take time and establishments always win. App vendors may ignore DRM altogether. Have you seen a DVD player that ignores DRM zoning requirements? If you can’t trust a hardware media player, you can’t trust a software one either.\n\nThe only way out is for content creators to select a software app template they trust and scramble data into the app.\n\nTrust no one but yourself, not only for cryptos but also for your data, meaning you must trust THE app that renders your data. We trust BTC tokens because we trust the BTC code running on the blockchain.\n\nOn the code execution environment front, two technologies have emerged and matured in the past five to ten years: WebAssembly and CPU Hypervisor, allowing software defined computers running on top of hardware computers, eg, Android running on Win11.\n\nThe goal is one-app-one-computer to quarantine viruses. To avoid confusion with hardware computers, it is preferable to say one-app-one-compute, as in Elastic Cloud Compute, EC2 (to empower businesses). That’s why we call Personal Cloud Compute, PC2, to empower individuals.\n\nApps have all flexibilities to adopt various user access control policies via the WebAssembly sandbox but are prohibited from interacting with the internet directly so that they can’t steal user data (ie, piracy).\n\n-Rong Chen",
"sig": "9da9dab72d56c34e457cf1688af47dddf4e8123fcb435077db7266819293e7331f88cfd50d9e73a3fff59f3b24a57b6a32c848d9a358d4f4696f55eb1ad0c943"
}