12月 28, 2022

引用投稿で通知が飛ぶべきかどうか問題

Twitterでは、引用RTをすると通知が飛ぶようになっています。昔は飛ばなかったのですよ。

そしてマストドンでは制作者のオイゲン氏が引用BTは晒しなどに使われ良くないとして実装していません。

しかし、過去のTwitterや現在のマストドンでは、投稿にURLを付けることで、間接的に言及は可能です。これは結局晒しを防ぐことにはなっておらず、本当に辞めさせたいなら存在する投稿URLが投稿できないぐらいの制限が必要では?と思ったりします。

引用投稿での通知の必要・不必要は、様々なパターンがあると考えられます。

a. 引用投稿で通知が飛んで行って欲しい人
  1. システムであり:そのまま引用BTすればいい
  2. システムでなし:BTしてから言及すればいい(下記参照の問題からするとリプライしてそれをBT?しかし新たにお気持ちをリプライされても困る問題が)

b. 引用投稿で通知が飛んで来て欲しい人

  1. システムであり:そのまま引用BTしてもらえばいい
  2. システムでなし:BTしてもらってから言及してもらえば良い(参照が大変)

c. 引用投稿で通知が飛んで行って欲しくない人

  1. システムであり:回避方法がない(h抜き?)
  2. システムでなし:そのまま投稿内にURLを含む

d. 引用投稿で通知が飛んで来て欲しくない人

  1. システムであり:回避方法がない(システムでオフにできる必要がある)
  2. システムでなし:何もしなくていい 

このパターン内にも送り手と受け手に合わせて、aとb、aとd、cとb、cとdの組み合わせがあります。

 

この先、まとまらないので、思いついたことを列挙します。

  • aで通知が飛んで欲しい人は、リプライではダメなのか? 
  • bは言及されているなら言及されていることを知りたい
    • 間違った言及をされていたら正したい
      • 通知がなければ間違った言及を正す機会が無くなる
  • 通知を受けたいbと受けたくないdは、場合に寄るのではないか?
    • cの通知を飛ばしたくないと考えている人は、ひっそりと言及したいのだろう
      • そんな内容の通知を受け取って幸せになるかどうか
  • cの通知が飛んで欲しくないのは、そもそも言及元に物を申したいわけではない、言及元に対するお気持ち表明でしかない
    • 言及元からツッコミは不要 
  • BT言及は言及元が参照しにくいのでダメという説
    • 同上
  • システムで通知を飛ばしつつ、通知を飛ばしたくない人はh抜きをするのがベスト?
  • h抜きではリンクを参照するのが面倒
  • システム側で、送るか送らないか、どうかを選べる方がいいのでは
  • 受け手側で通知を切れたとして、切る勇気はあるか?

どのパターンの人間に寄り添うかで、仕様が変わってくるので、この問題、正解がないような気がしています。


12月 04, 2022

今回の波はどうなるか(Fediverse (2) Advent Calendar 2022)

Fediverse (2) Advent Calendar 2022の4日目です。

わたしはnotestockという、分散SNSのログ管理をするサービスを運営していますが、11月頃からの大量移住を受けて、かなり宣伝してもらえたので、あまり書くことがないんですよね。重ねて言っておくことは、グループ登録しといてくださいね、ぐらいです。

グループ登録の説明はこちら

 

しかし、今回の大量移住はどうですかね。

今までにも大量移住は何度かありました。

だいたいがTwitterで二次元絵を発表している人達が、厳しすぎるBAN基準に耐えかねて、みたいな感じでした。

分散SNSの特徴として、拡散されにくいというものがあります。SNSに参加している人間が「この投稿を他の人にも知って欲しい」と思って共有しない限り、システム的に多くの人に見てもらうような仕組みが不足しています。

そのため「多くの人に見てもらって承認欲求を満たしたい」という目的でSNSを使っていると、分散SNSではさみしくて死んでしまうかもしれません。

過去の大量移住では、多くの人が寂しさに耐えられずTwitterへ帰って行ってしまいました。

分散SNSに古くからいる人たちは、「今回もどうせみんな帰っちゃうでしょ」と大量移住が起きる度に言ってきました。


2022年11月からの大量移住では、ちょっといつもと雰囲気が違いますね。

二次元絵を描いている日本人という範囲だったのが、テクノロジー系でもなく、アーティスト系でもなく、何気ない投稿をしていた人達が多いです。

それと、海外での動きが大きいですね。バンバンと公式サーバが作られ、「送信元ドメインによって投稿者の身元を保証する」という望ましい仕組みがきちんと実現されてきています。

いわゆるオタクの人達が多かった世界に新しい風が吹き込んできた感じがあります。

 

ただまあ、Twitterの喧噪に疲れて分散SNSに流れ着いたような人達からすると、少ししんどいところがあるかもしれません。

拡散されにくい仕組みと相まって、上手く棲み分けができるといいなと思って眺めています。


あと、SNSの運営には結構お金が掛かるというところも広まると良いですね。

どうしてTwitterがあんなにも広告が多いのか、タイムラインをごちゃごちゃさせて滞在時間を増やしてたくさんの広告を見せないといけないのか。

分散SNSを運営されているサーバによっては運営費が公開されているところもあります。「自分たちの考えに合わせてSNSを運営する」ということに、どれだけの負担が掛かるのか。それに気が付いて、ウェブサービスとその運営費をどうやって集めていくのか、どうしてそのサービスが無料で使えているのか。そういうあたりに少しでも意識が向くようになると、今後も上手くこの世界が継続していけるんじゃないのかなと思っています。


