カラオケで純情エモーショナル歌うと歌詞表示がアレで笑う(6人分パートがあるけどメロディは全部同じなので実質無意味)
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
カラオケで純情エモーショナル歌うと歌詞表示がアレで笑う(6人分パートがあるけどメロディは全部同じなので実質無意味)
このアカウントは、notestockで公開設定になっていません。
@Yohei_Zuho リレーサーバに登録したインスタンスが相互に、
ローカルタイムラインのトゥートをメンバーのインスタンスの連合タイムラインにブロードキャストする。
お一人様や小規模なインスタンスに、他のインスタンスのローカルが混ざって流れてくるので賑やかになる。また、自インスタンスのローカルが他に流れるので、リモートでの交流が促進される。
複数のリレーサーバが同時に存在でき、同時に参加できるので、いろんなグループを作れたり、リレーのバックアップになったりする。
リレーが単一障害点（ソコが落ちたら全体が落ちる）にならない仕組みになっている。
オプション機能であり、必ずしもリレーを利用する必要はない。
masterに入ったばかりの実験的な実装。今のところ開発者or 一部のmaster追従勢の遊び。
リレーサーバはMastodon本体とは別の軽量な単独のWebサービス。
デフォルトのjoinmastodonリレー（海外サーバ多し）の他、私が立ててみたrelay.dtp-mstdn.jpがある。他は知らぬ。 #dtp
relay 、どうせ Mastodon 特有の機能でしょみたいな気持ちがあるので特に興味を持っていない(調べてないので知らんけど)(そもそも FTL というのが ActivityPub で規定される機能ではなさそう？(知らんけど))
このアカウントは、notestockで公開設定になっていません。
まぁ Mastodon リレーがデファクトスタンダードになって標準プロトコルになるならいいんじゃない？
このアカウントは、notestockで公開設定になっていません。
@unarist リレーされた投稿を受けとる側の一般サーバはどのような宛先として受けとるのかが気になっています (エンドポイントは ActivityPub 的にはサーバ全体で共通の inbox な気もしますが、宛先 IRI は誰宛なのかなと)
リレーの実質的なソースコードこれだけか https://source.joinmastodon.org/mastodon/pub-relay/blob/master/app/workers/process_worker.rb
それとも、このリレー鯖を特定のアカウントでフォローしないといけないのかな？
リレーサーバの実装の話。
現在のリレーサーバ実装（pub-relay）は、登録インスタンスのリスト（ドメインとinboxのアドレス）と、登録を拒否（ブロック）するドメインのリストだけをデータベースに持っています。
relay@リレーサーバ というアカウントが直接生えているので、各インスタンスはこれとやりとりしています。
登録インスタンスがrelayのinboxに投稿を投げてよこしたら、全登録インスタンスのinboxにそれを投げ直します（パススルー）。
relayへのフォローリクエストの体で、リレーに登録し、フォロー取り消しで削除。
sidekiqでProcessWorkerとDeliverWorkerが走っていて、ProcessWorkerがrelayに対するリクエストの処理、DeliverWorkerが各インスタンスへトゥートを配信する処理を行います。
sidekiqのキューはdefaultのみ、リトライは行いません。
登録インスタンス一覧と、ブロックの登録・削除を行う、シンプルなコマンドラインツールがついています。
実に美しく読みやすい。
※個人の感想です #dtp
このアカウントは、notestockで公開設定になっていません。
コンパイラの警告はもちろんコンパイラ依存なのであてにしたくない
(それはそれとして自分の開発では有効化てんこもりだけど)
(開発での有効化はいいとしてリリースするビルドスクリプトで警告をエラー扱いするのやめろ)
最新のコンパイラを使いがちな人間なので、システムアップデートで C++ の -Werror のせいでビルド失敗したこともあるし、授業で書いてるプロジェクトが Rust nightly で deny(warnings) のせいで (doc comment の仕様変更関連で警告が出て)コンパイル通らなくなったこともある
警告をエラーにする設定でリリース出すやつ、お前は未来に現れる全ての仕様準拠コンパイラの警告の実装を知っているのかと問い詰めたい
実装の問題でなくプロジェクト管理者の思想の問題だったりするので説得も面倒だしややこしい
-Wall -Wextra -pedantic とかにして警告も全部エラーだと思ったほうがいい気がする（そうしないと C 言語結構ヘンな実行時バグ踏み抜くので……）
クリティカルなやつはそうなんですが、割とどうでもいいやつで新しく警告追加されてエラーになるとブチギレ案件なので……
その点 rust では各 lint 項目について allow, warn, deny で選択できるのでとてもよい(そしてそのような素晴らしい環境で後方互換性も考えず deny(warning) する奴は反省しろ)
このアカウントは、notestockで公開設定になっていません。
もう今のマシンに chrome 入れてないからわからないけど、 chrome がメモリと CPU までも無限に食う現象がマジで辛かった(あと落ちる)
カラオケにオタクとしか行ったことがないのでオタクソングしか歌っていない
このアカウントは、notestockで公開設定になっていません。
