HTML の <ruby> に思うこと

ニュースサイトから記事本文を抜き出して利用しようという作業をやってみて、<ruby> 要素がほかの要素に比べてかなり異質なものあることに気がつきました。

ニュースの本文は

...<p><span class="colorC"><ruby>気象庁<rt>きしょうちょう</rt></ruby></span>は「もっと<a href="javascript:void(0)" class="dicWin" id="id-0000"><ruby><span class="under">二酸化炭素</span><rt>にさんかたんそ</rt></ruby></a>を<ruby>出<rt>だ</rt></ruby>さないようにしなければなりません」と<ruby>話<rt>はな</rt></ruby>しています。</p>...

のようになっています。BeautifulSoup の .text で単純にタグを削除するだけでは

気象庁きしょうちょうは「もっと二酸化炭素にさんかたんそを出ださないようにしなければなりません」と話はなしています。

と、ルビが本文に混じってしまい、まともな文になりません。事前に rt 要素を削除しておく必要があります。

実際に行った作業は「HTML からタグを除去して本文を取り出す」なのですが、単純に行って得られるものは上記のとおりで、それを「本文」とは呼べないと思うのです。

マークアップ言語

はじめに、

気象庁は「もっと二酸化炭素を出さないようにしなければなりません」と話しています。

という“内容”そのものがあります。これに“意味”をつけるために、たとえば「気象庁」は固有名詞という意味をつけるためにこれを <span> で囲み、それからこの文ひとつでひとつの段落という意味をつけるためにこれを <p> で囲みます。これがマークアップであり、そのためのタグであるはずです。

次の段階で、これをどう表示するか、たとえば固有名詞は文字を赤色にし、段落はそのはじめに改行する、というものはさらに分離してスタイルシートで記述することになっています。

逆向きに考えてみます。ブラウザで表示されるもののソースから表現のスタイルを取り除き、“意味”づけのタグを取り除いたら、残るのは“内容”そのものでなければならないはずです。

ところが今回の例では上述のように、余計なものが残ったままになります。

ルビは“内容”か

私は「ふりがなは内容そのものではなく、それに付け加えているもの」と考えますので、「余計なもの」と書きました。たとえば、ここの言葉は重要と思って下線を付ける、固有名詞ははっきり分かるように文字の色を他と違える、というのと同じで、内容に対して何らか助けのために付け加えているものだと思います。ですから、そういったものを剥ぎ取ったときには残っていてはならないと考えます。

そう考えたときに、現在の仕様の <rt> はかなり異質です。下線や色付けがタグ内の属性(attribute)とそれに紐付けられるスタイルで表現されるように、ふりがなもタグではなく属性で示されるのが適当だと思います。

仮に <span>ruby という属性が定義されているとして

...<p><span class="colorC" ruby="きしょうちょう">気象庁</span>は「...」と<span ruby="はな">話</span>しています。</p>...

と書くのがもっとも自然のように感じます。

既存の仕様である <a> を逆に考えてみましょう。<a> にとって属性 href は、それがなければほとんど意味がないくらい重要なものです。

もっと<a href="example.html>二酸化炭素</a>を出さないようにしなければなりません

だからと言ってもしそれがタグになっていて

もっと<a>二酸化炭素<href>example.html</href></a>を出さないようにしなければなりません

と書かれるものだとしたら、その違和感がわかろうというものです。

<rt> のあり方

前節に書いたように、ルビは属性で指定されるのが自然だと思います。ではどうすればいいのか。

<ruby>関連要素って駄目駄目」に、この問題の歴史(なんと不幸な!)から対案まで解説されていました。この記事をぜひじっくり読んでいただきたい。

この記事の「脱法ルビ」が、当面の対応策です。仕様に反せず、仕様内でできる策です。現状ここまでできるのですから、ここに示されているスタイルをレンダリングエンジン側で装備し、属性名を data-ruby ではなく ruby とできるよう仕様のほうが改訂されたら、当分は現在の <ruby>, <rt> との共存期間があったとしても、もうほとんど解決ではないですか。

……と思ったら、このスタイル、すなわち display: ruby-text を実装しているのは Gecko (Firefox) だけで、Webkit (Safari)も Blink (Chrome) も未対応でした(2018年6月現在)。ひどい状況です。

ルビを実際に使う人やデザイナのほとんどは、ほんの少し首をかしげるくらいはあっても、仕様に従って使うだけで、そのしようがどうあるべきかまで問い返したりはしません。そもそも世界のうちでごく限られた言語だけでしか知られておらず、その中でも使う人はごく少数ですから、問題にする人も滅多にいなければ対応もぜんぜん進まないのでしょう。ほんとうに不幸です。