12月 03, 2022

Engage Kiss(クソじゃないアニメ Advent Calendar 2022)

クソじゃないアニメ Advent Calendar 2022の3日目です。

わたしが紹介するのは、Engage Kissです。

あらすじ
太平洋に浮かぶメガフロート型の独立都市「ベイロンシティ」。そこで民間軍事会社をしている緒方シュウという青年が主人公です。
彼は過去の事故により家族を失っていて、一人で暮らしています。そこにかいがいしく通い妻をしているキサラという女子学生。
電気やガスも止められているようなその日暮らしをしているシュウに、ご飯を作ってあげたり献身的な世話をするキサラなのですが、なんだかちょっと様子が怪しくて・・・。

○○脚本の誰それと△△キャラクターデザインの誰それが強力タッグ!みたいな売り方をされているのですが、個人的にはできあがった作品で判断するタイプなので、気にしていませんでした。昨今のコンテンツ充実度と競争からすると、まあそういうところで目を引いてもらうしかないのかなというのも理解はできます。

公式サイトのイントロダクションやイメージ絵で、悪魔が出てきてドンパチしたり斬り合ったりするぜ!って感じの流れなので、メインがバトルなんでしょうが、個人的にはキサラの性格にやられました。
この子良いよ!
包容力がありすぎる。お母さんか!
この作品では、シュウの昔の彼女、夕桐アヤノという女も出てきます。
アヤノは全然シュウとの未練が切れていなくて、仕事柄もシュウと関わりが続いているのですが、それを良しとしないキサラのヤキモチ焼き具合がかわいい。
シュウもはっきりと言ってやったら良いのに、なんだかんだアヤノを甘やかし、キサラにもペコペコしつつ、それを許してしまうキサラ。

あ、これ、かなりダメンズだ!

というシュウの性格が見えてきます。
キサラはシュウに騙されているのではないか。アヤノもなんだかんだ吹っ切れていないし。
と、かなりシュウに対して評価が厳しくなってきたところで、なぜこんなダメなやつなのかという理由が少しずつ見えてきて、個人的には評価が180度回転したり、もう一回したり、さらにしたりするのですが・・・。

とにかくね、キサラがかわいいんですよ。
語りすぎてもネタバレになっちゃうので、かわいさは作品を見てもらうしかないのですが、4話ぐらいまで見てもらうとキサラの良さが伝わるんじゃないかと。
製作に誰が関わったとか気にはしないのですが、キサラのかわいさを感じると「冴えない彼女の育てかた」を書いた丸戸史明氏が構成・脚本ということで、主人公に対する献身的な女子、加藤恵と重なるところがあります。

献身的な女の子、甘えたくなるし、ちょっとその貢献に返したくなるし、なのでシュウのことも応援したくなるし、アヤノの気持ちも理解できるしで、出てくる人間みんなが「そうなってしまうよな」という納得の行動を取るので、見ていて違和感を覚えにくかったです。
いくら多様性の世界と言えども、理解できない人間というのを見てしまうと、やはり拒否反応というか「こいつさえいなければ」みたいなことを考えてしまうと、なぜこの人間が作品に必要だったのか、なぜこの人間はこんな性格になってしまったのかみたいなところが描かれるまで、ずっとモヤモヤした気持ちになってしまったりして、純粋に作品を楽しめなくなってしまうんですよね。

なので、純粋にキサラの愛情を感じ取れる、良い作品でした。
時にはその愛情がすごい重いんだけど、その重さがかわいさで軽減されていて、ちょうど良い感じでした。

12月 02, 2022

無の癒やし(癒やされたい Advent Calendar 2022)

癒やされたい Advent Calendar 2022の2日目です。

癒やされる・・・癒やし・・・、癒やしってなんでしょうね。
調べてみました。
「癒やされる(いやされる)」の意味 Weblio辞書

それとの関わりを通じて、辛い思いなどが和らぎ、穏やかな気分になること。ストレスが軽減されること。(実用日本語表現辞典)

いかがでしたか?



・・・と、こんなところで終わりませんよ。

辛い思いなどが和らぎ、穏やかな気分になること

とありますね。
「落ち着く~」みたいな感じです。
そして

それとの関わりを通じて

「それ」。何かをすることで、「落ち着く~」になるわけです。

ということで、わたしが最近落ち着くアプリを紹介します。
2048 - Google Play のアプリ
です。



一時期、わたしのHTLで流行っていたのですが、もう誰もやっていません。
数字が並んだパネルをスライドさせ、同じ数字同士をぶつけると足し算され、どんどん足して2048を作ろうというアプリです。

プレイしてみると分かりますが、意外と難しい。
同じ数字同士をぶつけられず、すぐに盤面が邪魔な数字で埋まってしまいます。
全然穏やかじゃない。
ストレスが軽減されるどころか、ストレスが溜まってしまいます。

なんでこんなものを紹介しているんだ!
癒やしを紹介するんだろ?!

そうです。癒やしは、このすぐ側にあるのです。
アプリを開始するときに、盤面の大きさを選択することができます。


この8×8サイズが癒やしなのです!

8×8サイズの何が良いかというと

  • スライドさせ放題
  • いくらでもぶつけられる
  • 失敗してもなんとかなる
  • どんどんデカい数字になる(男の子ってこういうの好きでしょ?)

