先定义可独立系统存在的数据，再构建能够校验、传播数据的系统。
前面已经定义了【公告】及【公告单链】的生成/校验方法，现在来设计【公告】的传播途径。

先思考一个问题：数据的传输是否需要去中心？
我的答案是只要中心是中立的，不限制数据的传输，数据的传输就不需要去中心。
中心可以高效传输数据，毕竟任意两个个体之间拉一条专线是不可能的，多个个体共用若干个中心是必然选择。

我所需要做的是，迫使中心保持中立，但这一点从根上说是做不到的...
我能做的只是，我可以自建一个中心，供我和我的朋友及其他个体中转数据，从而曲折的实现了中心的中立（不中立的中心我不用，这样的中心也就不存在，只有对我中立的中心是存在的）。

这里还要谈一个话题，系统的可扩展性。
一个汇集所有个体数据的xx系统对于单个个体有存在的必要吗？
我的答案是没有。
单个个体能够互动的个体数量有限，能够处理的数据有限，个体只需要能够与有限的个体互动，进行数据交换即可。
因此，并不需要全球统一社交平台，中国个体不用facebook活得挺好，美国个体不用qq也活得挺好，甚至中国个体不用qq、微博、豆瓣、抖音也可以活得挺好。
我理想中的系统是可扩展的系统：
1个人用，数据在本地。
2个人用，数据是在各自的本地，通过直连或者中心转发来传输数据。
N个人用，数据还是在各自的本地，通过直连或者中心转发来传输数据，单个中心转发数据的功能是一样的，只是服务能力有差距，比如有的中心可以连接1万个体，有的中心可以连接100万个体，有的中心开启了账号限制，只接受特定账号的连接，或者排斥部分账号的连接。个体与中心的连接是多对多的关系。
中心的运营个体可以拒绝其他个体，个体也可以选择甚至自建中心。
而不是像微信这种中心，一旦建立形成规模，拒绝使用或被限制使用对个体来说几乎是不可承受的。

说了这么多，接着讲【公告】的传播，设计【公告中心】。
客户端默认是不接受任何【公告】，也就是deny all。
当个体明确关注某个账号后，客户端会向【公告中心】请求该账号的【公告】，举例：
{
"Action":201, //表明这条消息是请求1条【公告】
"Address":, //【公告】的签发账号
"Sequence":, //【公告】的序号
"To":, //消息的转发目标账号
"Timestamp":,
"PublicKey":"",
"Signature":""
}
这条消息的意思是让【公告中心】向To转发这条消息，获取【Address的第Sequence条公告】。
如果【公告中心】缓存了【Address的第Sequence条公告】，就将该公告转发给请求账号。
如果没有缓存，就将这条消息转To。
如果To在线，To就会将该公告作为1个对象，发给【公告中心】，举例：
{
"Action":101, //表明这条消息是反馈1个对象
"Object":,
"To":, //消息的转发目标账号
"Timestamp":,
"PublicKey":"",
"Signature":""
}
这里的Object是1条公告，比如
{
"ObjectType":101,
"Sequence":1,
"PreHash":"F4C2EB8A3EBFC7B6D81676D79F928D0E",
"Quote":[],
"Content":"o22Zhy8MzQYemARcftajENtfikjbhTNiqg：自主可控",
"Timestamp":1583719468574,
"PublicKey":"03D5AD191ADEA2857AC05E1D64075ED911C81CF36CEB8B230B1D68222801B0ADE7",
"Signature":"3044022001CE5500C78F310F2627F0B9FA6E2E913DC533B8EC0FAFA0199B5BBF1A517CA802205A714BA53834B85D031AA65AA166641BD52831327DF52998F5C77816E08815DE"
}

【公告】存储于那些地方
1、【公告】生成账号的本地
2、生成账号的关注账号的本地
3、生成账号与关注账号共同连接的【公告中心】（如果中心开启缓存功能）。

【公告中心】事实上是一个它连接账号集合形成论坛或微博，一个【公告中心】连接的账号越多，其缓存的【公告】（也就是帖子）就越多，同样可以形成类似于微博、贴吧之类的巨头，但是这样的巨头确无法妨碍个体的自由，因为个体可以带着自己的和已获取其他个体的【公告】，随时选择其他的【公告中心】。

【公告】是对标微博、论坛、贴吧等，个体对转播范围不太在意的网络系统。
强制将主题、回复归一到相同形态。
强制完全解放传播范围，一经被获取，传播完全失控，删贴几乎不可能。