ニュースのスクレイピングでタイピング練習

ひらがな数文字を打ち返すだけのタイピング練習は案の定すぐに飽きてしまったので、何か別のネタを考えなくてはならなくなりました。飽きないためには膨大かまたは頻繁に更新される元データがあればいい、青空文庫かな、でも小学生に向いているものがどれほどあるかしらん、頻繁に更新されるといえばニュース、でもこれまた小学生向きではなさそう……と思ったら実にぴったりのものがありました。NHK NENS WEB EASY です。ひとつの記事で50字ほどの文が10ほど。意味もわかりやすくて量もちょうどいい。かなり手間をかけて作られているようです。

さて、これをなんとか持ってきてタイピング練習の材料にしようと思ったのですが、何しろ本業でも何でもないので情報を集めるところからスタートでした。今回やっていることは実は「スクレイピング」という程のこともないのですが、そのとっかかりということで、せっかくなのでここに記録しておきます。

環境の準備

NHK NENS WEB EASY のページの肝心な部分は JavaScript で生成されているようで、Python で単純に requests.get(url) とやっても、ブラウザで見ている HTML ソースとは別のものしか得ることができません。そこでまず、ブラウザが実際に表示するページを取得できるようにします。

Debian パッケージ chromium-driver をインストールします。

sudo apt-get install chromium-driver

これを Python から使うためにライブラリ Selenium をインストールします。

pip install selenium

取得した HTML から必要な箇所を切り出すのには BeautifulSoup4 を使います[1]

pip install beautifulsoup4

でインストールします。

ニュースサイトの構造

ニュースサイトによくあることですが、各記事の URL は数字の羅列のような名前で、先頭ページではそれが日々更新されます。

ブラウザのデベロッパーツールで NHK NENS WEB EASY の先頭ページ https://www3.nhk.or.jp/news/easy/ の構造を見てみます。

<div class="top-news-list__pickup news-list-item" id="js-news-pickup">
  ...
  <h1 class="news-list-item__title is-pickup">
  <a href="./k10011463631000/k10011463631000.html"><em class="title"><ruby>日本<rt>にっぽん</rt></ruby>の<ruby>二酸化炭素<rt>にさんかたんそ</rt></ruby>の<ruby>濃度<rt>のうど</rt></ruby>が<ruby>今<rt>いま</rt></ruby>まででいちばん<ruby>高<rt>たか</rt></ruby>くなる</em><time class="time">6月5日 11時30分</time></a>
  </h1>
</div>

最初に大きく取り上げられている記事は <div id="js-news-pickup"> で、その中の <h1> の中の <a> から記事個別ページの URL が得られます。

その記事個別ページを同様にブラウザのデベロッパーツールで見てみると、記事本文は <div id="#js-article-body"> にあることがわかります。これを切り出してくればいい訳です。

スクレイピング

参考にした(というか、ほぼそのままコピーさせてもらった)コードは「Python Webスクレイピング テクニック集」の「JavaScriptによる描画に対応する」です。

ソース中のコメント「ブラウザを起動する」の箇所で、ブラウザのパスを指定する必要がありました。Debian のパッケージを使っている場合

driver = webdriver.Chrome(executable_path='/usr/bin/chromedriver', chrome_options=options)

です。

切り出し

1回めの

        # ブラウザでアクセスする
        siteurl = "https://www3.nhk.or.jp/news/easy/"
        driver.get(siteurl)

        ...

        # BeautifulSoupで扱えるようにパースします
        soup = BeautifulSoup(html, "html.parser")

        # id で特定の要素を切り出す
        href = soup.select_one("#js-news-pickup h1 a").get('href')

で記事個別ニュースの URL が得られるので、2回めは

        driver.get(newsurl)
        html = driver.page_source.encode('utf-8')
        soup = BeautifulSoup(html, "html.parser")
        # ルビを削除
        for s in soup(['rt']):
            s.decompose()

        ...

        # ニュースの本文
        text = soup.select_one("#js-article-body").text

で、記事本文を切り出します。

ルビを削除

ニュースの本文は

...<p><span class="colorC"><ruby>気象庁<rt>きしょうちょう</rt></ruby></span>は「もっと<a href="javascript:void(0)" class="dicWin" id="id-0000"><ruby><span class="under">二酸化炭素</span><rt>にさんかたんそ</rt></ruby></a>を<ruby>出<rt>だ</rt></ruby>さないようにしなければなりません」と<ruby>話<rt>はな</rt></ruby>しています。</p>...

のようになっています。BeautifulSoup の .text で単純にタグを削除するだけでは

気象庁きしょうちょうは「もっと二酸化炭素にさんかたんそを出ださないようにしなければなりません」と話はなしています。

