今日(きょう)(さわ)がしく(たわむ)れ生きる人々の漫画映画(まんがえいが)

Licenses 笔记以及主题实现

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

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

许可证摘选

这里只摘录与 GPL / FDL 兼容的那些许可证吧。

自由文档许可证

这里的文档真的就指的是专门的文档,例如软件的使用手册、课本、字典等。可能可以应用到个人写作中,但是似乎还是直接用 实用作品的许可证 会好一些。

  • GNU Free Documentation License (FDL)

  • FreeBSD Documentation License (FreeBSDDL)

实用作品的许可证

  • GNU General Public License (GPLOther)

  • GNU Free Documentation License (FDLOther)

  • CC0

  • Creative Commons Attribution 4.0 license (a.k.a. CC BY) (ccby)

主题计划的 license

实现思路很简单: 1. conf.py 里需要设置一个默认的 license 选项; 2. 在 Metadata 里面有 license=XX 的就显示相应的许可证,没有就默认; 3. 有些许可证可以附加所有者自行指定的条款,这个就随便留个 license-mod=YY 的设置?

License 选项

首先应该有个 none 选项。

然后 CC 类的基本所有 license 都要能够兼容吧,但这里有个问题就是选项的文字怎么选。 比如是 ccby 呢还是 cc-by 呢? 可能其实 我都要 是最好的选项,然后又得去学 Python / Mako 的 swtich 语句了……

其次是上面列举的所有与 GPL / FDL 兼容的许可证,这个时候真的还是要纠结选项的文字。

License 显示

CC 类的证书都有图标,看起来观感会不错。但是其它的许可证似乎都没有?这大概只能随便显示一下了 :P

reStructuredText Intro

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

小心

推荐几个好得多的博文 都来自于同一个博客: 《从 Markdown 到 reStructuredText》: https://macplay.github.io/posts/cong-markdown-dao-restructuredtext/ 《从 Markdown 到 reStructuredText(二)》: https://macplay.github.io/posts/cong-markdown-dao-restructuredtexter/ 《从 Markdown 到 reStructuredText(三)》: https://macplay.github.io/posts/cong-markdown-dao-restructuredtextsan/ 写得比我详细得多得多得多,还讲到了 reStructuredText 的其它很多很厉害的功能(例如方便的 CSV 表格、Admonition 等等)

与 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

::
  1. one

  2. two

  • bullet

  • and - * +

  • could be used

same, same.

Images

![alttext](link)

.. image:: link
    :alt: alttext
A cat goes here
1

Python 传统上的习惯是:

  • 一级标题(书的一部/一集/part):

    ########
      part
    ########
  • 二级标题(书的一章/chapter):

    ***********
      chapter
    ***********
  • 三/四/五/六级标题(一节/一小节/一小小节/段落):

     title
    =======

    三/四/五/六级分别使用:= / - / ^ / "

2

超链接由两部分构成,一个是显示的文字,一个是链接地址。 reStructuredText 里这个可以拆开,比如:Python_ 这样是定义了显示的文字, 而对应的链接地址可以在另外的地方这样给出:

.. _Python: http://www.python.org/

另外,脚注也可以看作是这种格式的延伸。脚注有一些其它格式: [#name]_ 这样配合:

:: [#name] 自动编号的脚注

会生成自动编号的脚注。

其它

生成目录

使用:

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

表格

一个方便的编辑表格的方法是使用 CSV 表格:

.. csv-table::

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

    .. code:: python

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

显示出来就是这个样子:

第一行第一列

示范一个内嵌代码块:

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

在 Nikola 的特殊用法

因为我用的是 Nikola 这个静态博客生成系统,而在博客相关的功能方面它提供了一些特殊语法。

TEASER_END

.. TEASER_END

博客对每个页面的预览默认是不会缩短页面内容的,所以在主页等页面看到的页面预览就是完整的页面。有时页面太长了,预览最好缩短一下,这个语法标志着预览的结束(预览从页面开头一路到这个标志)。

阿瑟•克拉克《星》

作者:[英]阿瑟•克拉克

译者:杨霞

原发表于《科幻世界》1998.10

重校/修正/补完:黑小喵 & Ent

https://www.douban.com/note/225498768/

http://emp.byui.edu/davisr/202/TheStar.htm

这里距离梵蒂冈三千光年。

阅读更多…

[翻譯] 改觀(Change My View):反 delta 舉措(緩慢更新中)

阅读更多…

Ubuntu Disable Man Pages

(只是个簡单的筆記)

原文地址: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 的权宜之计,可能之后的一些改动会在这里更新。

现在 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

ActivityPub 协议笔记(又一新坑)

词汇 Activity Vocabulary

英文 本文翻译
vocabulary 词汇
activity 活动

原文见:activitystreams-vocabulary/

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

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

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

核心类型 Core Types

类型 说明 属性
Object 基本类型,与 Link 属并列关系 attachment | attributedTo | audience | content | context | name | endTime | generator | icon | image | inReplyTo | location | preview | published | replies | startTime | summary | tag | updated | url | to | bto | cc | bcc | mediaType | duration
Link 基本类型,与 Object 属并列关系 href | rel | mediaType | name | hreflang | height | width | preview
Activity 扩展 Object 新增 actor | object | target | result | origin | instrument
IntransitiveActivity 扩展 Activity 除去了 object 属性
Collection 扩展 Object 新增 totalItems | current | first | last | items
OrderedCollection 扩展 Collection items 属性换为了 orderedItems
CollectionPage 扩展 Collection 新增 partOf | next | prev
OrderedCollectionPage 扩展 OrderedCollection | CollectionPage 新增 startIndex

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 类型有:

  • 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 outbox usage with GET and POST requests

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

扩展的属性汇总

Object

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

Actor

  • inbox
  • outbox
  • type : 类型并不一定要是 Person Service 等在 ActivityStreams 里的类型,也可以是 Profile 或其它扩展类型
  • followingSHOULD
  • followersSHOULD
  • liked : MAY : 用户 Like 过的对象 Collection
  • streams : MAY : 一系列其它 CollectionCollection
  • preferredUsernameMAY
  • 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 的时候,消息的可见范围是公开的。(似乎根据 cctoPUBLICUNLISTED 的差别。)

S2S 交互

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

请求的 HTTP 头需要相应设置 AcceptContent-Typeapplication/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。

[翻譯] 什麼是 /r/changemyview