特に3番目。失敗してもなんとかなる。8×8サイズは、盤面が広いです。
このアプリはスライドさせる度に新しい数字が出てきますが、余裕の収容能力を持っています。
少々ぶつけられなくても、余った数字が盤面を埋め尽くす前に、否応なしに同じ数字がぶつかって足し算されていきます。
その結果、ちょっとスライドさせる方向を間違えたところで、なんとでもリカバーできるのです。
失敗しても安心。
その結果、どんどん数字が大きくなっていきます。

今わたしがプレイしているのがこれですが、2048どころか131072なんて数字になっています。
本当に終わりません。
上で紹介した8×8パネルでも、もう読めませんが1073741824なんて数字も見えます。

終わらないの?作業ゲー?いやゲームじゃないのでは?

そう、ゲームではありません。癒やしアプリです!

マイクラでひたすら地面を掘り進むとか、巨大なプチプチシートを永遠と潰しているとか、ああいう感じです。
失敗しても余裕で受け止めてくれる盤面。
それを見せつけてくれる大きい数字。

癒やされますよ。

12月 01, 2022

開通前の道路が好き(運輸・地理関係 Advent Calendar 2022)

運輸・地理関係 Advent Calendar 2022の1日目です。

交通機関・地理・おでかけあたりのネタで、なんでも良いと言うことだったので、その辺に関する好き話を少し。

タイトルにも出ていますが、わたし、開通前の道路が好きなんですよ。
それも、特に衛星写真で見るのが大好物です。

これだけではよく分からないと思うので、順番に出していきましょう。

スクリーンショット

大阪府の北部、茨木市の山奥です。
このあたりは、神戸と名古屋を結ぶ名神高速道路を補う目的で新しく作られた、新名神高速道路が通っています。
2017年末に開通したのですが、高速出入り口のそばの山を切り開いた中に、物流センターを建てて、京阪神の物流拠点にしようという感じみたいです。
高速道路は開通したものの、街作りの方が追いついておらず、衛星写真を拡大してみるとまだ道路に白線が引かれていなかったり、土のままだったりします。

このあたりは、南東部分に安威川(あいがわ)ダムも建設中で、高速道路が開通する前から谷底を縫うように走っていた府道46号線の付け替えをしつつ、高速道路へのアクセス道路にする工事が行われていたりしました。

このように、工事の具合を眺めることで街作りの方向性が見えてきたりします。
次のものを見てみましょう。

スクリーンショット全体 スクリーンショット大阪側スクリーンショット奈良側

大阪と奈良の間は、いくつかの国道で結ばれているのですが、その中でも一番北側に位置する国道163号線のバイパス工事現場です。
このあたりは、元から対面通行の国道163号線がありました。写真にある太い道路に沿ってクネクネとしている道です。
昔ながらの曲がりくねった危険な峠道を、4車線の高規格道路にしようということで、新しく建設されています。
大阪側はかなり工事が終わっています。写真にある川が流れているあたりで工事が終わっています。
そう、この川を境に大阪府と奈良県が分かれています。
奈良県、全然工事進んでないじゃん!
地図を東(右)に進めると、300mほど工事がされている区間があったりしますが、ここに繋がるのは果たしていつになることやら。

こんな感じで、地域によって道路に対する温度感みたいなものが感じ取れたりします。

次はスクリーンショットを出してみましょうか。次の写真にも、工事中の高速道路が映っています。どこか分かりますか?

見つけ方のポイントは、GoogleMapsの高速道路を表す黄色い線が、途中で不自然な終わり方をしている場所です。

答えは↓

操作しやすいGoogle Mapsも貼っておきましょう。

スクリーンショット

新名神高速道路の滋賀と京都を結ぶあたりです。
最初に挙げた土の道路はまだ道路の形をしていましたが、このあたりはとりあえず木を伐採しましたという感じです。場所によっては伐採もされていなかったりしますが、全く手つかずの部分はトンネルになる可能性が高いです。
こういう画像を見ると「地図に残る仕事」って、壮大ですごいなという感じしませんか?

この「山の中を伐採して進む道」という点では、東名阪自動車道の工事現場もなかなか見物でした。
東名阪自動車道は田園部分を貫いていく箇所があるのですが、用地買収が終わって農家の持ち物ではなくなった田んぼという状態が存在しました。
農家が管理する田んぼと、農家の持ち物ではない田んぼには、稲が植えられているかどうかという違いが現れます。
道路を作る人は稲を植えないですし、自分の持ち物じゃなくなった田んぼにも稲は植えないですもんね。
その場所が今どうなっているかというと・・・。

スクリーンショット

はい。もう完成しています!その様子は見られません。
Googleストリートビューは、古い年代の写真が見られたりしますが、今のところGoogle Mapsの衛星写真は新しいものだけなんです。
国土地理院が公開している年代別航空写真もありますが、撮影間隔が結構長いようで、場所によっては肝心の部分が写っていなかったりします。
今回の場所は、なんとか国土地理院の写真にも収録されていました。


リンク:https://maps.gsi.go.jp/#17/35.029359/136.515625/&base=ort&ls=ort&disp=1&vs=c1g1j0h0k0l0u0t0z0r0s0m0f1

どうですか、このコントラスト!うっとり来ますよね。
土地の境界線らしい縁取りがないところもあるのに、稲の生え方で境界線が見えてしまう。
人の営みに食い込んでくる道路という景色が思い浮かびます。

わたしが関西に住んでいるので、関西方面の工事現場をいくつか挙げてみましたが、日本全国で道路の建設が行われています。
各自治体の道路課や施設課あたりや、高速道路ならNEXCOのサイトに掲載されていたりします。

