【提案】dwebcard

[Gaubee]

这是一种新的 dweb-browser 的原生资产，与 dwebapp 同级别。

以下是对它的属性的简单概述：

1. 它是单个文件 html 文件，但后缀是 .dcrad.html。
   1. 它的结构相对严格，需要定义“封面”、“内容”
   2. 封面是只能是 svg/img 代码（默认不支持 svg-animation），同时不允许 js。因为预览的时候，会直接提取这部分的代码来进行渲染。
2. 它被禁止使用 indexeddb、localStorage、cookie、sessionStorage 等浏览器存储。
3. 它被禁止使用网络。
   1. 如果要存放视频，“卡包应用”自带视频播放器，因此虽然网络访问被禁止，但是视频播放的源可以被播放器播放即可安全播放视频。
4. 它自主携带数据，通过特定的接口数据可读可写。写入的数据直接存储到 .dcard 文件中。
   1. 数据接口有两种：一种是“可擦写数据”，和传统可读写数据库一样，可以随意修改（就跟你使用铅笔在卡片上进行修改涂写一样）
   2. 第二种数据接口是“永久数据”，一旦写入，会附带签名，将无法再修改。这些数据会以特定的形式展示在卡片中（区块链思维）。
5. “card.browser.dweb 卡包应用”用于管理所有卡片
   1. 默认存储在“文档/dwebcard”中
   2. 内置了分享能力，包括面对面发送等
   3. 其它 dwebapp 可以通过与 card.browser.dweb 进行通信，以实现卡片的增加，修改，查询。

      卡片中可以配置信任的域，对于信任域，无需授权即可进行访问，否则需要用户通过 pick 的方式基于访问的权力。
      如果要配置共享的信任域名，要求使用 *.std.dweb，这样应用才能通过 dwebprotocols 来访问它。
      同时，这里的通讯访问，可以独立访问卡片的数据，也可以访问卡片的封面

意义和作用

1. 它是单文件，易于传播、分享、收藏
   1. 可以用于贺卡
   2. 可以用于实现某些应用需要构建关系网的需求
2. 把它当作一个数据库，同时它自带了表单界面
   1. 可以作为分布式社交的数据：
      1. 比如发一个文字或者推文，就是创建一个 dwebcard；
      2. 转发、点赞、点踩就是在这个 dwebcard 的永久数据区域追加数据并签名
      3. 这样一来，某人只要发了一条数据，就可以形成证据链
   2. 配合一些联网应用，可以用来做益智小游戏，来实现对数据的写入（利用联合签名）
   3. 可以作为合约文件，比如传统的合同文件，以及区块链的智能合约
   4. 可以用作聊天存储：
      1. 这样就不需要自行所谓的备份，就是直接读取本地文件即可看到结果
3. 它存储在本地文件夹中，即便用户卸载了整个 dweb-browser，它作为 html 文件仍然可以被只读浏览
4. 它无需安装，即可直接运行，同时禁用了网络访问，避免其它渠道的恶意注入和数据泄漏
   1. 比如可以用来做小游戏，比如把往年 13kbjs 的游戏打包一下，就成了一个个“游戏卡带”
5. 它带有签名，可以用作数字资产。一个 dwebapp 可以围绕这种数字资产来构建应用

   任何的数据界面都是数字资产，这样一个用户用下来，即便 dwebapp 卸载了，也能留下一堆用户的数据使用 dwebcard 存储在本地

如何开发构建，以及注意事项

1. 使用 vite-plugin-singlefile 打包出单文件
2. “卡包应用”会提供常见的卡片编辑器，这样即便是普通人，也能不依赖程序员来构建卡片
   1. 编辑器主要包含两个方面：
      1. 封面编辑器：一个简单的 SVG 画图编辑器
      2. 内容编辑器：一个简单的所见即所得编辑器
         1. 内置组件系统，可以拖拽添加组件，比如布局、图片、视频、3D 模型等
         2. 提供逻辑组件，可以做到一些基本的交互按钮、交互表单等
   2. 编辑器还内置了常见的模板，由 dweb-browser 团队官方提供，满足常见的使用场景

[waterbang]

非常超前的想法，在分布式社交中有重要意义，不过在当前环境中，可能会有很多低价值数据，感觉低价值数据并不值得生成类似dwebcard的产物，上面所说的数字资产，或者个人信用证明就非常合适。

如果要生存视频(或者其他资产，当前以视频为例)，如果能提供两种形式就更好了。

1. 如同上面所说，使用网络资源。
2. 完全本地化，但是文件可能会比较大，不过完全本地化对离线环境友好，并且天然的安全隔离。但是可能分享困难。

[Gaubee]

@waterbang
关于“完全本地化”的设计，是这样的：从系统级别的“卡包应用”出发，它必须安全，必须防止攻击，所以它不被允许访问网络，（但是可以使用JS、使用DOM-API）。

但是大部分的“卡片”并不是用户自己生产的，而是被dwebapp生产的，它是作为文件数据库被使用。因此某个卡片，我只需要配合特定的dwebapp，就能实现各种能力，包括网络访问能力。
比如说我只在卡片中记录一个 网络链接/种子链接，从“卡包应用”看来，就是一串text/html，但是在特定的dwebapp看来，它可以提取这个链接去给用户访问，去播放视频，去下载文件。

我可以在卡片中提供对应dwebapp的下载链接dweb://install，那么用户点击链接自然可以唤醒安装器去安装应用。

---

所以 “卡片”、“卡包应用”、“dwebapp”，三者的关系更像是：“数据库文件”、“数据库应用”，“数据库客户端”