と、ルビが本文に混じってしまい、まともな文になりません。事前に rt 要素を削除しておく必要があります。

この作業をやってみて、rt がほかとは異質なタグ(要素)であることを実感しました。これについてはまた別の記事に書こうと思います。

1文ずつに分解

記事を「。」で区切り、リストにします。「。」自身も含めたいので split が使えません。NHK のニュース記事で全体の最後に「。」がないことはまさかないだろうと仮定して、

        lines = re.findall(".*?。", text)

とします。あとは Errnot がこれを1文ずつ表示するようにするだけです。これでこの bot を相手に XMPP のチャットでオウム返しにタイピングの練習をすることができるようになりました。

それにしても、いろいろ寄せ集めるだけでこれだけできるのですから、便利な世の中になったものだとつくづく思いました。

  1. Python にはじめからある html.parser でもある程度できます。また Selenium にも同様の機能があるようです。

あらためてチャットサポートを構築する

Converse.js という XMPP の Web クライアントを見つけて「チャットサポートを構築する」の記事を書いたのは2014年初頭でした。Converse.js が公開されて1年めほどでバージョンは 0.7.2 でした。

2018年4月現在の Converse.js は 3.3.4 で、かなり進歩しています。情報もあちこちに出てきて、以前は苦労したことも現在では簡単にできるようになっていました。本家ページ以外に情報が散らばっていましたのでここにまとめてながら、あらためてチャットサポートを設置してみます。

PreBind

その前に、今回の構築には用いませんが、以前は私がよく理解できておらず適当に誤魔化していた PreBind について、簡潔に解説したページ PreBind: connettersi senza password がありましたので、紹介しておきます。

PHP のクラス XMPP Prebind for PHP をダウンロードしておき、次のようにインスタンス化します。

<?php 
include 'xmpp-prebind-php/lib/XmppPrebind.php';

$boshUrl = 'https://example.com:5280/bosh/';  // 環境に合わせて変更
$server = 'example.com';           // 環境に合わせて変更
$username = 'your_username';   // 環境に合わせて変更
$password = 'your_password';   // 環境に合わせて変更
$resource = rand(10000,99999); // ここでは5桁の数字。環境に合わせて変更

$xmppPrebind = new XmppPrebind($server, $boshUrl, $resource, false, false);
$xmppPrebind->connect($username, $password);
$xmppPrebind->auth();
$sessionInfo = $xmppPrebind->getSessionInfo(); // array containing sid, rid and jid

header('Content-Type: application/json');
echo json_encode($sessionInfo);

?>

これだけで動かしてみると分かりますが、sid, rid, jid の3つを JSON 形式で返すものです。

次に、Converse.js の初期化の際に、上のスクリプト名( prebind.php だとします)を prebind_url で指定します。

<?php
  $boshUrl = 'https://example.com:5280/bosh/';  // 環境に合わせて変更
  $server = 'example.com';      // 環境に合わせて変更
  $username = 'your_username';  // 環境に合わせて変更
  $prebindUrl = 'prebind.php';  // 上のスクリプトの URL
?>
<html>
  <head>
    ...
    <link type="text/css" rel="stylesheet" media="screen" href="https://cdn.conversejs.org/css/inverse.min.css" />
    <script src="https://cdn.conversejs.org/dist/converse.min.js"></script>
    ...
  </head>
  <body>
     ...
    <script>
      converse.initialize({
        i18n: 'ja',
        locales_url: 'https://cdn.conversejs.org/locale/{{{locale}}}/LC_MESSAGES/converse.json',
        authentication: 'prebind',
        bosh_service_url: '<?php echo $boshUrl; ?>', 
        keepalive: true,
        jid: '<?php echo $username."@".$server; ?>',
        prebind_url: '<?php echo $prebindUrl; ?>',
        prebind: true,
        ...
      });
    </script>
  </body>
</html>

この HTML は誰にも見られることになりますが、パスワードは事前接続にのみ用いられているので、ここに書かずに済むというわけです。

チャットサポートの構築

XMPP サーバーで匿名接続を利用できる場合、Converse.js の初期化時に authentication: 'anonymous' とすることで、実は上述の PreBind はまったく使わずに済みます。

以下、この匿名接続を使ってチャットサポートを組み立てます。

  • 客側は Converse.js で匿名(一時的なJIDを使う)とする。
  • 窓口側のJID(たとえば support@example.com) は共有名簿として匿名接続時に与えられる。
  • 客側の Converse.js は自動的に窓口側JIDを呼び出しチャット窓を開く。

という流れです。

サーバー側設定

BOSH または Websocket

