当前互联网最大的问题在于寡头垄断了用户数据，通过规则影响和控制用户行为，并获取巨额利润。垄断造成了互联网企业的极端贫富分化，抑制了竞争和创新，互联网正在失去发展的活力。打破寡头对互联网的垄断，成为越来越迫切的需求。
Leither是一个去中心化的云操作系统，能够以去中心化的方式重构传统的互联网平台业务，让用户重新掌握数据的所有权和使用权。Leither云系统包括去中心化的文件系统、数据库、应用体系、用户安全体系、网络体系等模块；在应用体验和协议上尽可能与传统兼容。相较于传统的云服务模式，应用体系有以下优点：开发应用极简单;系统资源消耗极低;带宽流量低成本;可以用简单的方法实现弹性伸缩。
在Leither上对标一个传统互联网应用，比如淘宝，发起者只需创建一个Leither组织，写好共识合约来描述项目参与方的通证分配机制。通证是用户贡献的凭证，可以按比例获取组织的业务收益；可以用于交换这个组织提供的服务，服务包括组织的业务本身、流量广告、节点信息路由、域名解析、内容检索、数据备份、业务支撑的带宽存储空间、CPU算力、合约验证、挖矿时的质押等。
组织参与者包括发起者、投资者、开发者、内容或服务提供者、设备支持者、运营推广者等。组织业务收益的分配通过共识机制保证。设备支持者对应区块链项目的矿工。设备既可以完成原来的记帐功能，也可以支撑更有价值的组织业务。和传统的区块链相比，Leither区块链在价值、成本、效率、功能、隐私等方面都有优势，更重要的是完全符合法律法规。
本文分上下两篇：
上篇介绍了弥媒和应用系统。讲如何把互联网平台业务进行肢解。
下篇介绍了组织和共识机制。讲如何通过共识机制，协调参与各方的利益，促使更多的人参与进来。
本文为上篇 下篇参见 组织和共识机制
本文中涉及的相关概念和定义如下：
-
数据
存储在介质的信息称为数据。数据结构定义如何存储、组织数据。数据结构是指相互之间存在一种或多种特定关系的数据元素的集合。 -
应用
数据不直接作用于外部世界，通过程序和外部世界进行交互。程序分系统软件和应用软件（Application），处理用户数据的是应用软件，简称应用。应用是各种程序设计语言编制的应用程序的集合，可以拓宽计算机系统的应用领域，发挥硬件功能。 -
弥媒
弥媒是Leither系统中最核心的创意，参考基因和弥母（Meme）的概念创制而成。弥母可以简单地理解为文化的基因，是一种可以通过模仿等方式在人与人之间传播的文化或者行为元素的载体。弥媒是互联网中的信息的载体，描述了信息数据的存储方式，也定义了信息相关的应用操作，包括不限于打开、生成、存取、保存、检索、展现、用户交互等；弥媒之间有引用关联，可以构建出复杂的互联网应用和服务。
-
Leither
Leither是一个弥媒的容器，也是一个超轻量级的去中心化的云操作系统。
Leither能够以极低的资源支持常见的互联网应用，例如网站，公众号，小程序，APP等；
Leither系统实现了认证体系、应用体系、文件和数据库系统、域名和网络系统。API支持常见的四十多种语言。 -
节点
Leither OS内核文件只有6MB，可以运行在常见的操作系统上，如Windows、Linux、FreeBSD、Darwin、Android等；由于对硬件要求极低，PC、手机、NAS、路由、树莓派等各种设备均可支持Leither。运行了Leither OS的设备称为Leither节点，简称节点
- 一个节点，可以当成轻量级的主机使用；
- 两个节点，可以互助，进行数据互备、容错和均衡，域名解析和路由等操作；
- 多个节点，能够以去中心化的方式重构常见的互联网应用。
弥媒可以在节点之间自由流动，从而实现去中心化的目的。
-
现代社会完全依赖于互联网
互联网一步步占据了社会的经济核心。2019年，仅中国线上交易额就达250万亿人民币。 -
互联网通过大数据影响社会
大数据的本质是收集数据和控制规则；进而影响和控制个人行为，并创造暴利的商业模式。
-
最核心的数据已属于寡头
社交相关的数据归腾讯， 电商相关的数据归阿里；其他重要的数据也分别落入两者相关的系统内。 -
通过规则制造了层层壁垒
通过系统应用规则进行保护; 通过现行的法律法规保护；通过生态潜规则进行保护。 -
利益和机会属于寡头
90%的利润被AT系所获取，财富集中速度越来越快；阿里和腾讯市值超过10万亿人民币；稍大一些的创业或投资机会，几无例外都落入了寡头手中。
-
普通用户，任人宰割
没有隐私，是一系列的数据标签；没有自主，是可以被引导控制的数学模型。 -
中小企业，进退失据
在大数据面前，每个企业都变成了透明体，机会和利润被压到了边缘；
腾讯平台上的游戏厂商分成10%都不可得；大部分电商都处在生死线上。 -
投资环境，机会丧失
新投资机会出现的时候，最终都不可避免的落入阿里和腾讯这样的寡头手中；
社会内卷化，我们很久没有听过普通人逆袭的故事了。
-
美国军方发明了互联网，没有控制获利
互联网源自美国军方的APARNET；互联网的架构从创建那天就是开放的，去中心化的。 -
运营商构建了国内网络，没有控制获利
国家通过国企业投入巨资，在全国范围通水通电通路通网；国企运营商不计回报构建了世界上最大的互联网；投入的4G、5G基站都是占世界一半以上。 -
少数公司通过几个应用控制了互联网
国内互联网被阿里、腾讯系控制； 海外互联网被脸书、谷歌、亚马逊、微软等公司控制。
- 欧洲
没有互联网巨头，相关行业被美国企业控制。为了保护用户和中小企业。欧洲制定了严苛的法规，频频开出天价罚单，在实践中这些措施作用有限。 - 美国
特朗普在竞选时，以及通过剑桥分析为代表的公司对用户数据进行深度挖掘，把握用户的政治态度和立场之后进行精准的政治广告和虚假新闻定向推送，进而干扰了美国总统的选举结果。 特朗普竞选连任的时候，特朗普的言论被各平台限流贴标签，直至被各大互联网平台封杀，使之无法和支持者进行互动，从而连任失败。
当前，美国两党不断扩大针对科技行业的反垄断执法力度，并在数字时代的当下更新现有的竞争法。 - 中国
早期的互联网是产业资本，促使了国内生产力的进步，为社会创造了不少增量财富。近几年，国内市场饱和，互联网寡头转向存量市场，利用自身的资源和资本优势开始挤压中低层人民的生存机会。目前成了国家所严格管理的金融资本。 近期，从蚂蚁公司上限受限开始，阿里腾讯都受到了反垄断的处罚
互联网日益中心化，少数寡头垄断了用户数据，通过规则影响和控制用户行为，并获取巨额利益。打破寡头对互联网的垄断成为民众越来越迫切的需求。
我们的目标是构建去中心化互联网。在分析问题提出方案之前，需要整理一下计算机和互联网发展各时期的需求，以及当时为解决这些需求而提出的方案模型。这些需求如果不能被满足，新的方案就是不完备的，无法替代现有的方案。
计算机诞生初期，科研人员通过编写程序使计算机解决具体问题，这些应用催生了最早的数据需求。后续随着应用功能复杂，应用也产生了大量的相关数据。
在Unix中，设计了文件这样的数据载体；同时为了管理文件和存储介质，设计了文件系统。
一切皆文件，所有信息相关的设备都通过文件表达。
随着应用的增加，需要表达文件和应用之间的关联。在DOS中有了扩展名的概念。到了Windows中，扩展名已经可以和应用进行绑定。
在电子邮件的MIME中，对文件（附件）类型有了严格的定义，目前的浏览器都对这个定义进行了支持。
为了处理复杂的数据关系，数据库应需求而生。数据库还是封闭的数据集合，是一个体系内的关联关系。
缺点：数据存放在封闭空间，不能自由流动，限制了价值最大化
WWW从规则上定义了数据和数据之间跨文件跨主机的关联。数据可以跨节点关联，突破了主机空间对数据的限制。互联网诞生，信息大爆炸。门户网站充分利用了这一特征，获得的蓬勃的发展。
缺点：基于链接的关联不够精确稳定。
信息大爆炸，产生了检索的需求。Goolge通过给数据附加标签的属性，提供了一种根据关键字进行内容检索的服务。
缺点：日益垄断，日益封闭，数据获取规则被干扰控制。
最早的社交通讯工具ICQ、MSN、QQ解决了人和人之间的实时消息通讯问题；Twitter提供了一个更快速简短的信息分享平台；
从MySpace到Facebook一个更系统的社交模型诞生了，这个模型分四部分：
| 序号 | 名称 | 说明 |
|---|---|---|
| 1 | 我 | 主要是管理用户个人相关的的信息 |
| 2 | 朋友 | 用户的关系链 |
| 3 | 应用和服务 | 用户使用的应用和服务 |
| 4 | 消息流 | 用户和外界的互动区，互动对象是朋友、应用、服务等 |
这个系统模型非常成功，后续出的互联网平台产品都在向这个架构靠拢。典型代表是微信、微博、阿里来往、支付宝、一些企业OA系统，都或多或少有这个框架的影子。 缺点：互联网日益垄断，日益封闭，规则被干扰控制
基于破除垄断、构建去中心互联网目标，设计原则如下：
-
一切以用户为中心
用户构建、用户控制、用户享有
A new birth of freedom and that internet of the people, by the people, for the people. -
规则自由开放
- 网络底层协议是开放的；
- 底层操作系统规则是开放的；
- 规则开放，用户才有选择权，用户才有控制权。
- 数据自由流动
在用户许可、安全可靠的情况下，用户数据可以从一个平台流动到另一个平台，可以从一种形式转换成另一种形式。
数据能自由流动，第三方才可以为用户提供丰富多采的应用和服务。
结合计算机和互联网的历史，Leither需要满足如下需求：
- 支持文件、文件系统和数据库
- 支持数据和应用的关联
- 支持跨节点的内容关联
- 支持跨节点的检索
- 支持跨节点数据流动
- 支持去中心化的社交模型
- 支持轻量级的容器系统
- 支持简洁的应用开发方式
- 用户体验要和当前互联网兼容
- 合法合规兼容当下的社会制度
在提出解决方案之前，我们要知道问题是怎么产生的，也就是数据是如何被垄断的。
在传统的操作系统上，文件可以在各终端和平台之间自由存取复制。互联网初期，用户数据访问是通过统一规则是互相开放的。谷歌、微软等大平台都提供了访问用户数据的API。
最早的数据垄断来自于Facebook，它利用各大公司提供的关系链数据构建了自己的社交媒体，然后断绝了第三方对用户数据的访问，用户数据被限制在了FB内部。
随后亚马逊苹果等公司纷纷建立了自己的数据王国。国内互联网巨头，QQ起家的时候没有采用通用的通讯协议。百度通过广告封杀淘宝的时候，阿里系对百度也进行了内容封锁。腾讯阿里大战的时候，也互相进行了封杀。
互联网日益孤岛化，堡垒化，用户的数据被割裂保存在不同的寡头平台。
我们分析一下访问数据的两种形式：
数据->应用
用户可以自由接触到数据，然后调用数据相应的规则。
Windows中，用户可以选择不同的应用打开同一类型文件；电子邮件中，用户可以选用不同的应用打开附件；同一个网址，可以选用不同的浏览器打开。
在这种情况下，用户可以可以自由选择应用。不被单一应用所限制。
应用->数据
用户访问数据时，数据被特定的应用规则保护，限定了用户只能通过一套规则进行访问。
用户在电商平台购物，登录电商平台，查找商品，进行购物； 用户在社交媒体上访问社交信息。
在这种情况下，应用中的算法规则决定了用户访问数据的行为路径。用户的行为被应用中的算法规则所控制。
在编程思路上，以上两种刚好对应“面向对象”和“面向过程”
平台公器化
Microsoft借助操作系统控制了整个PC的应用生态，在办公软件和浏览器等领域都利用操作系统扼杀竞争对手。阿里、百度、谷歌、亚马逊等一些内容站是通过内容检索控制用户数据和行为；腾讯、脸书是通过社交网络控制用户数据和行为。
开源社区利用Linux把操作系统变成了公共平台（公器化）。类似的例子还有Android，芯片开源指令集架构RISC-V。
对于存放用户数据的平台，应该有开源的平台架构。 当前互联网最应该公器化的是社交网络和内容检索两个部分。
数据能自由流动
在最早的操作系统里，用户的文件是可以在不同主机不同系统之间自由复制。数据能自由流动应该成为大家的共识，也应该成为基本的设计规范。
我们可以做三个工作：
- 广为宣传使之成为主流的价值观;
- 促进各国制定法律法规成为行业规范，对于保存在用户平台上的数据，必须支持用户导入和导出的接口;
- 发动类似浏览器插件这样的开源项目，组织研发人员把用户数据从寡头的平台上导入到用户的空间，数据到了用户空间，便可以对用户的数据复活及再关联。
规则从属于数据
数据能自由流动的情况下，用户可以选用不同规则去操作数据；换个说法，尽可能使用面向对象的开发方式，避免面向过程的开发方式。
在面向对象的开发方式中，只要能确保数据对象能够自由流动便可。数据结构通常相对简单，易于逆向获取。在知道数据结构的情况下重构规则相对容易。
用户数据颗粒化
对于耦合在一起的大规模数据，我们是没办法单独剥离的。在设计上应该尽可能的让数据颗粒化。颗粒化的原则是象基因一样，尽可能包含相对完整的信息。
信息相对独立，能够独自和算法规则结合。和外部的关联简洁清晰，能够为算法和规则表达。常见的动态语言都适合算法规则的颗粒化。
数据和数据关联
孤立的数据价值是有限的，不同数据之间应该能够互相关联，这样才能够表达更复杂的内容。
Html之间通过链接进行关联，除了链接不稳定以外，这是非常不错的一种表达关联方式；数据库的数据关联都是内部关联，限制了广泛的信息互动。
传统互联网的数据存放着十亿级用户规模的数据，需要构建大量的数据中心。大的数据中心超过十万台服务器，每个业务通过各种技术方式进行集群处理。这些数据中心需要大量的运维人员进行日常管理。
对于个人数据，规模和复杂度都要低的多，不需要数据中心；但需要新的机制存放用户数据，需要轻量级的云操作系统，类似Solid中推荐的Pod。
数据要回归用户，首先需要一个设备来存放用户数据。这个设备最好是用户拥有的私人物品，成本要可控，轻量级免维护的。
相对于一些区块链提出的同态加密的技术，本方案更加简单有效。完全控制一个数据终端，就完全控制了数据和应用规则。
文件
文件是记录在在存储介质上的程序和数据的集合。文件有一定的格式，我们通常用数据结构来描述文件结构。
操作系统中通常有文件系统管理文件，操作系统通过树状目录来存放文件。
点评：
主要是针对磁盘访问进行了封装，优化了存取流程
WWW（World Wide Web）
在目前的Web标准中，Html5表达页面内容，CSS定义页面的风格排版布局，JS执行页面的逻辑。可以相对完整存放并表达数据。页面间通过链接进行关联，可以组织出大规模的高复杂度的信息内容。
缺点：
只定义到了前端，缺失了后端功能。寡头通过后端控制了整个用户数据。
页面间的关联是基于链接的，链接中的主机和位置是不稳定的。
没有对主机、用户等元素进行定义
基因（GENE）
基因是生命信息的最小片段，DNA或RNA保存一段完整的遗传物质。遗传物质记录了生物对环境的适应信息，这些信息的执行规则保存在生物体内。
生物通过遗传的方式复制之前的环境应对，通过变异加筛选的方式适应新的环境变化。
缺点：
就是每迭一次需要一代生命周期，信息量相对有限，不能表达复杂的变化，改造环境能力有限。
弥母（MEME）
弥母是道金斯在自私的基因一书提出，和基因类似，弥母是文明信息的最小因子。弥母记录了人类对这个世界的所有知识。
这些知识保存在人类的大脑里，在人和人之间传播，也可以保存在各种媒介上。
人类可以在大脑中对外界进行建模，在和外界的互动过程中，每一次反省就是一次迭代进化。“吾日三省吾身”相当于每天进化了三次。相对基因，弥母的进化速度有了数量级的提高。
弥媒由来
信息熵是宇宙和人类发展过程中重要的一个物理量。熵增定律为宇宙演变指明了一个方向。熵也被称为时间之箭。薛定谔在《生命是什么》中提到：人活着就是在对抗熵增定律，生命以负熵为生。
生命把环境的信息记录在了基因Gene里，通过遗传适应之前的环境，通过变异筛选适应环境的变化，生命体则负责解释执行这些信息。
人类有了意识之后，可以在大脑中对环境进行模拟调整，在大脑中处理相应的信息。这些信息的基础单位被查德-道金斯称为弥母Meme
计算机和互联网诞生以后，信息的处理方式发生变化，需要一种新的单位来描述信息，我们称之为弥媒Mimei
除了象基因和弥母一样，弥媒能包含一段信息，同时也定义了和信息相关的规则。
功能实现
基于2.7需求汇总所提的需求，我们实现了如下的相关功能：
- 弥媒通过应用生成、管理、存取、展现、传播
- 弥媒基于内容主题创建，每一个弥媒都有一个唯一ID
- 用户可以设置弥媒的各种权限
- 弥媒和弥媒之间通过引用进行关联
- 弥媒可以运行保存在一个或多个节点上
- 象Git一样，弥媒有版本的概念，版本主要是解决数据的一致性问题
- 节点之间的数据库可以实时同步变化，也可以备份后再进行同步
- 弥媒目前描述的数据类型有数据库和文件，后续会支持流
- 文件系统是特殊的系统类型，基于数据库和文件完成
- 每个弥媒都可以有独立的数据库和文件系统空间
- 弥媒通过不断的修改备份完成内容的继承进化
- 用户也可以用分支的方式完成弥媒内容的变异
Leither是我们实现的一个弥媒容器系统，同时也是一个去中心化的云操作系统
点击查看弥媒相关的API
弥媒特点
| 特点 | 说明 |
|---|---|
| 唯一性标识 | 弥媒的ID和版本机制，可以精确稳定描述信息 |
| 表达复杂信息 | 支持数据库和文件系统，支持弥媒关联，支持应用，可以表达复杂信息 |
| 信息自由流动 | 可以构建关系链和不同的群，弥媒可以根据用户行为在不同节点之间流动 |
| 多元信息检索 | 每个用户都可以为弥媒构建标签，可以通过不同用户节点定制多元的信息检索结果 |
以上特点，后文会详细叙述
传统方式
我们分析一下，各种架构下资源的描述方式：
WWW是通过链接描述资源的，http://服务器地址[:端口号]/路径/文件名[参数=值]
在常见的操作系统中是通过路径来描述资源的，盘符:/路径/文件名
在上面的描述方式中，所有的环节都是不确定的，服务器地址，端口号，路径，文件名，参数都是可变的。现行的方式都无法准确描述一个资源。在IPFS协议中，通过对文件取摘要的方式生成唯一ID。这个唯一ID是基于内容的。内容改变就会生成新的ID。这种不确定性不利于正常的操作和关联。
在弥媒体系中我们提出了新的方案：弥媒ID
在Leither定义的去中心化网络生态中，所有的资源都是用ID来描述的，包括用户、节点、内容、应用等。
用户和节点的ID是基于公私钥产生的，一个文件和数据块的标识ID是基于内容取摘要产生的。
弥媒有内外两套标识：
-
对外的标识是弥媒ID
弥媒ID是代表弥媒的唯一ID,是 弥媒创建时产生，后不再改变。
弥媒ID可用于弥媒的检索、操作、引用关联。
弥媒的数据存在文件或数据库中，每次修改备份之后，会产生一个新版本。
版本号从0开始，每次备份增加1, 依次是:0,1,2,3,4......
为了便于操作，用“last”来代表最后一次备份的版本。 -
对内的标识是内容摘要ID
弥媒的每个备份版本指向一个文件或数据库的ID
ID是根据内容摘要生成的。
弥媒信息
创建时基于以下参数:
| 名称 | 说明 |
|---|---|
| Author | 创建者 |
| AppType | 关联应用 |
| Ext | 扩展类型 |
| Mark | 标识 |
| Create | 创建时间 |
| Right | 权限 |
弥媒的信息用以下结构表达：
type MiMeiInfo struct {
Author string //作者
AppType string //应用类型
Ext string //扩展信息
Mark string //标识
Create time.Time //创建时间
Right uint64 //权限
}弥媒ID是固定的
弥媒ID是基于创建者、关联应用、弥媒类型、弥媒标识产生的。
创建之后，不管怎么改变内容，弥媒ID都是不变的。
通过弥媒ID和版本获取弥媒数据
弥媒在编辑的过程中、备份的时候生成版本，这个版本对应的数据是基于内容摘要的。版本备份之后内容确定不再修改。
可以根据弥媒ID和版本获取到指定的弥媒数据。
弥媒支持文件和数据库系统，能支持绝大多数互联网应用的数据存储需求。
弥媒是把信息进行颗粒化的。针对以下数据，建议进行弥媒化：
- 需要检索的内容
- 需要在用户之间分享的内容
- 需要在节点之间流动的内容
弥媒化可以提前进行，也可以在需要的时候进行转化，后者本质上是原来的弥媒分裂成了两个弥媒，新的弥媒数据从原有的弥媒中脱离，原有的弥媒中分裂出的部分变成了一个指向新弥媒的引用关系。
Leither提供数据库和文件系统，对于用户自用的数据，用户完全可以仿照传统的方式进行开发维护。在这种情况下，是根据用户或应用构建一个大的弥媒。
弥媒的文件和数据库都支持版本机制
- cur代表当前修改中未备份的版本，代表在实时修改
- last代表最后一备份的版本，代表最新的固化内容
- release代表审核过，确定可以对外发布的版本
有了版本机制，我们便可以通过唯一ID获取不同版本的弥媒数据。
可以根据弥媒id和版本号cur获取最新的弥媒数据。
可以根据弥媒id和版本号last获取最后备份的弥媒数据。
也可以根据弥媒id和版本号release获取最稳定的弥媒数据。
也可以根据弥媒id和指定的版本号获取任一指定的版本的弥媒数据。
孤立的数据不能表示复杂的信息，弥媒有了唯一标识ID，可以构建相对稳定的关系结构。信息存储在弥媒的文件或数据库中，存储的格式由关联应用确定。
弥媒之间的关联由引用确定，引用信息包括弥媒ID和引用数。正常情况下数据内容中的语义关联都是由应用规则解释的，系统无法获取，需要应用主动调用API维护弥媒引用。
增加引用相关的接口规范，弥媒相关的应用可以根据语义生成引用情况。
相关API：MMAddRef MMDelRef MMGetRef
大部分弥媒所表达的只是一份内容片段，通过关联性，我们可以表达相对完整，更加复杂的内容。
传统操作系统上的文件系统诞生的背景是计算机都是大型的昂贵设备，上面的应用和数据也不多。文件系统避免了应用直接操作和管理存储介值，从而提高了效率。
随着计算机、互联网和移动互联网的发展，用户、应用、数据都爆炸式增长。文件系统开始暴露出以下缺陷：
- 文件名标识文件不精确
- 检索信息不足，只有路径和文件信息
- 同一个文件会被多次存储
我们把传统的文件系统转化为弥媒框架，进行以下改造：
- 唯一标识：每个保存信息的文件都根据摘要生成ID，作为文件标识
- 当前版本：弥媒的当前版本处理频繁的读写
- 引用使用：不直接保存数据，增加资源引用数，通过引用资源的唯一标识使用资源。
对于文件系统的目录结构，我们也进行信息颗粒化（6.1），对需要分享或需要检索的热门有主题的目录，可以转化为弥媒。
目前Leither采用json格式的弥媒文件保存目录，对于文件较多的目录效率偏低，后续会改成基于数据库方式实现。取摘要的方式类似Merkle树。
6.4.1 Leither系统中用到的文件对象
-
弥媒当前文件
指的是弥媒文件的当前版本，当前文件是可读可写的 -
弥媒版本文件
指的是弥媒的备份文件，备份文件是只读的
由当前版本文件备份生成， 同系统动态分配一个版本号指向这个备份文件。 -
Mac文件
以文件内容的Mac ID为标识的文件，Mac文件是只读的。Mac文件可以被弥媒对象引用。
弥媒的版本文件就是一个版本号指向一个Mac文件。Mac文件也可以由临时文件转换生成。 -
临时文件
由MFOpenTempFile创建生成，进行数据写操作之后。
由MFTemp2MacFile转换为Mac文件。 -
弥媒文件系统
系统内置的一个弥媒类型，描述一个弥媒的文件系统。
可以由MMCreate创建，可以在webdav目录下；
可以通过设置扩展名为.mmfs的配置文件配置或自动生成弥媒文件系统；
可以通过MFOpenByPath打开文件系统中的对象。
注：目前是通过json文件的方式实现的，在文件比较多的时候性能较差，正在规划变成数据库方式实现。 -
操作系统文件和目录
可以把操作系统中的文件目录link到webdav目录下，这时候可以通过MFOpenByPath函数打开操作系统中的文件和目录。 -
弥媒根目录
webdav目录是节点对外展示的弥媒总入口。
可以把操作系统中的文件或目录link到这个目录 也可以生成一个配置文件指向节点内的一个弥媒对象
6.4.2、打开文件
- 弥媒文件
创建弥媒文件：
接口函数MMCreate，参数类型为api.MM_File，返回值为弥媒id
打开弥媒文件：
相关API为MMOpen，返回值为会话id，通过会话id可以操作文件内容。ver如果是"cur",可以进行写操作。其它版本文件为备份过的文件，只能进行读操作。
-
通过路径打开
这种方式打开的是弥媒文件系统或操作系统文件系统中的文件，
相关API：MFOpenByPath -
打开Mac文件
打开挂在某个弥媒下的mac文件，
相关API： MFOpenMacFile -
打开临时文件
打开一个临时文件，用于读写操作，
相关API：MFOpenTempFile
读写操作完成之后转换为Mac文件，
相关API：MFTemp2MacFile
- 关闭文件
除临时文件外，其它文件操作完成后都需要关闭文件。考虑到远程操作文件经常会有异常掉线情况，操作对象的会话id在超时情况下都会自动关闭文件。
6.4.3 操作文件
-
对象方式读写
MFSetObject MFGetObject -
字节数组读写
MFSetData MFGetData -
查询状态
MFGetSize MFStat MFIsExist MFGetMimeType -
目录操作
MFReaddir -
文件系统
FSFind FSMkDir FSRemoveAll FSStat FSRename -
其它
MFTruncate MFCopy
数据库的底层有两种：一种是基于LevelDB，一种是基于BoltDB。两种数据库都进行过底层改造。
LevelDb用于当前版本，可写可读，一致性是基于时序。
写事务时会检查改动的部分是否有第三方同时修改过相应的内容。有改动则提示错误，通知调用端重新执行相关操作，避免写冲突。
BoltDb用于历史版本，只用于读。
API参考Redis，可以操作字符串，哈希表，列表，集合，有序集五组数据类型，支持事务。
-
事务
Begin Commit Rollback -
字符串
Set Get Del Incr IncrBy Strlen -
哈希表
Hmclear Hdel Hlen Hset Hget Hmget Hmset Hgetall Hkeys Hscan Hrevscan HincrBy -
列表
Lpush Lpop Rpush Rpop Lrange Lclear Lmclear Lindex Llen Lset -
集合
Sadd Scard Sclear Sdiff Sinter Smclear Smembers Srem Sunion Scan -
有序集
Zadd Zcard Zcount Zrem Zscore Zrank Zrange Zrangebyscore Zremrangebyscore Zrevrange Zrevrangebyscore Zmclear Zclear ZincrBy
常见的应用模式有以下四种：
本地应用
这是最早的应用模式，应用和数据都在本机。应用间的数据交互通过文件流转。
点对点应用
这诞生于局域网时期，有了网络之后，应用负责直接和另外的终端通讯。这时候每个点上的应用都是平等的。负责自身所有的业务。在节点比较多业务复杂的情况下，通常会选取一个节点负责公共事务。
这是服务器的早期雏形。
客户端服务器模式
随着网络规模的扩大和互联网的诞生，服务器模式诞生了，初期服务器只处理核心的逻辑，大量的具体业务还是由客户端本地处理，这种模式简称CS模式。
浏览器服务器模式
WWW标准制定之后，网站的概念诞生了，可以通过浏览器访问远程服务器。随着js功能变强，越来越多的业务转向了浏览器服务器（BS）模式。
BS模式免除了本地客户端安装配置管理，简化了用户的需求。
各模式融合
随着Html5功能的强大，BS模式中越来越多的业务象CS模式一样放到了前台。
越来越多的APP开发都是基于Html5方式，越来越象BS模式。
Leither Api支持40多种语言，重点支持Html5。因为目前互联网上大量常见的应用形态都是基于Html5完成，包括网站、App、公众号、小程序等。 Html5并不完备，没有为后端数据和业务逻辑制定标准。Leither补充了Html5构建云应用时缺少的环节， Leither提供用户和安全认证机制，提供了应用体系，提供了云端的文件系统和数据库系统，提供了去中心的域名解析机制，冗错及负载均衡机制。
业务前端化
除非必要，业务缺省放在前端执行。这样的好处是用户开发的时候和本地页面开发差不多，不需要学习更多的技术。
瘦节点
在考察测试了手机、PC、服务器、路由器、机顶盒、Nas、树莓派等各种存储终端之后。
手机和PC不能稳定的服务输出，服务器过重限制过多，路由器和机顶盒通常厂家都有一定的限制。NAS和其他可以定制的硬件比较适合。
业务前端化加上个人业务量不大，比较适合这种弱CPU的设备
针对性优化
对于特殊情况，节点也支持批量执行请求，后台任务；
个人终端没有专业的运维人员维护，节点构建和应用安装需要简单，使用过程需要免维护；
对家用网络环境做了优化，提供了去中心化的域名体系，可以实现类似云主机的效果。
应用弥媒化
Leither提供了完整的应用体系，系统中的应用本质上是一种弥媒。
应用体系的详细文档
7.3.1、Html5是互联网的核心标准和规范
目前互联网上大量常见的应用形态都是基于Html5完成.
应用包括网站、App、公众号、小程序等。
7.3.2、Html5并不是一个完整的互联网应用解决方案
Html5标准中只提供了本地化存储方案（Web Storage与IndexedDB），并没有为后端数据和业务逻辑制定标准。这造成了常见的HTML5应用严重依赖后端来实现业务逻辑和数据存储。因为不触碰核心的业务逻辑和底层数据，前端程序员通常在各种开发人员中处于歧视链的底层。
7.3.3、Leither补充了Html5构建云应用时缺少的环节
Leither提供用户和安全认证机制，提供了应用体系，提供了云端的文件系统和数据库系统，提供了去中心的域名解析机制，冗错及负载均衡机制。
7.3.4、Leither非常适合构建云服务
除了能完整构建云应用，Leither系统内的应用和数据资源都是可以流动的弥媒形态，加上负载均衡机制，使得Leither成为构建云服务平台的理想选择。在开发过程中应尽量引导开发者把计算放在前端进行，这样大量减少了对主机的要求。同一台主机保守可以比传统方式高一到两个数量级，两者的效率差可以进行量化计算和直接评测。
7.4.1、开发应用极简单
学习完Html5就可以成构建云应用的绝大部分工作，独自完成网站，App,公众号，小程序的开发。整个过程和开发html本地应用相似。
7.4.2、系统资源消耗极低
Leither系统是为低CPU低内存的设备进行开发的，应用对系统的消耗极低。
应用中的计算缺省使用前端资源，特殊优化时才会使用节点资源，这样大量减少了对节点硬件的要求。
同一台主机保守估计可以比传统方式高效一到两个数量级，可以进行量化评测。
对于超大运算量的业务，可以提供API和专业的计算节点配合完成。
7.4.3、带宽流量低成本
对于大流量的应用，系统可以以高效稳定的方式均衡到家用网络节点上，两者之间的成本相差10倍以上。
7.4.4、可以实现弹性伸缩
系统应用和数据都支持docker一样的空间隔离。应用文件和数据库都支持版本式的备份。
同一台物理主机可以同时支撑多个用户多个应用和相应的业务数据。
支持在域名和链接不变的情况下，应用和数据根据需求在不同物理主机之间进行流转。
弹性伸缩功能由去中心化域名和弥媒机制支撑完成。
信息扩张是生命的意义
基因，弥母是记载了生命的信息，生命存在的意义就是使在些信息占据更多的时空。弥媒存在的意义是使有价值的信息更广泛的传播。
流动的信息才是有价值的
FileCoin中传递了一个错误的概念：数据是资产。数据本质上是一种负资产，设备、硬盘、网络都需要消耗成本。高价值的数据只有流动起来变成流量才能产生价值。支持数据的业务主要是存取。
支撑流量的业务流有以下环节：业务体系开发、内容的产生（制造采集等）、保存、传播、展现、价值实现。内容每一次展现都产生了价值。展现次数和单次展现价值决定内容的产生价值。
信息流动是业务的需求
在传统的互联网中，数据备份、容错、均衡、云业务的弹性伸缩本质上都需要信息进行流动。
信息流动有两种情况：
- 主动保存
通常是因为弥媒的价值比较高，保存能产生后续价值。 - 请求帮忙保存 通常是当前节点的支撑能力不足，需要其它节点帮忙安全备份容错，负载均衡等。
保存的流程：
- 信息弥媒化
信息弥媒化之后，分享的内容可以备份成文件块。 - 节点复制数据
在有对方节点相应权限的情况下，把弥媒的数据块从一个节点复制到另一个节点上。 - 更新弥媒的路由信息
最终内容消费者是先获取弥媒的路由信息，再根据路由信息访问弥媒数据，路由信息中有弥媒的节点信息和最新变动信息。更新弥媒路由信息后，用户可以获取到最新的弥媒信息
前文（2.6）提及了当前的社交模型分四个部分：我、关系链、应用服务、消息流。 Leither中相应的模块如下，详情见相应模块的文档
| 名称 | 说明 |
|---|---|
| 我 | 认证体系确定用户身份， |
| 应用和服务 | 应用模块处理用户使用的应用和服务 |
| 消息流 | 消息模块处理用户和应用间的交互信息 |
后续重点描述关系链和信用模型。
用户（节点）和用户（节点）之间需要有信息和服务交互，交互过程中需要进行量化结算。
在现实世界货币是人和人之间的信用结算工具；在Leither网络中，是通过信用方式进行交换。
每个节点都可以对其它节点进行信用授权，这个授权是允许别的节点可以使用我的节点的服务。节点和节点之间服务量的差是借方向出借方签发的借条，也可以理解成借方发行的货币。对于一个群体组织，组织发行的货币本质上是成员向组织贡献的凭证，这个奉献可以是有价值的劳动、资源等具体能推动组织发展的价值等价物。这个凭证可以向成员交换组织服务或其它价值。
信用标的
信用标的最高的是现实生活中的法币。在Leither网络中，节点和节点之间互助的服务可以作为标的。
可供选择的标的有：存储 带宽 CPU
根据节点网络的特点，其重要性排序如下：带宽 > 存储 > CPU
我们会优选带宽作为节点间结算的基准单位，其他类型的服务通过系数进行转换。此外，信用标的也可以是现实世界的法币
个人信用模型
这种信用模型是用户与用户之间（点对点）的信用证和借条
- 信用证
信用证可以理解为允许先使用后付费的服务量，借条可以理解为已使用未付费的服务量。
信用证包含以下信息：授权方、接收方、信用单位、信用上限，授权方签名; - 借条和货币
借条包含以下信息： 借出方、借入方、信用单位、出借数额、借入方签名。 对于借出方来讲，这是借条， 对于借方来说，这相当于发行了货币 。
信用构建
-
信用授权
关系链在建立的时候，双方有互信基础，可以根据关系的远近进行不同数据量的授权。 -
定期增信
两个节点在建立关系之后，可以通过定期增信的方式增加信用。 -
互助
用户节点在建立的时候，同时具备了提供服务的能力。可以通过主动向对方提供有益的服务获取信用，例如数据备份、均衡、路由、检索、中介等服务。 -
信用撤销
发现对方有严重的违法等不良行为时，用户可以主动撤销给对方的服务。 -
主动获取
用户可以通过线下方式购买或者沟通等行为，促使用户提升信用。 -
信用交换
用户可以通过第三方用户或组织进行信用交换。 组织和信用体系参见 组织和共识机制
交易流程
在有信用的前提下，用户可以通过信用交换服务，同时生成相应的记录。
在超出信用的情况下，服务方停止向对方提供服务。
信用中介
没有直接关系的节点，可以通过中介节点进行信用交换。
也可以通过共同信赖的中间媒介来进行，例如法币、虚拟币，或者后文会提及的群体货币进行交换。
下篇参见 组织和共识机制