このアカウントは、notestockで公開設定になっていません。
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator(開発者の一員)です。また、独自機能を盛り込んだFedibirdを管理・開発しています!
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@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.
#fedibird #fedibird_info 絵文字リアクションの連合まわりについて、実装上の不備や仕様の変更を行いました。
・Pleroma / Akkomaに対し、絵文字リアクションを送ってもお気に入りとして届く問題を修正
・Holloからの絵文字リアクションを受け取れない問題を修正
・リアクションに添付する絵文字の情報をID(URI)のみで表現しても受理できるよう変更
・絵文字リアクションに対応したサーバへは、EmojiReact Activityを送信するよう変更
・お気に入りのみ対応のMastodonなど、絵文字リアクションに未対応のサーバへは、Like Activityで送信する(従来通りの仕様)
また現在、Pleroma系の仕様により、既についているPleroma系他サーバの絵文字を使ったリアクションに便乗した際、相手サーバがまだその絵文字を一度も受け取っていない場合は失敗します。
うん、何を言ってるかわかりにくいね! リプライで詳細を説明します。
#fedibird #fedibird_info FedibirdもPleroma / Akkomaも、便乗リアクションができます。
既に投稿についているリアクションであれば、自分のサーバに登録されていない絵文字を使ったリアクションが可能になる機能です。
この際、他のサーバの絵文字情報を添えてリアクションのActivityを送信します。
受け取る側は、既に知っている絵文字であればそのまま受理しますが、知らない絵文字は、いったんリモート絵文字として登録した上でリアクションとして受理する流れになります。
このとき、他サーバの絵文字の情報が虚偽であるとマズイので、リモート絵文字を登録する前に、本来の絵文字の帰属サーバに問い合わせて存在確認をします。
ところがPleroma / Akkomaは絵文字の情報(Object)を取得できるurl(ID)に絵文字の画像URLを返してくるので、Objectを取得して照合することができません。
このため、未登録の第三者の絵文字を登録する処理を安全に行うことができず、この絵文字リアクションは失敗することになります。
あまり頻度の高い状況ではないのですが、制限ではあるので、一応気に留めておいて下さい。
@imfine_never 日本語圏のMisskeyユーザーが多いこともありますが、
Misskeyはデフォルトで全ユーザーの公開とホーム投稿が検索許可、Mastodonはデフォルト禁止で、公開投稿を、許可した人だけ検索可となるので、かなり許可割合・範囲が異なる点は注意が必要です。
@askyq unicode絵文字受け取れないバグはなおしたよ。
kmy.blueはともかく、既存kmyblueインスタンスに従来通りLikeで送る対応いれておいた方がよさそうね。
@askyq とりあえずfedibird.comからkmyblueとして認識している24ドメインに対しては、絵文字リアクションをLikeで送るようにしたよ。
@yuicho nodeinfoは30分ぐらいブラウザとか相手環境にキャッシュされるよ。
https://github.com/mastodon/mastodon/blob/1fc165de02d79294c8a218f5fa82bcd477484ca1/app/controllers/well_known/node_info_controller.rb#L17-L18
あまり更新されないが、かなり頻繁に参照されるので、強めにキャッシュかかるんよ。
@blahat 代表的なのはkmyblueだね。あと、glitch-socでも作ってて、ずっとプルリク開いてるよ。
このアカウントは、notestockで公開設定になっていません。
@vulpes22accipiter 気が向いた時にゆるく交流したい人が、自己紹介、おはよう、おやすみ、近況などを投稿している、ラウンジ・カフェテリア的な場所として #fedibird ハッシュタグのタイムラインがあります。
全文検索したり、ハッシュタグやキーワードを購読することで、タイムラインに興味のある対象を流すという独特の使い方があります。
もちろんフォローを介してお互いを意識しながら交流していくことも有効です。
あまり繋がらずに壁打ちしたり、本当に自分のためだけに『自分限定』という投稿範囲で記録しておくこともできます。
使い方の幅が広いので、自分に合ったやり方でご活用ください。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@fohte 『別のサーバー』が1のpostを4の前に既に受け取っている場合は、4のrepostに関わらず、edit対応の有無で結果がでているので、これは除外。
まだ『別のサーバー』が1のpostを知らない場合、4のrepostの時に『別のサーバー』は元のMastodonサーバへfetchする。この時、edit対応の有無にかかわらず、edit後の内容が取得される。
2にある情報で利用されるのはpostのuriのみ。内容は1から取得するか、もう手元にキャッシュがあるならそれを使う。
@fohte postを受け取った時点、JSON-LD署名がついているjsonであれば転送することができるんですが、一度受け取ってデータベースに保存した他鯖の投稿内容をjsonに組み立てて転送しても、出所が投稿したサーバではないし、署名も残っていないので、相手に信用してもらえません。(信用する実装があるかもしれませんが、容易に騙されることになります)
@FrosPhia サーバのスペックに余裕が少ないと、動画変換しきれずにエラーになってしまうケースがあるようです。
@daihard 改めて調べてみましたが、投稿と直接の返信を1つ表示する以外に設定なさそうですねえ。
一応、testからtest4までの交互に返信しあった4投稿を表示するとこんな感じなので、表示されていないわけではないようですが……。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
30年以上前、NIFTY-Serveの規約が、投稿したりアップロードしたものをNIFTY側がいろいろ勝手に使える内容になってて憤慨したの思い出すね。懐かしいわ。
契約文書、相手側が最大確保する内容になっていることが多いので、妥当でない場合は条文を直すよう求めないといけないんだけど、面倒くさいよね。
ある企業のプロダクトの評価に参加することになったとき、私がそこで話した内容のみならず、私の知識・知見まで全権利を取られる内容の契約書(の原案)をよこしたので、さすがに話し合って解決したよ。
@ottoto2017 どうやって確認したかによるね。NodeInfoが30分ぐらいキャッシュするのとか。
@ottoto2017 WebUIなら、ブラウザで最初に開いた時に<head><script id='initial-state'>に含まれる値を使うので、リロードするまでは以前のバージョンです。
@nove_b Fedibirdは相手サーバのNodeInfoや/api/(v1|v2)/instanceなどの情報を取得して保持していますが、この情報取得に失敗していたようです。
手動で取得し直して対応しました。
@hiko_watage 相互フォロー限定はサークルなので、これは正しい動作です。
あらかじめ用意したサークルメンバーの代わりに、投稿時点で相互になっている相手を自動指定するサークルです。
Misskeyのリノートは、何度も出来る仕様になってるからね。
ちなみに受け取る側のMastodonは、同じノートのリノートは(事前に解除しておかないと)受け付けないんで、覚えておくといいよ。
結果として、Mastodonから見ている人にとっては、高頻度でリノートされてもうるさくないのです。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
リノート(ブースト)には、
自分が投稿する内容に関連した記事を、文脈を明示するために行うものと、
露出機会を増やすために行うものがあるけど、
露出機会を増やす目的で行うなら、前のリノートは解除しておくのがベターかもね。
そういうことを実践している人はまだいないかもしれないけども。
露出機会を増やすためにリノート連発し過ぎると、リノートをミュートされてしまいます。アカウント自体をミュートされるかもしれません。
フォロワーや機能を使いこなしている人達には敢えてミュートしてもらって、まだ認知されていない人に向けてリノートを見せていく、という戦略もとれなくはないですが、
運営の意向にも反しますし、自身のリーチ力、拡散力を放棄することにもなります(応援リノート効かなくなるし)。
とはいえ、ローカル・ソーシャルタイムラインを中心に見ている人は、自分がログインしている時にリノートされてこないものは見ていないですし、
ホームでみているフォロワーにしても、遡って全件チェックしているとは限りません。見落としもあります。私自身の体感としても、フォロワーに届いていない率はかなり高い。
ログインしている時間帯別にリノートしたり、日を置いてリノートすれば、効果が出ます。
リノートで行き渡らせる効果は大きく、リノートしないという選択は厳しい。
さて、どうしましょうね?
Mastodonのブーストの仕様についておさらいしておきましょうか。
Misskeyの人もチェックしておくといいよ。
・『公開』と『ひかえめな公開(未収載・非収載)』であれば、誰の投稿でもブーストできる
・『フォロワー限定』の投稿は、投稿者本人だけがブーストできる
・ブーストにも公開範囲がある。自分自身のデフォルト公開範囲になる(鍵運用の人はフォロワーにだけ届く)。ブースト時にダイアログを表示するようにしておくと、その場で変更することができる。
・同一アカウントが一つの投稿をブーストできるのは1回だけ。もう一度ブーストしたい場合は、先に解除する必要がある。
・ブーストはフォロワーのホームとリストにだけ表示される。ローカルタイムラインや連合タイムラインには表示されない。
・短時間にホームタイムライン(またはリスト)に同じ投稿のブーストが流れてきても、表示しない機能がデフォルトで有効になっている(無効にして、全部表示させることもできる)。
ホーム(orリスト)の先頭から40個以内に元投稿かブーストがある場合、それ以上ブーストは挿入されない。
・Misskeyなどから、同一アカウントによる同一投稿のリノートが流れてきたら無視する(Mastodonでは許可されていないため)
再表示しないとこ、肝心な仕様が抜けてるね。
・各ユーザーのホーム(リスト)に保持されている(最新Mastodonでは800件・変更されていることも多い)投稿の中に既にブーストがあれば、新規に挿入しない。
これは、タイムラインの最後がどのぐらい前になるか人によって違うと思いますが、保持件数が2,000件に拡大されているfedibird.comの私のホームについて言えば、6時間〜10時間です。
Mastodonではよくある使い方ですが、文脈を示すためにブーストした時に、みんなが話題にしていると、大抵は省かれることになります。
みんなで言及しているとタイムラインがその話題に溢れているので、あの投稿の話か、と理解できるんですけどね。
これを嫌ってブースト省略無し・毎回表示にしている人もいます。
> BT
と書く人もいますね。
私がお勧めなのは、投稿末尾に投稿のURLを記載する方法です。IceCube(クライアントアプリ)の引用は、メンション+投稿末尾URL記載です。
Fedibird系では『参照』が使えます。Misskeyなら『引用』があります。
余談ですが(細かい仕様)
誰かがブーストを解除すると、そのブーストによって省かれた別のブーストが繰り上げ当選されます(タイムラインに出現する)。
わざわざそのために保持してあったりします……。
@ELshE5 -missingって名前のついたテーマを選んでいませんか?
-missingはアバターアイコンをデフォルトアイコンに強制するテーマなので、別のテーマを選択すればなおるかも。
@NaOHhnmk 人によるけど、数時間だけ再表示しないということなので、最初の一回はちゃんと届くよ。
もう見たやつを何度も表示しない仕組み。
Mastodonユーザー向けにも説明した方がいいかな。
Mastodonにおけるブーストを、Misskeyではリノートと言います。
リノートはブーストと基本的に同じものですが、いくつか根本的に仕様が異なるところがあります。
ひとつは、ローカルタイムラインやグローバルタイムライン(連合)に流れるということです。
Mastodonはフォロワーに対してのブーストしかできませんが、Misskeyは直接パブリックスペースにアピールできるため、だいぶ意味合いが変わります。
悪意を持って晒すのも容易ということで、長所でも短所でもあります。
競争が激しく、かえって目立ちにくい面もあります。
もう一つは、同じ投稿を何度でもリノートできることです。(2つめ以降はMastodonで受け取れません)
リノートの表示を抑制する仕組みとしては、Mastodonのような『ブーストをまとめる』機能はありませんが、
リアクションやリノートしたノートを畳んで表示する機能があります。
リノートがうるさい場合、Mastodon同様、タイムライン単位、アカウント単位で、リノートを表示しない設定があります。
Misskeyには標準機能に引用があるため、Mastodonより言及目的でリノートするケースは少なくなります。
@kuroringo データベースは残しておいて新旧2台で動かして、本体が安定して動くようになってから2段階目でデータベース移動するとスムースかな。
もうちょっと頑張るなら、新旧データベースをレプリケーションしておいて移行するっていう手もある。最小停止時間で移行できる。
ま、停止して移行でいいと思いますw
@liaizon People don't know about the different features of different server implementations as much as we think. By comparing and contrasting, we can see that Mastodon is carefully designed to not overheat the competition.
Fedibird can't renote like Misskey, but it can include boosted posts as an option in the remote server domain subscription, so you can see a timeline like Misskey. Just like what Misskey users see.
We are also considering making reboosting a little easier while keeping with the Mastodon philosophy.
@aquarla 一旦、全部削除したよ。
Remove unused E2EE messaging code #31193
https://github.com/mastodon/mastodon/pull/31193
@ninki_jikkyousya mstdn.jpにもサーバ機能として予約投稿ついてるよ。対応アプリが限られてるけど、いくつかある。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@noellabo@gorone.xyz この投稿がみえている人、確認のためにお気に入りか絵文字リアクションしてください。
ブーストできるけど、テストにならなくなるのでやらないでね。
@__ まあほとんどのサーバは動作テストしにいってるだけだね。mstdn.jpは最初のアカウント。使っちゃいないが特別かな。
このアカウントは、notestockで公開設定になっていません。
TIPSあげとこ。
Webサイトが、ユーザーにプッシュ通知したり、オフライン動作をサポートしたり、アプリのように動作させたりする(PWA)ために、Service Workerという仕組みを使います。
Mastodonも、ホームに追加してアプリ化して使えるようにしたり、ブラウザを閉じていても通知を受けられるようにするために使っています。
ブログとかニュースサイト、ポータルなどが、最新情報をプッシュするために使うこともあります。
Mastodonのようなアプリ系はまだいいのですが、たまたま訪問した情報サイトなどで、騙して了解させて、都合のよい情報を送り続けるのに使われたり、面倒くさいヤツでもあります。
不要なものが仕込まれてるとやっかいですし、一覧して、選んで消したいですよね。
chromeの場合は、アドレスバーにこれ入力してください。
chrome://serviceworker-internals/
細かくいろいろでてきますけど、よくみるとどのサイトから仕込まれているかわかるので、Unregisterボタンで消しちゃいましょう。
@fohte 概ねあすかさんが書いた通りです。
inboxに投げてきたサーバのドメインに所属するActorなのか、あるいはJSON-LD署名されているものか、参加しているリレーのActorによる転送か、など、いろいろ判定があります。
iOSのアクセスガイド便利だよねー。
これでアプリ固定しておくとスライドして別のアプリに切り替わるのも抑制できるので、
デレステのライブをプレイ中に画面が切り替わる事故とかも防げる。
配信するときも安全対策になるし。 [参照]
みんなどこかにある桃源郷を求めてるから……ん……どこかできいたことあるな桃源郷……と思ったらゆっきゅんとこのサークルだった。
@p__hone PeerTubeは、利用者それぞれのPeerTubeサーバからみる方法と、配信元のPeerTubeサーバから見る方法があるのね。
どちらも、特に何もしなければ、配信元からストリーミング再生したものを表示するだけなので、結果としては同じなんだけど、
利用者のサーバがキャッシュする(冗長化する)設定をしていれば、所属するメンバーに向けては、そのキャッシュを再生することができるんだ。
本当に人気のある、所属ユーザーが必ず見るような動画は、この冗長化設定をしておくことで、ヨソの混雑に巻き込まれずに再生することができるよ。
あと、同時視聴者のブラウザ同士で通信してデータをシェアする仕組みもあるので、同時視聴者が多い方がオリジンサーバの負荷が軽くなるというのもあるよ。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ところでMastodonのWebUI、シングルカラムとマルチカラム(上級者向けUI)のどちらを使ってますか?
※ Mastodonには、Twitter風のシングルカラムと、TweetDeck風のマルチカラムのUIがあり、切り替えられます
※ スマートフォンではモバイル用になるので、PCやタブレットで利用する場合のお話です
※ サーバによって使い分けている場合は『両方』で。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
ところでMastodonのWebUI、シングルカラムとマルチカラム(上級者向けUI)のどちらを使ってますか?
※ Mastodonには、Twitter風のシングルカラムと、TweetDeck風のマルチカラムのUIがあり、切り替えられます
※ スマートフォンではモバイル用になるので、PCやタブレットで利用する場合のお話です
※ サーバによって使い分けている場合は『両方』で。
@zundan そう言われてみれば、Vivaldiみたいに、サイドのパネルとしてMastodonみてる人っていうのもいるよね。
@ponapalt バキュームテーブルに噴射するモードがあって、重たい板でも楽々に動かせるんよ。そうしないと擦り傷つけちゃうんで!
テーブルの外については、人数かけて動かすしかないよ\(^o^)/
噴射すると、エアホッケーできるよ\(^o^)/
昔よく、mstdn.jpがたまたま落ちてると『これは分散を促進するために敢えて……』とか言われたのを思い出すよね。