前述の PreBind でもそうでしたが、BOSH(または Websocket)を利用しますので、XMPP サーバーに付属のそれらの機能を有効にしておきます。ejabberd の場合、ejabberd.yml は次のようになります。

listen:
  ...
  -
    port: 5280
    ip: "::"
    module: ejabberd_http
    request_handlers:
      "/ws": ejabberd_http_ws
      "/bosh": mod_bosh
    http_bind: true
    register: true
    tls: true
  ...
modules:
  ...
  mod_bosh: {}
  ...

匿名サーバー

通常クライアントがサーバーに接続する場合は、事前に作成しておいた user@example.com という形をした JID とパスワードが必要になります。匿名サーバーは、そのサーバー名だけを指定して接続を試み、@ より前のユーザー名を乱数のようにそのつど生成して接続します。

サーバーアプリケーション ejabberd の場合、ejabberd.yml に次のように設定して SASL 匿名サーバー (anonymous.example.com という名前だとします) を設定します。

hosts:
  - "example.com"
  - "anonymous.example.com"
  ...
host_config:
  "anonymous.example.com":
    auth_method: [anonymous]
    anonymous_protocol: sasl_anon

なお今回は特に関係ありませんが、匿名サーバーで接続するユーザーについては、悪用を防ぐため権限を絞っておくのが望ましいでしょう。たとえば、別のサーバーとの通信の禁止、MUC 談話室や PubSub ノードの作成の禁止、などです。

窓口側のJID

窓口側のJID(例: support@example.com) の作成は、通常どおり行います。

共有名簿(shared roster)

匿名サーバーの場合、接続のたびにアカウントが新たに一時的に生成されるため、その JID には相手先名簿がありません。そこで、共有名簿(shared roster)という機能を使うことにします。

まず ejabberd の設定ファイル ejabberd.yml でこの機能を有効にしておきます。

modules:
  ...
  mod_shared_roster: {}
  ...

ejabberd のウェブ管理画面の「バーチャルホスト -> anonymous.example.com -> 共有名簿グループ」の画面で、まずひとつのグループを作成します。たとえば

  • 名前: support
  • 説明: サポート窓口
  • メンバー: support@example.com
  • 表示グループ: (空欄)

のようにします。ここで support@example.com は、窓口側(問い合わせを受ける側)の JID です。

さらにもうひとつグループを作成します。

  • 名前: all
  • 説明: 全ユーザー
  • メンバー: @all@
  • 表示グループ: support

ここで @all@ は、「全ユーザー」を意味します。

これで、「anonymous.example.com の全ユーザーの名簿に support グループのメンバー(ここでは support@example.com のみ)を自動的にセットする」ことができました。

Converse.js の設定

チャットウィンドウを設置する Web ページで、Converse.js を読み込むようにいくつかの行を書き加えます。Converse.js そのものを同じサイトに置いてもいいですし、CDN から読み込むようにもできます。

<head>
    ...
    <link type="text/css" rel="stylesheet" media="screen" href="https://cdn.conversejs.org/css/converse.min.css" />
    <script src="https://cdn.conversejs.org/dist/converse.min.js"></script>
    ...
</head>

それから、パラメータとともに Converse.js を初期化することで、そのページにチャットウィンドウを設置します。基本は

converse.initialize({
        websocket_url: 'wss://example.com:5280/ws/',
        authentication: 'anonymous',
        jid: 'anonymous.example.com',
        auto_login: true,
})

です。ここでは BOSH ではなく WebSocket を使う場合です。匿名接続の場合 jid はサーバー名のみにします。自動ログインでサーバーに接続するのですが、このままでは相手先とのチャットを開くところはできません。

自動で相手先とのチャットを開く

この情報は本家ではないところにありました。Converse opening a chat from API の回答で Converse.js の作者がプラグインを紹介しています。

converse.plugins.add('chatsopen', {
      initialize: function() {
        var _converse = this._converse;
        Promise.all([
            _converse.api.waitUntil('rosterContactsFetched'),
            _converse.api.waitUntil('chatBoxesFetched')
        ]).then(function() {
          _converse.api.chats.open('support@example.com');
        });
      }
    });

初期化時にこれを利用するようにします。

whitelisted_plugins: ['chatsopen'],

コントロールボックスは全部隠してしまうこともできます。

blacklisted_plugins: ['converse-controlbox'],

まとめ

以上をまとめて(ついでに他のパラメータも追加して)、チャットウィンドウを設置する Web ページまるごとの例です。

<html>
<head>
    <meta charset="utf-8"/>
    <title>チャットサポート</title>
    <link type="text/css" rel="stylesheet" media="screen" href="https://cdn.conversejs.org/css/converse.min.css" />
    <script src="https://cdn.conversejs.org/dist/converse.min.js"></script>