新しい道路ができると暮らしが便利になり、一瞬で通り過ぎてしまいますが、この道路ができる前はここはどんなところだったのか、なんてことに少し思いを寄せてみると、そこに住んでいた人・自然にありがたみを感じるかもしれません。


9月 20, 2022

pawoo.netが繋がらなくなった件のまとめ

何があったのか

9/17頃からpawoo.netに繋がらなくなる人が現れた。

9/19頃から運営者のラッセルが対応を行う

9/20から再び繋がるようになった。(完全に回復するには2日程度掛かると思われる)

 

何が起きていたのか

9/17にpawoo.netのネームサーバが、

  • ns01.idcfcloud.com
  • ns02.idcfcloud.com
  • ns03.idcfcloud.com 

から

  • ns1.abuse-value-domain.com
  • ns2.abuse-value-domain.com

に変更される。

 

abuse-value-domain.comはそれぞれ

ns1.abuse-value-domain.com 123.123.123.1

ns2.abuse-value-domain.com 123.123.123.2 

に設定されていた。

 

そのため、pawoo.netのIPアドレス問い合わせが、123.123.123.1などに転送される。

 

IPアドレス 123.123.123.1 は中国聯合通信(チャイナ・ユニコム)が所有している。

inetnum: 123.112.0.0 - 123.127.255.255 netname: UNICOM-BJ descr: China Unicom Beijing province network descr: China Unicom country: CN

このIPアドレスにIPアドレスの問い合わせを行うと、中国の検閲システム(いわゆるグレート・ファイアウォール)でブロックされているドメインだった場合に、著名なサービスのIPアドレスがランダムで返される。

そうして、pawoo.net を開こうとするとfacebookなどのIPアドレスが返され、開こうとしているアドレスと証明書のアドレスが一致しないのでエラーとなっていた。

(ランダムに返されるIPアドレスが、偶然pawooのものだった場合は、ページが表示されていた?) 

(ブロックされていないと思われるドメイン(osa-p.netなど) では、応答が無かった)


疑問点

  • abuse-value-domain.com が割り当てられていたIPアドレスは想定されていた運用だったのか?
  • 運用されているコンテンツに問題があったとして、ネームサーバを変更する操作は、一般的に行われる運用なのか?

訂正

「123.123.123.1でネームサーバが運用されていた」と記述していたが、検閲システムそのものの動作か不明なため、単に「IPアドレスの問い合わせを行うと」に変更。
 

7月 24, 2022

企業・有名人の分散SNSの始め方

これから書く内容は、個人的な考察です。実際はまだまだ発展途上なため、もっと別のアプローチが出てくるかもしれません。

新しいSNSとして「マストドン」という言葉を聞くようになってきました。
新しいと言っても、2016年から始まって(日本では2017年から流行)いますので、2022年でもう5年ちょっとになります。
雰囲気としては、気の合う仲間と日常やネタや時事をワイワイやっているという感じですが、フォローしていない人でも共有で回ってきて、だいたい活動している人のアイコンは何度か見たことがあるという、Twitterが大爆発的に流行るちょっと前の「日本語をしゃべってる人はだいたい見たことある」というあんな感じの状況です。

さて分散SNSと比べられるTwitterも、ネットをそれなりに使っている人なら1アカウントは持っているというような状況になり、様々な企業や有名人、国までもが情報発信ツールとして使っている状況です。
しかしTwitterも色々な問題があり、飛び出す人たちがいます。ここでは、分散SNSとはなんぞやという詳しい話や、中央集権がどうとかいう話はしません。そのあたりの記事は2017年頃にたくさん出ていたのでそちらを参照してください。
ある程度有名な人たちが、分散SNSで活動して行くに当たって、どうするのが良いかというのを考えてみたいと思います。

