反应过来主题应该还要加上个显示 license 的功能，但同时又不想把 license 仅仅局限于 Creative Commons 类的，所以稍微查了一下，在这里记录一下各种适用于文字作品的 license。

主要来源请见 Various Licenses and Comments about Them. 中文版： 各类许可证及其评论.

我看着 reStructuredText 的文档绝望极了，真的比 markdown 复杂多了 T_T。我尝试着在这里做点笔记。

1 与 markdown 的比较

reStructuredText 对中文的体验极其不友好，
因为它很多结构（表格/标题）要求宽度对应，但是中文毕竟和英文跨度不同，
很多编辑器甚至处理器可能都有不同的处理方式……
不爽。
所以下面的表格用英文了。

相邻的两个块之间要用空行隔开。

/	Markdown	reStructuredText
Title	# h1 ## h2 ### h3 etc.	========== h1 ========== or: h2 ---------- Must be wider than the text # * = - ^ ” could be used [1]
Bold	**bold**	**bold**
Italic	*italic*	*italic*
Blockquote	> quote1 > quote2	not blockquote here indent and you get one another line nested another
Inline Code	`code`	``code``
Block Code	``` code ```	:: code
Footnote 2		[1]_ and later the page: .. [1] footnote could be indented
Link 2	[name](link)	link or `name <link>`_
In-page links 2		target_ or `target`_ where target could be titles, footnote, definitions, etc.
Lists	:: one two bullet and - * + could be used	same, same.
Images		.. image:: link :alt: alttext

.. contents:: 目录标题
    :depth: 2

.. csv-table::

    "第一行第一列","示范一个内嵌代码块：

    .. code:: python

        a = [1, 2, 3]
        print(""No Python"")"

a = [1, 2, 3]
print("No Python")

.. sectnum::

.. TEASER_END

1

1

3

3

2

2

3

3

5

5

4

4

2

2

2.2

2.3

3.4

3.4

3.5

1.1

a

test

test

waht

what

（只是个簡单的筆記）

原文地址：uninstall - Remove documentation to save hard drive space - Ask Ubuntu

因為 VPS 上實在不需要 man pages 等的文档，但是安裝时又費时間，所以想永遠把它關掉。摘錄如下：

# Create /etc/dpkg/dpkg.cfg.d/01_nodoc