</head>
<body>
<h1>チャットサポートのページ</h1>
<p>右下の窓で話しかけてください。</p>
</body>
<script>
    converse.plugins.add('chatsopen', {
      initialize: function() {
        var _converse = this._converse;
        Promise.all([
            _converse.api.waitUntil('rosterContactsFetched'),
            _converse.api.waitUntil('chatBoxesFetched')
        ]).then(function() {
          _converse.api.chats.open('support@example.com');
        });
      }
    });

    converse.initialize({
        i18n: 'ja',
        locales_url: 'https://cdn.conversejs.org/locale/{{{locale}}}/LC_MESSAGES/converse.json',
        authentication: 'anonymous',
        websocket_url: 'wss://example.com:5280/ws/',
        auto_away: 300,
        auto_reconnect: true,
        keep_alive: true,
        jid: 'anonymous.example.com',
        auto_login: true,
        allow_logout: false,
        allow_contact_removal: false,
        allow_contact_requests: false,
        allow_muc: false,
        allow_otr: false,
        allow_registration: false,
        blacklisted_plugins: [
            'converse-bookmarks',
            'converse-controlbox',
            'converse-mam',
            'converse-muc',
            'converse-notification',
            'converse-otr',
            'converse-register'
        ],
        whitelisted_plugins: ['chatsopen'],
        forward_messages: false,
        message_carbons: false,
        message_archiving: 'never',
        use_vcards: true,
        view_mode: 'overlayed',
        visible_toolbar_buttons: {
            call: false,
            clear: false,
            emoji: true
        }
    });
</script>
</html>

実際に設置してみたのが次です(サーバー名など変更)。

Mastodon / GNU social はブログである

GNU social のインストール

Mastodon ブームに乗って GNU social をインストールしてみました。

このところ Mastodon が大流行のようで、その流れに乗って mastodon.cloud にアカウントを作ってみて、そこで情報を仕入れていくつかの記事を読んでどんなものかが少しづつわかってきました。割と早い時期に目にしてたいへん参考になったのは「gnusocial や mastodon の哲学」です。

早速自分でもインスタンスを立ててみようかと思いましたが、環境が整っていれば簡単そうなものの、その環境を準備するのが面倒くさい。そこで Mastodon と交流可能な GNU social を見てみることにしました。参考になったのは「GNU socialのインストール」です。

GNU social のインストールは、インストール版 WordPress を使ってことのある人にとっては簡単です。その説明を読めば分かるように、基本的に要件は PHP, MariaDB(MySQL), Web サーバー(Apache など)で、WordPress のそれと同じです。

まず https://git.gnu.io/gnu/gnu-socialから GNU social を入手し、Web サーバーでアクセスできるところに展開します。既に WordPress を動かしているサーバーなら、https://expample.net/social などのようにサブディレクトリでもいいでしょう。

それから、データベースにアカウントを用意しておきます。

そしてブラウザからアクセスします。あとは欄を埋めるだけです。サイト名、データベースのID、パスワード、管理者の名前、パスワードなどです。これで設定ファイル config.php が作られます。

これで終わり。このへんの手順も WordPress の「5分でインストール」にそっくりです。

一人だとちょっとさびしい

GNU social や Mastodon のタイムラインは

  1. 自分の発言
  2. 自分がフォローしている人たちの発言
  3. ローカル = 同一インスタンスのユーザーの(A)の和
  4. ネットワーク = 同一インスタンスのユーザーの(B)の和(だと思う)

があります。おひとり様インスタンスだと、(C)や(D)の意味がないので、ちょっとさびしいです。

要はブログである

おひとり様インスタンスを立ち上げてみて、WordPress そっくりのインストール過程からも感じたのは、「これは要はブログである」ということです。実際「マイクロブログシステム」と言われています。Twitter もそう言われていましたが、同一サーバー(名前空間)にすべてのユーザーがいるためにそれを意識することがなくなっていました。

自分の発言はブログで言うところの「記事」に相当し、その記事にコメントがついたりトラックバックしているようなものと考えることができます。記事を極端に短くして、コメント/トラックバックを短期間に大量に投げ合っているイメージです。「フォロー」というのは RSS で情報をやり取りして自分のブログに相手方の記事を混ぜ込むようなものです。ブログの記事を寄せ集める Planet (そういえば最近とんと聞かなくなった言葉です) に似ています。

このように考えるとストンと腹に落ちました。Mastodon や GNU social は自分の書く記事と大量のコメントをデータベースに蓄え、それを整形して表示するものと言えます(もちろん他のインスタンスに情報を送る機能を持っていて、それが肝なのですが)。デフォルトの GNU social の見かけに対して、はじめから添付されている qvitter を使うようにすると、同じ中身を Twitter そっくりにして表示します。WordPress で言うところの「テーマ」と同様に、GNU social も外見を変更できます(INSTALL の Themes の節を参照)。