まずはアカウントを作る。
情報発信をするにはアカウントを作る必要があります。これは分散SNSでも違いはありません。
しかし、ただアカウントを作ると言っても、いくつかのパターンが考えられます。ここが分散SNSの使い心地や、企業・有名人ブランド力の強化に繋がってくると考えています。

  1. 既存のサーバにアカウントを作る
  2. 一番簡単なパターンです。分散SNSが出てきた当初は、サーバを用意するには技術的な知識が必要となりハードルが高かったという問題がありました。
    そのため数あるサーバの中から、どれかを選んで、そのサーバにアカウントを作るというものです。
    企業や、ITジャーナリストや、作家さんなんかでこのパターンが見られます。

    メリットとしては
    • 簡単
    • 他の人に見つけてもらいやすい
    デメリットとしては
    • そのアカウントが本物かどうか見分けが付きにくい
    • 自分の意思とは関係なくサーバ運営が終了してしまう可能性がある

    Twitterと違って、現在見られる分散SNS向けサーバシステム「マストドン」「Misskey」「Pleroma」などでは、バッジ機能はありません。そのため、作られたアカウントが本当にあの企業のものなの?あの有名人なの?という区別がつきません。
    対処方法としては、Twitterや、サイトから「このアカウントは本物ですよ」とリンクを張っておくことぐらいです。
    また、サーバ運営者には企業や個人がありますが、圧倒的に個人が多いです。事業継続性まで考慮されているサーバは一握りしかないと考えていいでしょう。サーバの運営が終了するとき、必然的に他のサーバへ移動する必要がでてきます。もちろん他のサーバへ移動しても同じように活動は継続できますが、終了したサーバにある過去の投稿などは消えてしまうでしょう。(拙作notestockを使えば保存は可能ですが。)


    例)
    @hakone_garasunomori@mstdn.jp箱根ガラスの森美術館
    @miraicorp@matitodon.com未来情報産業株式会社
    @nelsoncoffeeroaster@pawoo.netNelson Coffee Roaster
    @comicLO_YLNT@pawoo.net茜新社刊「COMIC LO」公式アカウント
    @careltokyo@mstdn.jp完全個室メンズエステサロン『ケアル麻布十番&白金高輪店』
    @mikamiyoh@mstdn.jpITジャーナリスト三上洋氏
    そのほか、pawooに多数の作家さん

  3. 組織としてサーバを立てて、その中にアカウントを作る
  4. 確実にブランド力が示せるパターンです。例えば、「example株式会社」が「example.co.jp」のドメインでウェブサイトを公開していたりするとき、「sns.example.co.jp」みたいなドメインで分散SNSサーバを用意するのです。
    ドメインというのは持ち物ですので、サイトのドメインに組み込んでしまう(サブドメインと言います)と、確実にその組織のサーバであると知らしめることができます。
    またこの場合、サーバ内に複数のアカウントを作って別々の運用を行うこともやりやすいです。

    @info@sns.example.co.jp組織としての総合的なお知らせ
    @pr@sns.example.co.jp広報担当者のアカウント
    @support@sns.example.co.jpサポート窓口のアカウント
    @sugoiseihin@sns.example.co.jp「(仮称)すごい製品」のプロモーションアカウント
    @top@sns.example.co.jp社長のアカウント

    みたいなことができます。

    タレント事務所なら、所属タレント毎にアカウントを作るということもできるでしょう。ただし、そのタレントが移籍したときに、過去の資産を引き継げないという問題があるので、このあたりは考慮する必要があります。そのうち、投稿内容まで含めて引っ越しできる分散SNSが出てくるかもしれません。(移行先のアカウントを表示できる機能があったりしますが、前の所属会社での活動や宣伝を引き継ぐ必要あるか?という問題もあるでしょうし、お互い納得いくように取り決めてください。)
    またグループ企業や仲の良い企業連合でサーバをひとまとめにすると、コストが圧縮できるかもしれません。(経理的なところは分からないので、上手いことしてください。)

    メリットとしては
    • 本物である証明が容易
    • ブランドを示しやすい
    デメリットとしては
    • 見つけてもらうのが難しい

    見つけてもらうのが難しいというのは何かというと、分散SNS向けサーバシステムの傾向として「フォローしてくれている人がいるサーバに向けて投稿を送信する」という動作が一般的なためです。
    多くの分散SNSでは「連合タイムライン」と呼ばれる表示がありますが、ここにはサーバが受信した投稿を含めて表示されています。各サーバの連合タイムラインに表示されていないと、そのサーバの会員に認識されていないと考えてください。(ベテランの方へ、非公開とか未収載のツッコミは飲み込んでください、ややこしくなるので。)
    できたばかりの組織サーバで投稿しても、他のサーバからは全く投稿が見えないかと思います。他のサーバの人からフォローされていませんしね。
    そこで必要になるのは、他のサーバに認識してもらうための行動です。

    簡単な方法としては「他のサーバの人をフォローする」です。
    フォローされると相手に通知が届きます。それによって、相手にアカウントやサーバの存在に気づいてもらえるようになります。
    ここで無差別フォローなどをすると嫌われる傾向があります。いいねを付けたり、返信(リプライ)で絡んでいくのも良いでしょうね。このあたりは数多の「企業Twitterアカウント運用指南書」みたいなものに書かれているのと同じかと思います。
    検索サイト(tootsearch)などで、興味ありそうな人を絞り込んでアプローチを掛けた方が良いかもしれません。
    アカウントを作っただけでフォローしても、フォロー返しは無いかもしれません。ある程度そのアカウントがどういう感じになるのか、いくつか先に投稿しておくと良いでしょう。

    やってしまいがちな間違いとしては「example株式会社のSNSを作りました!みんな登録してくださいね」と一般開放してしまうことです。
    必ずしも間違いとは言えないのですが、たいていの場合運用コストが膨れ上がってしまい、どうにもならなくなってしまうと考えられます。
    その会社の製品について話をして欲しかったのかもしれませんが、関係の無い話が投稿されたり、企業のドメインから公開しておくと問題が出る投稿をされたり、会員同士のもめ事が起きたり、それらの投稿内容の管理にコストが掛かります。
    「みんなが書き込める、会社のサポート掲示板」という感覚で解放すると、きっとそれ以上のコストが掛かると考えた方がよいです。
    一般の人たちは他のサーバにアカウントを作ってもらって、情報発信側のドメインは関係者からの発信のみに絞るという形です。

    もう一つ、これは分散SNSだけに限った話ではありませんが、やってしまいがちなものとして「example株式会社(サイト example.co.jp)のSNSを作りました。 example-sns.comです!」これは、似た名前の偽サイトかもしれませんし、「ドメイン放棄 危険」あたりで検索してもらえばいろいろ出てきますが、分散SNSの運用方針を変えたときに困ったりすると思うので避けた方がいいです。

    例)
    unnerv.jp特務機関NERV(Twitterで災害情報などを流しているゲヒルン株式会社)
    social.farend.co.jpファーエンドテクノロジー株式会社
    FLOSS.social自由・無料・オープンソースソフトウェアに関するアカウントのサーバ
    botsin.spaceボット運営に特化したサーバ

    ここまで組織という単位で話を進めていましたが、一人の個人事業だけど発信元として明確にしたいんだけど・・・、と感じる有名人もおられるかもしれません。
    大丈夫です。サーバを検索できるサービス、fediverse searchで「お一人様」をキーワードに検索してみてください。
    世の中には、こんなにも個人でサーバを運営している人がいるのです。

