のえる @noellabo@fedibird.com

Misskeyのリノートは、何度も出来る仕様になってるからね。

ちなみに受け取る側のMastodonは、同じノートのリノートは（事前に解除しておかないと）受け付けないんで、覚えておくといいよ。

結果として、Mastodonから見ている人にとっては、高頻度でリノートされてもうるさくないのです。

リワード広告を解説する2P目に遷移するやいなや、あらかじめリワード広告が出る妙味よ！（褒めてはいない） [参照]

test
#feather

長州力

？ 長州に要する力
〇 長州で発揮する/発生する力 [参照]

git reset --hard FETCH_HEAD

🦍 🦍

契約文書、相手側が最大確保する内容になっていることが多いので、妥当でない場合は条文を直すよう求めないといけないんだけど、面倒くさいよね。

ある企業のプロダクトの評価に参加することになったとき、私がそこで話した内容のみならず、私の知識・知見まで全権利を取られる内容の契約書（の原案）をよこしたので、さすがに話し合って解決したよ。

30年以上前、NIFTY-Serveの規約が、投稿したりアップロードしたものをNIFTY側がいろいろ勝手に使える内容になってて憤慨したの思い出すね。懐かしいわ。

専門性の高いサーバ・話題のハッシュタグといえば……

#gochisou_photo かな！

夜更けの民の為に、ヤマモリのガパオライスの写真つけとくね！！！！

バグの原因、どうしようもない凡ミス、あると思います……

#fedibird #fedibird_info FedibirdもPleroma / Akkomaも、便乗リアクションができます。

既に投稿についているリアクションであれば、自分のサーバに登録されていない絵文字を使ったリアクションが可能になる機能です。

この際、他のサーバの絵文字情報を添えてリアクションのActivityを送信します。

受け取る側は、既に知っている絵文字であればそのまま受理しますが、知らない絵文字は、いったんリモート絵文字として登録した上でリアクションとして受理する流れになります。

このとき、他サーバの絵文字の情報が虚偽であるとマズイので、リモート絵文字を登録する前に、本来の絵文字の帰属サーバに問い合わせて存在確認をします。

ところがPleroma / Akkomaは絵文字の情報（Object）を取得できるurl（ID）に絵文字の画像URLを返してくるので、Objectを取得して照合することができません。

このため、未登録の第三者の絵文字を登録する処理を安全に行うことができず、この絵文字リアクションは失敗することになります。

あまり頻度の高い状況ではないのですが、制限ではあるので、一応気に留めておいて下さい。

#fedibird #fedibird_info 絵文字リアクションの連合まわりについて、実装上の不備や仕様の変更を行いました。

・Pleroma / Akkomaに対し、絵文字リアクションを送ってもお気に入りとして届く問題を修正

・Holloからの絵文字リアクションを受け取れない問題を修正

・リアクションに添付する絵文字の情報をID（URI）のみで表現しても受理できるよう変更

・絵文字リアクションに対応したサーバへは、EmojiReact Activityを送信するよう変更

・お気に入りのみ対応のMastodonなど、絵文字リアクションに未対応のサーバへは、Like Activityで送信する（従来通りの仕様）

また現在、Pleroma系の仕様により、既についているPleroma系他サーバの絵文字を使ったリアクションに便乗した際、相手サーバがまだその絵文字を一度も受け取っていない場合は失敗します。

うん、何を言ってるかわかりにくいね！ リプライで詳細を説明します。

@FloatingGhost In Pleroma/Akkoma, the ID of the Emoji Object is the URL of the image. Is there a reason for this?

When an Emoji Object is sent from an untrusted third party, I want to check the origin, but I'm having trouble because I can't do that.