アカウントで管理できるイベントツールなんてあるのか。
event.baraweb.net/

この で将来的に、bot以外のアカウントも受け入れようかと考えはするものの、需要があるとは思えない。

で特定のドメインを止めたい場合は「モデレーション」。僕がよく迷うのでメモ。

は似て非なるもので、僕はMastodonの方が好きだな。

13ベータ2、まだTwitterやFacebookの動作が怪しいので、ますます への引きこもり度合いが高まりそう。

を組むと(おそらく でもそうだろう)、名前付けのセンスが問われる。
というのは、Google Cloud Platformはプロジェクト・VMインスタンス・ディスク・スナップショット・ストレージ(S3互換バケット)・SQLインスタンス・VPCネットワークの外部IPアドレスそれぞれに名前をつける必要があるからだ。
なお、VMインスタンス名はホスト名に、スナップショット名はスナップショットをもとに作られたディスクに名前が残る。
また、プロジェクト名は一度削除すると同じ名前のものを作れない。
そして、ストレージは文字通りのグローバルな名前空間にあるので世界的に一意である必要がある。
さらに、SQLインスタンスは一度削除すると同名のインスタンスを1週間ほど作ることができない制約がある。
名前付けのセンスが使い勝手を決めてしまう。
プログラミング的だなあと思う。

おひとり様サーバ構築経験を振り返ると、階段を昇っている感じがする。

1. VPS : 最初からMastodonが入っている状態のVMでMastodonサーバを起動できる
2. : 1台でSQLやストレージ含め完結したMastodonサーバを自分でつくる
3. : SQLとストレージ(S3バケット)を外出しにして、VM・ディスク・IPアドレスをそれぞれ別としたMastodonサーバを自分で構成する(イマココ
4. どこかのクラウド : 自動デプロイやオーケストレーション、場合によってはサーバレスアーキテクチャも駆使して、ある程度の人数が収容できるMastodonサーバを構成する(未経験)

難易度はもちろん1<2<3<4。

このサーバで が一通り使えるようになりました。

構築:
- のus-central1リージョンus-central1-aゾーン上に構築
- machine-typesはf1-micro・g1-small・n1-standard-1のいずれか cloud.google.com/compute/docs/
- `dd if=/dev/zero of=/swapfile bs=1M count=4096`でスワップファイル約4GBを作成
- - - 標準の永続ディスク 30 GB
- 互換バケット)使用
- 9.6で使用
- はVMインスタンス内
- ドメインは
- メールサーバは
- 有効

BlessedGeeks.Social

@h12oのおひとりさまMastodonです。@h12o以外のユーザはbot。Google Cloud VMで運用しています。