今の個人的お勧めは、断然に2番です。
サーバを用意するのが難しいという話がありましたが、現在はサーバを貸してくれるサービス(hostdonMasto.hostなど)があります。

分散SNS原理主義(打倒中央集権!とか)に基づくと、そういうサービスも使わずに、サーバソフトウェアも自前で維持するべきとなるのですが、少なくとも多くの企業や有名人で法律に乗っ取った範囲で投稿するのであれば、サーバ貸しサービスで問題ないはずです。
もちろん、これらのサービスが無くなってしまう可能性もあるので、そのあたりの判断は必要です。過去に一社撤退したサーバ貸しサービス会社があります。

それなら1番の既存サーバでアカウント運営をしている人たちもいるし、いいんじゃないの?という判断もあるでしょう。
多くの場合、一般にも開放しているサーバを運営している人は、手弁当で運営している酔狂な人たちです。寄付などを受け付けているところもあるようですので、サーバ維持のためにも寄付してみることをお勧めします。(しかし個人へ寄付したときの経理的な部分や稟議的な部分で、多分ややこしいですよね。)


これを書こうと思ったきっかけなど。
先日、ガーシー2というサーバが公開され、参加者が大量に登録され運営コストが大変だという話題がありました。
中心となる人物のいろいろな情報発信アカウントが無効にされてしまったために、新たな情報発信アカウントとしての運用を目指したのだと思いますが、一般の登録を受け付け同じような思想を持つ人たちの集まりとなりました。
分散SNSでは、同じ話題に詳しい人たち(Twitterなんかでもクラスタと呼ばれる)で集まると盛り上がりやすいという傾向があります。絵描きが集まっているサーバや、特定のゲームプレイヤーが集まっているサーバや、バイク好きが集まっているサーバや、酒好きが集まっているサーバなど。ですので、ガーシー2サーバが一般登録者を受け入れたということ自体は、必ずしも間違いでは無いという部分に当たるかと思います。ただし「サイバーカスケード」や「エコーチェンバー現象」などに気をつける必要があります。
それらの問題を分散サーバ同士で繋がることによって、内部では濃い話題をしつつも、外部から「それはちょっとおかしいんじゃないの?」とツッコミを入れてもらえる環境というのは、ある程度大事なのではないかとも考えています。
しかしそのツッコミをきっかけに、先に紹介したように、一般の登録参加者が余計な発言を生み出す可能性を考慮すると、有名人のアカウントを用意するサーバは、その有名人の情報発信のみに徹し、信奉者と非信奉者同士のレスバトルは外部でやってもらうという、責任を持ちたくない部分で責任を持たないという運用の形もあるのではないかと思っています。

過去に国会議員や、有名なコスプレイヤーが既存の一般公開サーバに登録されたことがありました。著名な人だけあってアンチな人もいたようで、色々と嫌な目を受けられたようで去って行かれてしまいました。こういうとき、クラスタ同士で集まったサーバでわいわいとしていれば、ある程度気も紛れたのではないかとか、また自分たちで管理しているサーバなら、あまりにもひどい言動に対しては自分たちでサーバから閉め出す、連合サーバ間でも無視扱いにするなどの管理をすることが可能でした。
なので「有名人が情報発信専用サーバを用意する」または「クラスタで集まれるようにサーバを公開する」という選択は、ブランド(クラスタ?)の運営方針としてどちらも考えられるため、サーバを立てる前にこの部分を慎重に考える必要があるかと思います。
個人的には、せっかく分散していて嫌いなもの同士が同じサーバに同居する必要が無い仕組みなんだから、分かれて嫌いなら無視しておけば良いのに、わざわざちょっかいを掛けに行く方がどうかしているとは思うのですが。

そんな感じで、新しいSNSと言えども個人が大きな発言力を手に入れたSNSという仕組みでは、どこへ行ってもいざこざは発生してしまうかもしれません。ですが、せっかく新しい分散SNSという仕組みを手に入れたのならば、それを活用してあたらしい情報伝達方法も試せるのではないか、という提案でした。


5月 14, 2022

データベースサーバのファイルシステムをzfsからbtrfsに切り替えた

1月末から少しずつ作業をしていて、3月に完全切り替えをして、多分もう大丈夫そうなので書き記しておく。 

2014年11月頃から、2TBのSATA HDD 5台をmdadmによる管理でRAID5化していたのですが、障害が出ることが多く、安定性で評判を聞いていたzfs(ZFS on Linux)によるRAID5に切り替えました。

2016年9月頃から速度に不満が出てきて、1ヶ月毎にSSDに入れ替え、オールSSD化されました。

使っていたSSDは、CrucialのCT2050MX300SSD1。これは、HDDから差し替える際に、2TB・2048GBのディスク領域をそのまま移行できるということで選択されました。

この機種を選択した他の理由として、S.M.A.R.T.による監視でドライブの寿命を予測できたというところです。HDDでも、S.M.A.R.T.による監視はできましたが、どうしても駆動部品があるということで、突然死の心配がありました。SSDは駆動部分がないため安定しており、さらにSSDに使われているメモリの書き換え回数に限界があるということで、ある程度寿命に予測が付くのでしょう。