それにしても、ブログをぎゅっと圧縮すると、あたかも IRC やネットニュース(NNTP) のような様態になるとは面白いことです。

やっぱりブログである

「ブログの集合体」と考えると、たとえば「そろそろマストドンについて語っておくか」に見られるような批判は、当たらないとは言わないまでもピント外れと言うべきでしょうか。

たとえば WordPress を自分のサイトに導入してブログを始める。それ自体はとやかく言われることではないでしょう。そうやってブログを運用する大抵のサイトは、アカウント作成を開放して不特定多数の人がそこに書き込む権限を渡すようなことはしません。一人か、もしくは特定少数のライターに権限を与えて運用されています。それと対比すれば mastodon.cloud や mstdn.jp はかなり特殊な状態です。逆に、ユーザー側からしても同じです。他所のブログサイトにアカウントを作れるからと言って、得体がしれないのに個人情報を渡すのだとすれば、それはユーザー側にも落ち度があります。何も Mastodon や GNU social の問題ではありません。

サーバーの設置は自由なソフトウェア実装が存在するだけではだめで、十分な性能を持ったコンピューターと十分なネットワーク帯域が必要になる。GNU SocialはPHPで実装されているし、マストドンはRuby on Railsで実装されている。実行には普通にWebサーバーを運営するのと同じだけの煩わしさがある。

これだけサーバーの実行が面倒だと、結局、既存のサーバーを利用するものが大半だろう。その結果、どこかの学生が1個人が運営している怪しげなサーバーに人が集中する。これはとても問題だ。

自分でやってみて実感しましたが、「これだけサーバーの実行が面倒だ」とは思いません。何度も引き合いに出しますが、インストール版 WordPress がこれだけ広がっているなら、それとほぼ同じ手間で設置できるものですから、同じくらい広まる可能性はあります。そもそも知らなかったという人たちが多いのだと思います。私自身、GNU social という言葉はどこかで小耳に挟んでいたものの、それが何かということを知ろうとはしていませんでした。それが今回の Mastodon 大流行でちょっと触ってみる気になったのです。これから雨後の筍のごとく、あちこちでおひとり様インスタンスが立ち上がるでしょう。

ブログシステムの WordPress も近年になってホスティング会社が簡単にセットアップできる仕組みを提供しています。それと同様になればかなり広まるでしょう。さっそくさくらのクラウドのスタートアップスクリプト Mastodon が現れています。

脱中央集権化

ところで、はじめに紹介した記事「gnusocial や mastodon の哲学」でも強調されている理念に「脱中央集権化 decentralization」があります。それは、今回の大流行に関係しているでしょうか。

もし多くの人がその理念を好ましく思っているなら、いま日本で大流行の LINE などより XMPP のようなオープンなメッセージングシステムが受け入れられていてもいいように思います。ところが登場時期については全く逆で、XMPP のほうがずっと前から存在するのに後から出てきた LINE があっという間に広まりました。

理念よりも、何かもっと表面的なこと—たとえば見た目のいいアプリとか—がきっかけのようにも思えます。XMPPサーバーを公開して数年経つのに登録者はあんまり増えていないからなあ。

Gajim で IRC

PC の中を整理していたら、2012年のメモが出てきました。そのまま捨てていいものか判断に悩んだので、ここに転記してから捨てることにします。

Gajim という XMPP クライアントから IRC を使う、というものです。いまさらIRCもないのですが……。

中継先の設定

まず、中継先を設定します。

操作 → サービスを探索 → … で「アドレス」に、IRC中継を行ってくれている適当なXMPPサーバーを入力します。たとえば step.im とします。「IRCトランスポート」を選択し、一番下の「登録」をクリックします。これで、名簿の「中継先」の欄に、irc.step.im ができます。

チャンネルの登録

次に、その名簿の欄のサーバー名を右クリックして、「コマンドを実行…」とします。「Join channel」を選んで「進む」をクリックします。

