08:24:33

今後の参考のために、具体的に流れを書いておきます。

rel=meの認証チェックマークは、

0. 対象リンク先がこちらにrel=meリンクを張った状態で、

1. アカウントの更新を行った際に、

2. バックグラウンドで実行されます。

まず最初に、相手の状態がrel=meリンク付きになっているか確認します(添付参照)

この状態で、アカウントを更新します。プロフィールの編集で、保存ボタンを押してください。

rel=meのチェックは、バックグラウンドで行われます。保存ボタンを押すと同時に終わってしまうぐらいはやいこともあれば、少し待たされることもあります。

反映されていなかったら、少し待ってブラウザをリロードしてください。

なかなか反映されなかった場合は、アカウントの更新をもう一度試してみてください。

08:35:01

これ、どちらかのリンクは、どちらかの更新時点ではまだ未設定になるため、

アカウントの更新を合計3回やる必要がある、ということです。

1. fedibird.comでプロフ更新
2. みすほわでプロフ更新
3. fedibird.comでプロフ更新

という感じですね。

このへんが分かりづらいところです。

08:57:58
2024-12-10 08:56:57 Posting 画眩 ggagen@pawoo.net
This account is not set to public on notestock.
08:58:03
2024-12-10 08:57:06 Posting 画眩 ggagen@pawoo.net
This account is not set to public on notestock.
09:05:20

絵文字が増えた分、だいぶ検索も重くなってきたんじゃないかな……

09:41:27

ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY
ACTIVE_RECORD_ENCRYPTION_DETERMINISTIC_KEY
ACTIVE_RECORD_ENCRYPTION_KEY_DERIVATION_SALT

の3つを定義するようになるので、このキーを失わないようにしておくこと。

パフォーマンスの面からも、全部のフィールドを暗号化するつもりは全然ないので、その点ではあまり心配は要らないと思う。

アカウントの秘密鍵とか機密性の高いものが対象で、適用対象は限られるじゃないかな。

09:44:53

そんなに難しいコードにはならんし、railsの標準的な機能でやるわけだから、エクスポートコードをさくっと書こうw

09:47:20

いらない絵文字を管理できるようにしないとだねー

09:54:48

暗号フィールドを含むモデルを、同一構造の暗号フィールドじゃない版のモデルにコピーするコード書いて、railsで一回走らせればええんやないかな。そしたら、あとはPostgreSQLレベルで対応できるようになる。

あと、いま検討してる設計でも、暗号フィールドを含むフィールドを別モデルに切り出して小さくしようとしてる。

accountsから秘密鍵などだけ別テーブルに抜き出すとかね。

使わないときにデコードのコストを掛けたくないわけ。

09:58:29

class Account < ApplicationRecord
encrypts :private_key
end

Railsのコード的にはこれだけだしね。あとは透過的に処理されるので。

10:05:42

stautsesのdirect visibilityのtextだけ暗号化して保存しといて、使うタイミングでデコードするコードも書けるから、そういうのは一応やる可能性あるけど……実際のところどうかな……。

10:12:03

支給されるときはボーアリ(??)

10:14:32

真顔

11:26:44

mstdn.jpは制限厳しく掛かりすぎて使えないこと多いよね。

私はfedibird.comの管理者で、mstdn.jpについては部外者なので何もできないけど、mstdn.jpの管理者に一言連絡入れておくね。

ただ、mstdn.jpは特に登録しなきゃいけないサーバではないから、登録できなくても気にしなくていいんじゃない?

fedibird.comとtoot.blueが使えるなら十分だと思うよ。そこからmstdn.jpや他のサーバのアカウントをフォローするのが基本的な使い方。fedibird.comには、mstdn.jpの人の投稿に絞り込んで見る機能があるよ。
fedibird.com/web/timelines/pub

あと前にお話したかもしれないけど、マストドンには日本の公式サーバみたいなものはないよ。

