https://www.v2ex.com/t/687076

2020 有多少人在听本地音乐
Tezos

最后还是有一个自己的本地音乐库，不然会被这些软件折腾得够呛
wangqh

网易云让我明白了：什么云都是虚的，只有自己盘里的才安心
Osk

可以，就像不信任网盘一样，不信任各个音乐平台
ftu

我电脑本地有收藏音乐，基本是市面上能找到的最高音质，音乐软件只是为了下歌而已
wunonglin

本来一直用在线的，之前是酷狗，后来改成网易云，用了三四年，最近才换成本地，使用 AIMP，不过还没考虑好怎么云端同步，大不了用我自己搭建的 nextcloud 。
liuran

一直在用本地，因为现在出来的新歌完全不听的。老歌都是以前下载下来留存的
sleepy2koala

我一直都用本地听音乐看视频，下盗版二三十年了，现在网速这么快如此的方便……
用平台找到了好听的新歌都会找一份无损的保存在本地……
0x11901

不能依赖任何云平台,
dioxide

2020 年，到现在一直都是喜欢的音乐买正版碟，一千多张了已经
syc721

我就是，一方面是版权不互通原因，另一方面喜欢的歌曲一部分是小众音乐，很难找到在线资源，所以一步到位，把自己的歌单所有音乐全部整理到了本地，冷门资源就自己找资源、改封面和详情、制作歌词，挺艰辛的。。。
SEVLT

我两年前开始基本是本地的了。
jellybool

本地音乐 70GB
随便你们怎么瞎搞，我自岿然不动
mikukonai

自己的在线音乐库 - Synology Audio
chevalier

我只听本地音乐
xuanbg

都 2020 年了，我还在用 iPod nano 呢！丢在车上听本地。
Roykira

我想啊，在线的经常听不了。
可惜以前的硬盘没了，又懒得去下载和整理。
taby

版权大统一之前不会用流媒体，一直有收藏 iTunes AAC 的爱好
VikingX

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

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

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

这里还要谈一个话题，系统的可扩展性。
一个汇集所有个体数据的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、生成账号与关注账号共同连接的【公告中心】（如果中心开启缓存功能）。

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

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