データベースサーバでは、24時間365日、大量の書き込みを行っており、S.M.A.R.T.で取得できる「寿命値」は一定の間隔で下がってくるという様子でした。

S.M.A.R.T.記録グラフ。ここで50%以下にあるグラフがCT2050MX300SSD1。

しかしこの「寿命値」も調べてみると、あくまでも計算式によるもので、0になった瞬間に壊れるわけではないようです。0になった時点で予測されるメモリチップの書き換え回数を消費したということで、0以降はいつ壊れてもおかしくないという状態だそうです。逆に言うと、性能不足のチップがあった場合は0に達する前に壊れる可能性もあるわけです。

実質2017年から使われてきたSSDも2021年で5年間、残り寿命が30%を切りそろそろ不安を覚えるようになりました。

ドライブ寿命については2年ぐらい前から気にしており、HDDからSSDへ切り替えたときのように、また1台ずつ入れ替えていけば良いだろうと、交換するドライブを見繕ってみるとCT2050MX300SSD1は1台6万円ぐらいしていたのに、2TBのSSDが2万円ぐらいまで下がっていました。量産化効果ってすごいですね。しかし容量が2000GBのドライブばかり出てきます。2TiBと2TBの違いでしょうか。

構成サイズが小さくなるようなドライブ交換は、zfsでは対応していないようです。どうしても一度RAIDを解いて、再度組み直す必要があるようです。しかも容量が小さい方に合わせられてしまう。以前仕事で触ったことのあるSynologyのNASでは、Synology Hybrid RAIDという仕様があり、サイズの異なるドライブを組み合わせて無駄なく領域を使ったRAIDが組めるというものでした。こんな仕組みが有ればいいのにと考えていました。

2022年になって、そろそろ次のストレージ構成を真剣に考えなければということで、再び調査をしてみました。相変わらずzfsでは容量減少は対応しておらず、btrfsのRAID5は動作が怪しい。

しかしbtrfsでは異なるサイズのドライブを組み合わせて容量の無駄を極力抑えた状態でRAIDが組めるという情報を見つけました。RAID5のパリティ計算をするCPU負荷も気になっていたので、この際RAID5はやめて、RAID1あたりで構成してみるか?と検討してみました。

Hyper-Vで環境を作り、サイズの異なるディスクの組み合わせでテストしてみたところ、問題なく動作するようです。障害時の復旧手順なども一通りテストして感覚をつかみました。

ということで2000GBのドライブを購入。今回は、CrucialのCT2000MX500SSD1とWESTERN DIGITALのWD Red SA500 WDS200T1R0Aです。他のメーカーを混ぜてみたのは、最近はNVMeのドライブしか買っていなかったので、2TB SATA SSDの使い心地が分からず、Crucial以外の品質も見ておきたかったためです。

新しい2000GBのドライブ2台でbtrfsのRAID1を組み、そこへzfsのデータをコピー。運用してみて動作に問題ないことを確認した後、zfsのRAID5を解放し、従来の2050GBドライブを1台ずつ2台混ぜて4台のRAID1に変更しました。運用しながらRAID構成を変更できるので便利ですね。

しかし思ったより速度が出ず、space_cacheの設定をv1からv2に切り替えてみたりしたもののずっとディスクが足を引っ張るようになりました。1ヶ月ほど調べてみたものの原因がつかめず、最終的にRAID1からRAID10へ切り替え。btrfs的にどのようなドライブの分け方になっているのか分かりませんが、なんとか処理速度も回復しました。

今後は古いドライブから死んでいくはずなので、RAID10に組み込んでいない残りの2050GBのドライブを順次入れ替えつつ、最終的に全部が新しいドライブに入れ替わる予定です。

zfsを運用していた間は、数回だけドライブを認識しなくなることがありましたが、RAID5に組み込み直すとすぐに復旧できたので、信頼度はかなり高いです。ただしzfsはカーネルアップデートの度にビルドし直す必要があります。手元で運用していたときは、画面上ではアップデートが成功しているのに再起動するとzfs領域を認識できなくなるという状態に毎回なりました。一度モジュールを完全にアンインストールして、再度インストールする必要があったので、そこだけが面倒でしたね。

btrfsはカーネルでのサポートも期待できるので、さらに安定した運用ができそうです。


2月 21, 2022

notestock機能追加(これすき検索、Qiitadon特殊対応)