マストドンの本家が運営しているサーバがドイツにあって、そこが旗艦サーバだから、そういうところに登録してみたいなら mastodon.social に登録するといいよ。

11:35:45

引用符をエクスポートしている問題の投稿のid(uri)に、.jsonをつけてブラウザなどでリクエストすると、outbox.jsonの該当項目と同じ内容がサーバから得られます。

サンプルがあれば理由を説明できるかもしれないので、良かったらuriを教えてください。

11:40:20

ごはんのところがビリヤニ! カレーはおまけ!

11:41:17

パソコンサンデーのおじさん

11:53:17

Google翻訳にしろ、DeepLにしろ、翻訳し易い原文を与えると翻訳結果が正確で綺麗になるので、そういう工夫は私もずっとしてきた。

生成AIも、そういうのが上手な人が、上手な結果を得てるんだろうね。

11:59:50

なるほど。かなり過剰にエスケープ入りますね……。

直せるなら直した方がいい感じがする。

12:02:13

なお、機械翻訳は、逆方向に翻訳して確認するのは必ずやってる。日本語→英語なら、結果の英語→日本語を試すということ。

ここでだいたい一致するのが、いい原文。

12:52:57

2017年4月に、日本で最初のブームがあったのね。

その時に立ち上がったサーバの一つがmstdn.jpで、最初はそういう名前じゃなかったんだけど、誰かが日本の公式サーバっぽいドメインとキャッチコピーでやっちゃいなよって提案したらしく、そこに人がたくさん集まって、日本の中心的なサーバとして成長した、っていうところまでは歴史的にあるんだ。

ただ、大学生が実家のPCで立ち上げてみただけのサーバにとんでもない人数が殺到したので、さくらインターネットやドワンゴが支援したり、別の運営者が引き継いだり、そこが手に負えなくなってさらに別の運営者が引き継いだりして、運営も大変だったし、

自由な気風で、よほど迷惑を掛けない限り制限したりしないので、よく言えば誰にも遠慮せずに使えるサーバ、悪く言えば治安の悪いサーバということで、

このサーバが日本鯖って名乗るのはどうなのか? 誰もがmstdn.jpにアカウントを作るものだと思い込んでいて、アカウントを作ってみてビックリし、Mastodonの悪評が広まるのはどうなのか? みたいな議論が絶えなかったんだよ。

そのうち、なんか喧嘩したり、サーバトラブルでマトモに使えない時期などを経て、いろんなサーバに人が散ったので、今はそういうのも昔話になったね。

13:00:29

で、イーロンマスクがやってきて、何度かマストドンに人がいっぱいくるブームみたいなのがあっって、日本ではmstdn.jpの他、pawoo.netやfedibird.comが引き受けていたんだけど、それだけでは厳しいぐらい人が増えた。

そのとき、バイク鯖ってテーマサーバを運営していたくろりんごさんが、自分も何かできないかということで、mastodon-japan.netっていう、もう一つのmstdn.jpを意識したサーバを作ってくれたりしたよ。いまも人数はそんなに多くないけど、登録可能な汎用サーバとして有力候補になるところだよ。

fedibird.comは、3万人を越えたあたりで、これ以上大きくしていくと、サーバの特徴や運営方針と合わないユーザーが増えてしまうミスマッチが拡大していく状況が見えていたし、運営費用を賄いきれなくなるから、登録を承認制にしたんだよ。そのまま登録を受け付けていれば第二の日本鯖になったと思うけど、あえてそうはしなかった。

そういうわけで、まあまた必要があれば新たな日本鯖みたいなのを作ってもいいけど、今は他の人に任せているよ。

13:31:38

Mastodonも含めてどれも大差ないけど、ささいなところで躓くのはどれも同じ。そうなると情報量の差がでるのよね。みんなが使ってるやつの方がいいってなりやすい。

13:35:38

たとえばMastodonについて何かライトニングトークやってって言われたら、5分なら、まぁやってもいいよって即答できるけど、15分喋れとか言われるとそれなりに準備が要るよね。

