Open Gaubee opened 6 months ago
首先阐述“内置工具”这个计划的出发点。 它对其了 dweb browser 的安全目标，就是要解决用户在网络平台中如何确切地保护自己的权益。因此我们需要通过内置工具这一系列的工程，向整个 dweb 生态提供一系列的基础模块。 在开源开放的背景下，用户可以最大程度地信任这些内置的基础模块，从而在互联网上达成一些列标准化协作的同时，将整个协作过程的数据所有权回归给用户。用户也因此可以甄别那些互联网服务是真的是在解决用户问题，而哪些互联网服务只是想用数据裹挟用户。 而我们作为这些基础模块的开发者贡献者，也务必切记，这些基础设施是属于每一个人的。
关于 dMessage 这个应用模块，它的名字其实就是“消息”、“短信”、“iMessage”的变体。 它是要解决聊天问题？ 不是。 它要提供一个可视化的数据交换空间。
我举一个很简单的例子，大家还记得 20 年前的诺基亚时代吧。那时候还很少有互联网游戏，但是却有联机游戏，比如蓝牙联机。 我们比如说一款象棋游戏，他其实是可以以文字化为基础，然后再进行可视化的。 现在假若开发者想要开发一个象棋游戏，他想实现写一个联机对战的功能。传统开发方式里，开发者还得自己去购买服务器。
因此，我们能不能让“dMessage”来替代“蓝牙”作为一个通讯协议，来解决这类对实时性要求不高的联机场景。
也因此，dMessage 的主要视图并不是传统聊天软件的“对话 Chat”为条目，而是“事件 Event”为条目。 用户可以在主界面里快速地新建事件：发起与某人的对话；或者是处理接收到的事件。
因此 dMessage 更像是一个面向人的行为习惯去设计的数据中心，在这里数据被以人能接收的方式一条条记录着，应用也应该尽可能遵循人类可读的方式去运作。
dMessage 是日志型数据库，只能通过追加内容。 dMessage 提供写入服务给其它模块，因此他们属于协作关系，其它模块可以告诉 dMessage 哪些数据它能处理，而哪些不能。 dMessage 是可扩展的，因此我也不一定要在象棋游戏上进行我的游戏，我可以在 dMessage 上打开象棋游戏的“事件文件夹（Event DB）”，直接开启一个新的对话，发送：“开新局，炮二平五”。 假如社区有人开发了更好的象棋机器人，那么我可以直接将这个数据库接入给它。这才是我们所要强调的，在这个标准下，用户数据真正意义上属于用户。 同时，因为是日志型数据库，我还能同时让我本地上的两个应用同时接入这个数据库，那么我就可以看两个象棋游戏机器人自己对弈了。
以上列举了一些基于这个 dMessage 基础模块的一些简单用例，它还能做更多的事情，比如让更多的模块都一起接入这个数据库。
但 dMessage 这种模式也是有很大的局限性的，比如开发一个 MUD 游戏时，客户端是否要承担所有的数据数据校验，如果不能，它就无法单纯作为一个“单机游戏联网模式”来看待，那么开发者本身就需要投入传统的游戏开发方案，那么也就意味着它需要额外再付出对 dMessage 的适配成本。虽然我们相信我们可以将这个学习成本降得很低，比如提供特殊的“input”组件。
但不论如何，用户仍然需要这样一个基础设施，它将作为 dweb 生态中一种人机交互的新标准存在。
相比传统联网游戏的开发，一个专门的服务器固然有它的好处，能做现在很多互联网企业在做的事情。但是，我们只是在开发一款象棋游戏软件而已，不是吗。我并不是在否定当下互联网模式，它固然有它的优势，这里我只是在提出围绕以人为本的另一种软件开发的模式选择——并不是要颠覆什么，只是想让用户多一种选择。
大背景
首先阐述“内置工具”这个计划的出发点。 它对其了 dweb browser 的安全目标，就是要解决用户在网络平台中如何确切地保护自己的权益。因此我们需要通过内置工具这一系列的工程，向整个 dweb 生态提供一系列的基础模块。 在开源开放的背景下，用户可以最大程度地信任这些内置的基础模块，从而在互联网上达成一些列标准化协作的同时，将整个协作过程的数据所有权回归给用户。用户也因此可以甄别那些互联网服务是真的是在解决用户问题，而哪些互联网服务只是想用数据裹挟用户。 而我们作为这些基础模块的开发者贡献者，也务必切记，这些基础设施是属于每一个人的。
简介
关于 dMessage 这个应用模块，它的名字其实就是“消息”、“短信”、“iMessage”的变体。 它是要解决聊天问题？ 不是。 它要提供一个可视化的数据交换空间。
我举一个很简单的例子，大家还记得 20 年前的诺基亚时代吧。那时候还很少有互联网游戏，但是却有联机游戏，比如蓝牙联机。 我们比如说一款象棋游戏，他其实是可以以文字化为基础，然后再进行可视化的。 现在假若开发者想要开发一个象棋游戏，他想实现写一个联机对战的功能。传统开发方式里，开发者还得自己去购买服务器。
因此，我们能不能让“dMessage”来替代“蓝牙”作为一个通讯协议，来解决这类对实时性要求不高的联机场景。
也因此，dMessage 的主要视图并不是传统聊天软件的“对话 Chat”为条目，而是“事件 Event”为条目。 用户可以在主界面里快速地新建事件：发起与某人的对话；或者是处理接收到的事件。
因此 dMessage 更像是一个面向人的行为习惯去设计的数据中心，在这里数据被以人能接收的方式一条条记录着，应用也应该尽可能遵循人类可读的方式去运作。
dMessage 是日志型数据库，只能通过追加内容。 dMessage 提供写入服务给其它模块，因此他们属于协作关系，其它模块可以告诉 dMessage 哪些数据它能处理，而哪些不能。 dMessage 是可扩展的，因此我也不一定要在象棋游戏上进行我的游戏，我可以在 dMessage 上打开象棋游戏的“事件文件夹（Event DB）”，直接开启一个新的对话，发送：“开新局，炮二平五”。 假如社区有人开发了更好的象棋机器人，那么我可以直接将这个数据库接入给它。这才是我们所要强调的，在这个标准下，用户数据真正意义上属于用户。 同时，因为是日志型数据库，我还能同时让我本地上的两个应用同时接入这个数据库，那么我就可以看两个象棋游戏机器人自己对弈了。
以上列举了一些基于这个 dMessage 基础模块的一些简单用例，它还能做更多的事情，比如让更多的模块都一起接入这个数据库。
但 dMessage 这种模式也是有很大的局限性的，比如开发一个 MUD 游戏时，客户端是否要承担所有的数据数据校验，如果不能，它就无法单纯作为一个“单机游戏联网模式”来看待，那么开发者本身就需要投入传统的游戏开发方案，那么也就意味着它需要额外再付出对 dMessage 的适配成本。虽然我们相信我们可以将这个学习成本降得很低，比如提供特殊的“input”组件。
但不论如何，用户仍然需要这样一个基础设施，它将作为 dweb 生态中一种人机交互的新标准存在。
结束语
相比传统联网游戏的开发，一个专门的服务器固然有它的好处，能做现在很多互联网企业在做的事情。但是，我们只是在开发一款象棋游戏软件而已，不是吗。我并不是在否定当下互联网模式，它固然有它的优势，这里我只是在提出围绕以人为本的另一种软件开发的模式选择——并不是要颠覆什么，只是想让用户多一种选择。