IRCチャンネル(先頭には#は不要)に、たとえば「wordpress」と入力し、IRCサーバーに「irc.freenode.net」と入力し、「実行」をクリックします。

チャンネルに参加

操作 → グループチャットに参加 → … → 新しいグループチャットに参加 と進み、

ニックネーム (適当に)
談話室 wordpress%irc.freenode.net
サーバー irc.step.im
パスワード (適当に)

のように入力します。談話室名は、IRC のチャンネル名とサーバー名を「%」でつなげたものにします。ニックネームは適当ですが、NickServ に登録しているならそれを入力し、パスワードもそれに合わせます。

……と、5年ほど前のメモを見ながら試しにやってみてできはしましたが、何しろいまでは IRC をぜんぜん使っていないので、いったい何の役に立つのやら。

オンラインストレージ hubiC をバックアップに使ってみる

PC のデータのバックアップは、宅内に複数の PC があるので相互にコピーするという安直な方法をとっていました。安直とはいえこれまでに数回、それに救われたことがあります。

しかし複数と言っても、同じ家の中にあります。ふと、もしこの家が火事になったら……と考えてしまいました。まあそのときには PC のデータどころではないでしょうが。

では外のどこに置けばいいのやら。無料のオンラインのストレージサービスを探してみました。そのうち、25GB もあって Linux からも使いやすそうな hubiC を試してみることにしました。

アカウントの作成

メールアドレスが ID になります。そこに紹介コードを入力する欄があります。どこかで紹介コードを入手してここに入力すると、容量 25GB のところ +5GB の計 30GB になります。なおいったんアカウントを作成すると自分の紹介コードができます。これを誰かに紹介して、その誰かがこの紹介コードを使ってアカウントを作成すると、紹介した側も +5GB され、5人分まで加算されて最大 55GB にまでなります。私の紹介コードをここに書いておきます。XWULCF

Debian で使う

まず、ウェブで hubiC にログインし、My accountDevelopersAdd an application とします。適当な名前と URL を入力します。作成できるとその detail に、Client IDSecret Client が表示されます。

次にローカル側(Debian)の準備です。

apt-get install hubicfuse

で、パッケージをインストールします。なお、ここでは Debian Stretch の これを書いている時点でのバージョン hubicfuse 3.0.0 に従って書きます。Jessie のバージョン 1.1.0 だと設定ファイルの書式が異なるようです。

/usr/share/doc/hubicfuse/README.Debian に書かれているとおり、

/usr/share/hubicfuse/hubic_token

を実行します。

client_id, client_secret,redirect_uri を、さきほどのとおり入力します。その後の質問では、括弧の中のとおり rwwrd のように入力します。デフォルトではないので、そのとおりに入力します。

続いて user_loginpassword を入力します。すると、

client_id=.......
client_secret=.......
refresh_token=.......

の3行が表示されます。これをそのまま ~/.hubicfuse というファイルを作ってそこに書き込んで保存します。

マウント

ユーザーを fuse グループに加えておきます。そしてマウントポイント (たとえば ~/mnt/hubic/) を作っておきます。

マウントは

hubicfuse ~/mnt/hubic -o noauto_cache,sync_read

です。あとは通常の操作で、ここにファイルをコピーするなどできます。とは言っても通信速度は(日本からだと)非常に遅いので、この中でいろいろ作業するのは止めたほうがいいでしょう。せいぜい cprm くらいが無難です。安全と謳っていますが、やはり他人任せにするのは心もとないので、データは手元で暗号化してから送ることにしました。

アンマウントは

fusermount -u ~/mnt/hubic

です。

復元手順はふだんから訓練を

通信速度は非常に遅いのですが、万が一の場合の保管場所ということで、そう頻繁にファイルをやりとりすることもないので、これでよしとします。設定が済んでしまえば通常のファイル操作のコマンドでファイルを送ることができるので、自動化するのも楽です。

しかし復元の手順はこれに頼ってはいけません。何しろ火事になって設定ファイルどころか紙に書いたメモも何もかもが失われている、という状況を想定しておかなければなりません。

そもそもデータを hubiC というサービスに置いたということと、そのログイン名とパスワードは頭の中に入れておかなければなりません。それから暗号化ファイルを元に戻す方法もです。

数か月に一度、その訓練をしておくのがいいと思っているところです。

「ライブドアブログにコメントすると、コメントの著作権はブログ主に」は有効か

事情があって[1] 、ライブドアブログ(livedoor Blog)の利用規約ガイドラインを見ていたのですが、妙なものを見つけました。

「利用規約」

そもそもライブドアは、その利用規約

1.3.1 利用者が掲載等を行ったデータの利用

  1. 利用者は、本サービス等の利用に際して利用者が掲載・表示・送信等(以下「掲載等」といいます。)を行ったデータ(映像・音声・文章・写真・電子メール・メッセージ・アップロードされたウェブコンテンツ、ソフトウェアその他一切のデータをいう。以下同様とします。)につき、当社が、利用(複製、上演、演奏、公衆送信(自動公衆送信における送信可能化を含みます。)、口述、展示、頒布、譲渡、貸与、翻訳・翻案を含み、以下「利用等」といいます。)することを、無期限かつ無償にて、非独占的に許諾します。
  2. 利用者は、利用者が掲載等を行ったデータにつき、当社が自らの判断で、有償・無償を問わず、当社の指定する第三者に対して利用等を許諾する非独占的な権限を、無期限かつ無償にて付与します。
  3. 利用者は、前二項に基づく当社ないし当社の指定する第三者による利用者が掲載等を行ったデータの利用等について、著作者人格権を主張せず、行使しないものとします。
  4. 利用者は、利用者以外の第三者の情報やコンテンツ等の著作物が利用者が掲載等を行ったデータに含まれる場合、当該第三者から利用等の許諾を得、または、当該第三者に著作者人格権を行使させないなど、当社ないし当社の指定する第三者が当該データの利用等を行うについて支障の生じないよう、適切な権利処理を行うものとします。

としています。ここでの「利用者」とは、「本サービス等を利用される方(以下「利用者」といいます。)は、本規約の内容に同意して、本サービス等を利用するものとします。」と定義されています。

これには問題があると私は思いますが、ここにブログを開設しようとする人は登録段階でこの利用規約に同意することになっているので、それはそれでしかたがありません。

「ガイドライン」

ところで、分かりにくいのですが、「利用規約」とは別に「ガイドライン」というものが存在します。

livedoor Blogガイドライン(以下「本ガイドライン」といいます。)は、弊社が提供するサービスであるlivedoor Blog(以下「本サービス」といいます。)のご利用につき、弊社が別途定める利用規約(以下「利用規約」といいます。)とあわせて適用されるものです。よくお読みになられて、本サービスをご利用下さい。

本ガイドラインに規定がない場合、原則として、利用規約の規定が適用されます。本ガイドラインの規定が利用規約の規定と矛盾・抵触する場合、その矛盾・抵触の限りにおいて、本ガイドラインが優先して適用されるものとします。

というものですが、livedoor ユーザーの登録の段階でも、その後の「新しいブログを作成する」段階でも特に注意を喚起されることもありません。

そのガイドラインに次のような節があります。

コメントに関する権利帰属

  1. 利用規約1.3.1(利用者が掲載等を行ったデータの利用)にかかわらず、他の利用者(ブロガー)が管理するブログ内に記載したコメントの著作権は、当該ブログを管理する利用者(以下「ブログ管理者」といいます。)に帰属するものとします。
  2. ブログ管理者が管理するブログにコメントを投稿した利用者(以下「投稿者」といいます。)は、当該コメントを投稿した時点で、当該コメントに関する一切の著作権(著作権法第27条および第28条に規定される権利も含みます。)が、ブログ管理者に譲渡されることを承諾するものとします。
  3. 投稿者は、前二項により譲渡されたコメントのブログ管理者による利用につき、著作者人格権を行使しないものとします。

つまり「ライブドアブログにコメントすると、コメントの著作権はブログ主に」ということになります。さらに、明確にはわかりませんが「利用規約1.3.1」と合わせて考えると、そのコメントをLINE株式会社が自由に利用できることになるようです。

「ライブドアブログにコメントすると、コメントの著作権はブログ主に」は有効か

ブログ主が、ブログ開設(その前のlivedoorユーザー登録)時に「利用規約」に同意しているなら、その内容に問題があるとは言え、利用規約1.3.1はしかたないかもしれません。

「ガイドライン」は、ブログ開設時に特に注意は喚起されませんが、他の項目に紛れて目立たないとは言えフッタなどにリンクがあるし、百歩譲って、ライブドアブログのブログ主はこれを承知していたとしましょう。

ところが、ライブドアブログ(LINE株式会社)とは一切何の合意も交わしておらず、通常の注意力をもってしても「ガイドライン」を目にする機会を与えられない[2] コメント投稿者が、ブログの記事を読んでそのコメント欄に書き込んだ途端、「一切の著作権が、ブログ管理者に譲渡されることを承諾するものとします」というのは、たいへん無理があるのではないでしょうか。

たとえば、コメント投稿者が後になって同じ内容を自分のブログに書いたら、ライブドアブログのブログ主に著作権侵害で訴えられる、という事態もあり得ます。

おまけ

言うまでもありませんが、当ブログ「半月記」へのコメントの著作権は、原則としてそのコメントを書いた人にあります。

  1. 当ブログのある記事が丸ごと転載されているのをたまたま発見し、その転載されているのがライブドアブログ(livedoor Blog)でした。この件についてはまた別に書こうと思っています。
  2. いくつかのライブドアブログで開設されているブログを見ても、コメント欄のまわりにこの点についての注意書きや「ガイドライン」へのリンクがあるものはありませんでした。