path-exclude /usr/share/doc/*
# we need to keep copyright files for legal reasons
path-include /usr/share/doc/*/copyright
# if you also want to remove the man pages uncomment the next line
#path-exclude /usr/share/man/*
path-exclude /usr/share/groff/*
path-exclude /usr/share/info/*
# lintian stuff is small, but really unnecessary
path-exclude /usr/share/lintian/*
path-exclude /usr/share/linda/*

find /usr/share/doc -depth -type f ! -name copyright|xargs rm || true
find /usr/share/doc -empty|xargs rmdir || true
rm -rf /usr/share/groff/* /usr/share/info/*
rm -rf /usr/share/lintian/* /usr/share/linda/* /var/cache/man/*
# If you also want to remove the man pages do:
rm -rf /usr/share/man/*

本文是这个嘟文 Pleroma 使用 gup.pe 的权宜之计，可能之后的一些改动会在这里更新。

现在 pleroma 帐号还是关注不上 gup.pe 的群组号，原因似乎是 [1] 中 umonaca 提到的 http 头的问题。刚刚测试了一下，这个问题可以通过使用 nginx 来手动设置 http 头来解决： 首先，打开 pleroma 的 nginx 配置文件（按官方教程安装的是 /etc/nginx/sites-enabled/pleroma.conf）； 文件里有一段类似这样的内容：

location / {
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
        ......
}

把这段内容全部复制（复制的内容里应只有一个“}”），粘贴到这一段的那个“}”花括号后面，现在这部分大概看起来像是这样：

location / {
        ......
}

location / {
        ......
}

将其中一个 location 行修改：

location / {
        ......
}

location ~ inbox$ {
        ......
}

在“location ~ inbox$ {”对应的那一块的里找到 proxy_pass_request_headers on; 这一行，在这行下面插入：

proxy_set_header Accept "application/activity+json";

现在这一部分应该看起来像：

location / {
        ......
}

location ~ inbox$ {
        ......
        proxy_pass_request_headers on;
        proxy_set_header Accept "application/activity+json";
        ......
}

保存退出，用 sudo nginx -s reload 或者 sudo systemctl restart nginx 重新加载配置。这个时候应该就可以正常关注 gup.pe 帐号了。

（但是不知道会不会有什么副作用。 :blobcatnotlikethis: ） （不知道什么时候 gup.pe 会把 header 改过来。） （还有顺便安利一下 QOTO 推出了群组服务器 https://groups.qoto.org ，和 gup.pe 差不多，但是需要手动创建群组，创建人可以编辑群组的简介并对关注者正常进行 block 等操作，也可以像正常帐号一样上锁来手动批准关注。）

[1]: https://github.com/wmurphyrd/guppe/issues/21#issuecomment-716452245

词汇 Activity Vocabulary

原文见：activitystreams-vocabulary/

Activity Streams 2.0 词汇有两部分定义：

1. 描述一个 Activity 的普遍结构的一组核心性质；
2. 描述 Activity 的特定类型以及常见 Artifact 的扩展的一组性质；

实现必须至少支持 Activity Streams 2.0 Core Syntax 里的扩展性质集。

核心类型 Core Types

Json 格式：

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "type": "<类型>",
    <类型对应的属性>...
}

扩展类型 Extended Types

Activity 类型

• Activity
• Accept
  • TentativeAccept
• Add
• Create
• Delete
• Follow
• Ignore
  • Block
• Join
• Leave
• Like
• Offer
  • Invite
• Reject
  • TentativeReject
• Remove
• Undo
• Update
• View
• Listen
• Read
• Move
• Announce
• Flag

• Dislike

• IntransitiveActivity

• Arrive
• Travel
• Question: 增加了 oneOf | anyOf | closed 属性

Actor 类型

Actor 类型是能够执行 Activity 的 Object 类型，包括：

• Application
• Group
• Organization
• Person
• Service

Object 以及 Link 类型

Object 类型有：

• Ariticle
• Document
• Audio
• Image
• Video
• Page
• Event
• Note
• Place: 新增属性 accuracy | altitude | latitude | longitude | radius | units
• Profile: 新增属性 describes
• Relationship: 新增属性 subject | object | relationship
• Tombstone: 新增属性 formerType | deleted

Link 类型有：

• Mention

属性汇总

属性非常之多。请参见 activitystreams-vocabulary/#properties。

ActivityPub

就我理解，ActivityPub 是在上述 ActivityStreams 格式的基础上扩展而来的一种服务器与服务器（S2S）以及客户端与服务器（C2S）的通信协议。

每一个对象都需要具有 id 以及 type 属性。

用户使用 Actor 表示，需要有 inbox 以及 outbox 属性。 其功能如图。（来自 W3C Copyright © 2018 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply. ）

发给对方 inbox 的对象都应该是 Activity（如 Create Like 等）。

扩展的属性汇总

Object

• id : 唯一标识符，应该是一个链接。该链接应当可以被访问，并返回对应的对象。
• source : 反映了 Note 的 content 的来源（如 Markdown 源码）。source 应为这样的对象 {"content": "I *really* hate JSON-LD.", "mediaType": "text/markdown"}

Actor

• inbox
• outbox
• type : 类型并不一定要是 Person Service 等在 ActivityStreams 里的类型，也可以是 Profile 或其它扩展类型
• following : SHOULD
• followers : SHOULD
• liked : MAY : 用户 Like 过的对象 Collection
• streams : MAY : 一系列其它 Collection 的 Collection
• preferredUsername : MAY
• endpoints : MAY : 可以有以下属性
• proxyUrl
• oauthAuthorizationEndpoint
• oauthTokenEndpoint
• provideClientKey
• signClientKey
• sharedInbox
• url : 被视为该 actor 的个人资料网页链接，不一定与 id 相同
• name : 显示名称
• summary : 个人简介
• icon : 头像

一些具有自然语言的值的属性 name summary 可能需要考虑 natural language support defined in ActivityStreams （天哪这什么噩梦。）

Collection

以下可以是 Collection 也可以是 OrderedCollection

• followers : SHOULD
• following : SHOULD
• liked : MAY : 某用户给出的喜欢
• likes : MAY : 可以是任何 object 受到的喜欢，例如用户，例如嘟文（原则上应该也可以给喜欢点喜欢）
• shares : MAY : 没看懂

OrderedCollection

必须以时间倒序（从新到旧）排序。

• outbox : MUST
• inbox : MUST

“公开”的可见范围

ActivityStreams 只能给某些特定的人发消息。ActivityPub 扩展了一下，当你指定的“人”是 https://www.w3.org/ns/activitystreams#Public 的时候，消息的可见范围是公开的。（似乎根据 cc 和 to 有 PUBLIC 和 UNLISTED 的差别。）

S2S 交互

Create, Update, Delete, Follow, Add, Remove, Like, Block, Undo 这些 activity 必须带有 object 属性，而 Add, Remove 这两个必须带有 target 属性。

请求的 HTTP 头需要相应设置 Accept 或 Content-Type 为 application/ld+json; profile="https://www.w3.org/ns/activitystreams" 或 application/activity+json 。

POST 请求的对象列表由 to, cc, bto, bcc, audience 属性决定。最终的对象列表必须去重，并去除作者（如果作者错误地进入了自己作品的受众列表的话）。

转递（Forwarding）机制

（诶呀看起来 Mastodon（以及 Pleroma 以及 Misskey？）都没有弄这个？）

目的是让用户不关注对话中所有的用户也能接收到（几乎）完整的对话。

当且仅当以下情况时转递：

• 第一次看到这个 activity
• to, cc, audience 里包含本服务器拥有的 collection
• inReplyTo, object, target, tag 是本服务器拥有的对象

SharedInbox 投递

如果有很多用户来自与同一个服务器，并且这个服务器有着 sharedInbox 的话，在投递是可以直接投到 sharedInbox 里，而不用一个一个用户投 inbox。

同时，如果有 Public 的消息想要让更多服务器知道的话，也可以给已知的所有 sharedInbox 都投递一份。

各种 activity 的处理

Create / Delete

收到的 activity 应在 inbox 里出现，可能还可以本地储存一份备份。

Delete 就反过来啦。

Update

应将相同 id 的 object 更换为本 activity 的那个 object。

Delete

删删删。可以换成 Tombstone。

Follow

应该返回 Accept 或者 Reject。从收到到返回可以有时间间隔（等待用户处理），也可以直接永远不返回（隐形 Reject）。

Follow 完之后，如果一个关注者的 inbox 很久都不可达，那么服务器可以考虑把 TA 从 followers 中移除。

Accept / Reject

object 一般只考虑 Follow activity，对应处理即可。其实也可以是其它 object，标准没定死。

Add / Remove

是对 target 属性对应的 collection 的增加/移除操作，除非对应 collection 不属于本服务器或 object 不被允许添加。

（这里没有说谁添加，要验证权限的话可能可以要求 object 和 Signature 的 key owner 是同一个？）

Like / Dislike

喜欢～有用属性是 object。

Announce

就是转发啦。转发 object。

Undo

取消某个 activity。