いつも応援ありがとうございます。
今回はnotestock( https://notestock.osa-p.net )に機能追加を行ったのでお知らせです。

  • notestockに新しい検索機能「これすきモード」が付きました
    一部界隈(わたしも含む)で、アナウンス(ブーストとかrenoteとか)した後「これすき」と投稿する習慣があるのですが、それだけを検索したいなと思って追加しました。
    作ったときはすごい欲しかったんだけど、完成したらそれほど使う機会無さそうで、暇なときに見返してニヤニヤする感じかなぁと思ったりもしつつ。どんどん「これすき」していきましょう。
    これすきって正規表現で言う「これら?(すごい|めっちゃ|死ぬほど|狂おしいほど)?すき」などの派生があるので「すき」だけで検索しています。misskeyサーバを表す「○まるすきー」とかも引っかかっちゃうけど。
    デフォルトを変更したい人が多そうなら、設定画面で変えられるようにします。

  • MastoOwn対応
    (この機能は2023年1月現在、停止中)
    またQiitadon終了前と言うことで、notestockおよびMastoOwn( https://hidao80.github.io/MastoOwn/ )に機能追加して反映してもらいました。
    Qiitadonのアカウントをnotestockに登録していただいている方は、notestock登録以前の投稿が掘り返し登録されていないかと思います。Qiitadonのバージョンアップを期待し続けていましたが、見通しがなくなったので、ちょっと強引な方法で取り込めるようにしました。
    Qiitadonの対象アカウントで、各自MastoOwnの操作していただく必要があります。MastoOwnのオプションにある「notestockへ送信」にチェックを付けてください。
    notestockへの反映は即時ではありません。設定画面に残り件数が表示されます。

  • fantia以外の寄付方式に対応
    fantiaで寄付するのはちょっと・・・という声を見かけたため、Liberapayとko-fiでも受け付けられるようにしました。
    応援ユーザーの表示は、現在Liberapayだけ追加されています。
    Liberapayとko-fiだと、寄付者を非公開にすることも可能です(たしか)
    寄付先については、 https://osa-p.net/#Donation を参照してください。

notestockの公開検索対象や各種検索サービスで、notestockが含まれている投稿をときどき確認していますので、何かあれば投稿しておいてもらえると、反応したりしなかったりします。
よろしくお願いします。

 

1月 31, 2022

Bluetoothイヤフォンの途切れを解消した

2021年の2月に、SONYのWF-SP800Nを買ったんですよ。 

ところが使っていると、どうも途切れやすい。プチプチと音が途切れる。場合によっては数秒間途切れて飛ばされたまま続きが再生されるという感じ。 

Bluetoothは2.4GHz帯のWi-Fiと干渉するということで、Wi-Fiアクセスポイントがパソコンのそばにあったので、場所を離したりしたのですが、効果が無い。(プリンタが2.4GHzしか対応していないので停波できない)

そもそも、それまで使っていたSONYのMDR-EX31BNでは途切れたことがないのです。

それまでのMDR-EX31BNはBluetoothのAptXコーデックで通信するようになっていたのですが、新しいWF-SP800NはSBCコーデックとAACコーデックにしか対応していない。 

しかもWindows10はAACに対応していないので、必然的にSBCが使われます。

どうやらこのあたりが原因か?と思ってかなりがっかりしていたのですが、 2021年5月ぐらいに、Windows10 21H2でAACに対応というニュースが流れてきました。

これは逆転か! と思ったのですが、待てど暮らせどAAC対応が更新に降ってこない。みんな気がついてないからニュースになっていないだけか? と思って、なんかWindowsの動作ログからBluetooth接続の詳細を調べてみたら、やはりSBCが選択されている。

SNSで「Win10のAACどうなったんだぁ~」とつぶやいていたら、「Win11対応になったらしい」という情報が。ぐぬぬ、最新版に上げさせる作戦か。わたしのマシンはWin11に対応していないらしく、更新されません。現状でなんとかするか、半導体不足の中マシンをすっくり買い換えるか。

・・・なんとかする方向で考えましょう。

 

そもそもSBCが最低限の接続方法としても、こんな途切れまくるものを製品として売るはずがないので、何らかの問題が環境にあるのでしょう。接続状況を見てみましょう。

この話をSNSですると「帯域足りないのでは?」という話が出てきました。

Microsoftのスマホ接続は、Android端末に届いた通知やSMSや着信をPC側で見られるというものです。多分常に通信しています。

マウスは専用のドングルもあるのですが、Bluetoothの方が電池の持ちが良い感じがします。あと専用ドングルを別マシンに刺して切り替えて使うというのが便利で、PCとはBluetoothで接続したい。

Proコントローラーはゲームをするときだけですが、コントローラーを使うと途切れがさらに大きくなるため、どうやら帯域が足りていないというのが問題なのかもしれません。

Bluetoothはバージョンによって通信速度が違います。それまで使っていた4.xから5.xに更新すると、Bluetooth Low Energy(BLE)の速度は上がるらしいのですが、今使っている機器がBLEで通信しているのか、従来のBluetoothなのか、よく分かりません。まあ最新版にしましょう、ということで5.1対応とかいうドングルを買ってみたのですが、まったく改善されませんでした。

こうなってくると、もうPCのBluetoothを諦めるしかありません。

作業中に聞いているSpotifyをスマホから再生すればいいのですが、PCのメールやSlackなどに届く通知音はキャッチしたいのです。

つまりPCの音をスマホから再生すればいい。

なんかそんなソリューションはないのか~と探したら、ありました。

AudioRelay

PCで起動したサーバへ、スマホのクライアントアプリから接続するというものです。

早速試してみると、ディスプレイへの音声出力を取り込んでスマホに配信するようです。でもディスプレイからも音が出続けている・・・。

ディスプレイ側でボリュームを変えればいいのですが、ディスプレイから音を聞きたいときもあり、しかも音量設定がメニューの最深部にあり、毎回いじるのは苦痛。

PC側で音声出力先を選ぶことは簡単にできるので、もう一つ音声出力先を作って、AudioRelayにはそちらから音を拾ってくれたら解決しそうです。そんなソリューションは~(以下略)、ありました。

VB-CABLE

実際に音が出るわけではないオーディオインターフォースを作成します。

最終的に、以下のような構成になりました。

遅延は10msとのことで、ディスプレイから流したものと比較しても、ずれていることは分かりますが動画を再生しても気にならないレベルです。

真剣に探すと、解決方法はあるものですね。これで1年近く悩んでいたイヤフォン環境が解消しました。


P.S. そういえばBluetoothアダプタを複数刺すというのを試したことがなかったけど、どうなんですかね。

アイコン:icooon-mono