ちなみに私の基準はスライド1枚1分。

13:41:48

errata

あっって → あって
承認制 → 招待制

13:42:30

こん! 🍎 🍎
火曜日は、なんだか手応えがあるね。いい一日にしよう。

14:24:46

:gplus: :gplus2:

:bplus: :bplus2:

14:47:13

たしかBridgy Fedっていうか、ATprotoの仕様で _ をハンドルに使えないために、MastodonやMisskeyの名前に _ を含む場合 - に変換するって話がありました。
atproto.com/ja/specs/handle

これ、実際のところ、どう対応すればいいんでしたっけ?
QT: fedibird.com/@gimlet_202407/11
[参照]

投稿の参照(1件) by のえる (@noellabo@fedibird.com)
2024-12-10 14:09:31


Bridgy FedでBlueskyからブリッジされたアカウントの投稿が流れてきていないようです。添付画像は私のFedibird・misskey.io・自分のMisskeyインスタンスのタイムラインで、いずれも私のBlueskyのブリッジアカウントをフォローしていますが、Fedibirdだけブリッジアカウントの投稿が流れてきていません。また、ブリッジアカウントのプロフィールページを見たところ投稿が更新されていないようです。調べていただけますか?
Bridgy Fedによるブリッジアカウント:

2024-12-10 14:09:31


Bridgy FedでBlueskyからブリッジされたアカウントの投稿が流れてきていないようです。添付画像は私のFedibird・misskey.io・自分のMisskeyインスタンスのタイムラインで、いずれも私のBlueskyのブリッジアカウントをフォローしていますが、Fedibirdだけブリッジアカウントの投稿が流れてきていません。また、ブリッジアカウントのプロフィールページを見たところ投稿が更新されていないようです。調べていただけますか?
Bridgy Fedによるブリッジアカウント:

15:05:01

Misskeyなどで認識している投稿のURLを使ってfedibird.comの検索にかけると、その投稿を手動でとってくることはできるようです。

fed.brid.gy/r/https://bsky.app

fed.brid.gy/r/https://bsky.app

データ形式で弾く場合はURLからの取得は不可なので、そこは問題ではなさそう。 [参照]

投稿の参照(2件) by のえる (@noellabo@fedibird.com)
15:24:55

まだそこまではわかりませんが、たとえばブリッジがリダイレクトを複数回行うなど、各実装が想定している範囲を超える挙動をする部分があるので、条件を絞り込んでいく必要があると思います。

ブリッジ接続している人の投稿は多数届いていますので、ギムレットさんのアカウントで発生している固有の問題を見つけ出す必要があります。

調査に時間要るので、もうちょっと待ってね。

16:46:06

なるほど。となれば、サーバ側で細工した方がいいかもしれませんね。ちょっとやってみます。

16:53:08

内部的に再フォローを掛けました。WebUIであれば、フォロー承認の通知が発生しているハズです。

これで何かBluesky側でテスト投稿して流れてくるようになっていたら成功です。

17:05:52

baraag.netあたりかな。misskey.ioの基準ではNGのエロ系サーバというだけなので、大丈夫そうな相手ならOKでいいと思いますよー。

18:05:59

バグかもしれないから調べてみようか。

18:20:33

フォローを受理するのは何も問題ないのですが、こちらからフォローバックすると、無修正イラストがmisskey.ioに流れ込んでしまうので、そこがつらいところです。

23:40:47

データベースの選択といえば、PixelfedでPostgreSQLを選択するのが地味に地雷だ。なんか動かないなって思ったら、それはDBの違いだ。PostgreSQLで確認してないと思われる。MySQLを使うべし。

23:48:06

すごく、そばめし感あるね……

23:52:45

FediSnap、Pixelfedだけど、写真だけじゃなくて、みんな思い思いに何か作ったもの発表したり、絵をあげたり、ゲームの動画あげたりしてるので、試してみるといいよ。