Timeline for main list by gnusocialjp, page 12

ねね
むい

@tundie mastodon.socialなどバニラのMastodonからリアクションは見えないはずです。カスタム絵文字の話かな？

クライアントアプリのいくつかが横長の絵文字に対応しているので、閲覧環境を変えてしまった方が楽かもしれませんね。

@Gargron It's because of the intense time we've had overcoming many difficulties. But it's still only 1/3 of our life. Happy birthday, Eugen.

@tell_me_fedi_jp @ishii00141

翻訳機能が有効なMastodonサーバでは、投稿の下部に翻訳リンク（利用者の言語によって表記は違う）が表示され、機械翻訳が利用できるようになっています。

この翻訳リンクが表示されるためには、対象の投稿の言語と、利用者の表示言語が、翻訳できる組みあわせを満たしている必要があります。mastodon.socialの場合は、DeepLの対応言語の組みあわせかな。

今回の件では、恐らく日本語指定されたいしいさんの投稿を、日本語以外の表示言語に設定されている方が、翻訳リンクによる翻訳を利用したかったのだと思いますが、ひょっとすると組みあわせを満たしていなかった可能性はあります。あるいは、iOSやAndroidのクライアントアプリ利用で、別の条件が発動していたかな？

翻訳は一度行うとサーバ内にキャッシュされるので、当時なんらかの一時的な理由で機能しなかったとしても、あとで有効になった時にキャッシュされることもあるため、これから検証しても原因不明になるかもしれません。

ちなみに、Misskeyは投稿に言語設定がないので、日本語から日本語への翻訳リンクが出現したりします。

投稿者として気遣えるのは、正しい投稿言語を指定しておくことぐらいですね。

@tell_me_fedi_jp @ishii00141 ブロックは当事者間にのみ影響を与えるもので、無関係のBには何も影響を及ぼしません。

また、ActivityPub全体で言うと、ブロックが相手のサーバに伝わって、相手方で作用すること自体も期待できません。

ブロックはそうした目的には不向きです。

ATフィールド張ってるのかな

FediMovieの利用規約では、

> 不特定多数に公開する権利をもたない動画を、公開動画としてアップロードしないでください。（URLを不特定多数に公開した未収載の動画は、公開動画とみなされます）

という言い方をしています。

ここでいう未収載はFediMovie上の公開範囲のことで、YouTubeでいうところの限定公開です。

SNSの鍵垢はXを想定していると思われますので、Fediverseではフォロー承認制＋フォロワー限定投稿のみと解釈しますが、

フォロワー限定投稿でURLを知らせる行為は不特定多数への公開と見做します。

なお、公開する権利があるかどうかの判断は通常は困難です。……困難なハズなんですが、判断が難しいものは少なく、だいたい見るからにわかりやすく駄目です……。

TogeなしTogeありTogeToge

Hageもあるよ

参照がTogeと言えなくもない《否定の連続》 [参照]

美味しかったナポリタンこれ #gochisou_photo

@feather_users 公式Discordとの役割分担としてはやはり、

・Fediverse上で語れる → みてもらう機会が多い

・ちょっとしたつぶやきを受け入れやすい

というあたりかな。

こっちで拾った話は、必要だと思ったら、誰かがDiscordにフィードバックすればいいと思うよ。

マンゴー苦手だと、マンゴーラッシーはさすがに……

コミケの最大手、トイレ待機列みたいな話だね！ [参照]

@tell_me_fedi_jp @ishii00141 また、投稿にrepliesコレクションを持たせ、返信された際に、された側が受理するかどうかを決め、コレクションへの追加・削除を関係者にAdd, Removeで伝達する方式も提案されています。

返信する前に返信可能かどうかを伝える方法は特に考慮されていないようです。

従来通りの投稿に対しての返信は即座にリプライツリー（スレッド）を構築する一方で、

対象がrepliesコレクションを持つ投稿の場合、Addされるまで返信としてリプライツリー構築しないように実装する必要がありますね。

@tell_me_fedi_jp @ishii00141 現在の主要なActivityPub実装においては、返信となる投稿に返信先の投稿へのポインタinReplyToが定義されていて、この情報を元にそれぞれのサーバがリプライツリー（スレッド）を構築しています。

特定の実装において、このリプライツリー（スレッド）構築に介入し、切断を行うことは可能です。

ただし、それを統一的に行う仕組みが現在のところないため、連合することができません。

Mastodonで提案中の方式としては、canReply, replyApproval, ApproveReply, RejectReply を使った返信元と返信先との返信許可の状態管理があります。

・投稿にあらかじめ返信を許可する範囲を定義しておきます canReply

・投稿に返信が来たら、許可する場合はApproveReply、拒否する場合はRejectReplyを返信側に返します

・許可済みの返信を、投稿のreplyApprovalに追加します。これを見て各実装はinReplyToを処理してスレッドをつなげてよいか判断します

・あとで返信に拒否を送ることで解除できるようになります。replyApprovalの更新により連合します。

留守電の文字起こし機能は神

トランジスタのボリューム

離合、ローカル用語なので毎回意味を調べてしまう。

まだ動いてるTootdonって存在するんですね……