@Aqraf 私もよくわかっていなかったとき、通知をActivityとして送っているんだと思っていた時期があるよ。でもどこにもそんなものなかった。
たとえばブーストの通知は、ブーストした人のサーバAから、ブースト対象になった元投稿のサーバBへAnnounce Activityが送られてきた時に（※元のサーバには必ず送る）「あ、ウチのサーバの投稿がブーストされたな？」と気付いたサーバBが通知するんよね。
通知はアクションした人のサーバじゃなくて、アクションされた人のサーバが発行してる。
のえる(@noellabo@fedibird.com)の投稿
主に、Fediverseへの関心に基づいた投稿を行うアカウントです。DTP・印刷に関する話をしたり、同人の話をしたり、カレーをブーストしたりします。
Mastodonのcollaborator（開発者の一員）です。また、独自機能を盛り込んだFedibirdを管理・開発しています！
Mastodonサーバ『fedibird.com』の管理者アカウントでもあります。ご連絡は当アカウントへ、サーバインフォメーションについては https://fedibird.com/about/more と @info を参照してください。
@Aqraf 私もよくわかっていなかったとき、通知をActivityとして送っているんだと思っていた時期があるよ。でもどこにもそんなものなかった。
たとえばブーストの通知は、ブーストした人のサーバAから、ブースト対象になった元投稿のサーバBへAnnounce Activityが送られてきた時に（※元のサーバには必ず送る）「あ、ウチのサーバの投稿がブーストされたな？」と気付いたサーバBが通知するんよね。
通知はアクションした人のサーバじゃなくて、アクションされた人のサーバが発行してる。
【お知らせ】
HostdonでホスティングされているMastodonインスタンスから送信されるメールのアドレスについて，8/1以前に契約されたお客様は「noreply@hostdon.jp」となっておりますが，諸事情により順次「noreply@mail.hostdon.jp」へ変更させて頂きます．
ものすごくざっくりなんですが（ざっくりみるようにしてますが）、
まあ1,000人のうち1人ぐらいはサーバ立てたり運営参加・支援したりする熱心な人がいて、残りの人はその人のところに集うって思っておきましょう。
その集まり方も、積極的に評価したりリスク回避したりする人は極少数で、あとは雰囲気で参加するサーバを選びます。人が多いとか、誰か知ってる人が使ってるとか。
そして、たとえば私も、自分の専門分野（片足突っ込んでるようなやつ）以外は、その他大勢の一人です。
中規模以上の、フリー登録で実際に人を受け入れているサーバというのは、自然にそういう構成比になるので、そのありのままの状態を受け入れた方がよろしいかと思います。
で、人数が多くなると限界が来ます。いろいろ。
障害が増えるとか、速度が遅くなるとか、財政難になるとか、管理者の横暴が許せなくなるとか、ローカルルールがはびこって息苦しくなるとか、まあいろいろ。
その時に、分散したり、別の人がサーバを立ててやり直したりできる特徴が生きてきます。
その芽を摘まないようにだけしておけば、あとはなるようになるので、
無理に思い通りの状態にしようと思わない方がよいと思います。
@teaspoon3 のえすきーはローカルありきで運営しているサーバです。ローカルの会話、楽しいですよ。
少し年齢層が高めだけど、若年層も混じっていて、子供の目に触れて支障があるようなコンテンツを伏せていなかったり、子供がふざけているような行動には、親目線的な厳しさはあるかと思います。普段はそういう堅苦しさはなくて、おはようからオヤスミまで、割とみんな日常の話をしたり、変なことやって笑い合ってる、楽しいサーバだと思います。
fedibird.comからは、ここから覗くといいですよ。
https://fedibird.com/web/timelines/public/domain/misskey.noellabo.jp
いま登録とめてますが、招待は出せますので、お声がけ下さい。 #fedibird
@oyuge Mastodonの公式アプリから登録されたのですね。
現在、Mastodonの公式アプリは、サーバを選択する画面に誘導せずに、mastodon.socialというサーバに登録するボタンを優先的に表示しています。注意深くみていれば気が付くのですが、気が付くとmastodon.socialに登録しているという流れです。
mastodon.socialというサーバは、ドイツにある国際的なサーバで、Mastodonの最初のサーバにして、開発者が直接運営している世界最大の旗艦サーバです。
そのままご利用いただいて問題ありませんが、日本ルールで運営されているものではありませんので、EUやドイツのルールに従い、多言語の入り交じった中でご利用いただくことになります。
Mastodonの公式アプリは、Mastodonを初めて使う利用者のために、長期間安定的に運営されているサーバだけをサーバリストに表示するようになっています。しかし、実際には非常にたくさんのサーバが存在します。
#サーバー紹介 というハッシュタグがありますので、これをクリックしてみてください。日本のサーバを、それぞれが自己紹介（他薦もあり）する投稿が確認できると思います。
もし望むなら、それぞれにアカウントを作成できます。
@maybe_jasmine 表示されない絵文字がありますか？
Mastodonで扱えてMisskeyで扱えないケースというのはあまり考えられませんが、具体的にこれというのがわかりましたら教えてください。
技術的な問題なのか、Misskey側で禁止されているなど運用上の問題なのか確認しておきたいと思います。
@oyuge Discordの感覚もあるかと思いますが、Discordの部屋は、Discord Inc.社が提供するサービスの上で貸与されるもので、それとは少し異なります。
Mastodonのサーバは、それぞれまったく異なる運営者が運営しているものです。
自分でインターネットに接続されたコンピューターを確保し、そこに『Mastodon』というソフトウェアをインストールして動くように設置し、自分自身でルールを決め、ユーザーの登録を解放している、独立運営のサービスです。運営資金も成り立ちも、それぞれに事情が異なります。
Mastodonは、その独立運営のサーバ同士がお互いに通信しあってつながる仕組みをもっていて、いま私が使っているfedibird.comというサーバから、mastodon.socialというサーバに、まるで同じサーバにいるかのようにやりとりできるようになっています。
サーバはまったく独立しており、学生が興味本位で設置したサーバもありますし、企業が設置したものも、政府機関が設置したものもあります。
サーバ毎に、ルールも目的も異なるので、サーバ選びは重要です。
同じサーバの人が共有するローカルタイムラインというものがありますが、それ以外はサーバが違っても交流できるのが特徴です。
@maybe_jasmine ざっくりいうと、リモート側（MisskeyでもFedibirdでも）に絵文字リアクションをつけてくれた人がフォローされていないとダメみたいですね。
スクリーンショットの絵文字リアクションがついている人はmisskey.cloudから誰かにフォローされている人で、抜けている絵文字リアクションは、絵文字リアクションしてくれた人がmisskey.cloudから誰にもフォローされていな人、という共通点があるようです。
たいへん参考になりました。ありがとうございます！ #fedibird
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@namaehamada_nai 期限付きで消えるようにする機能、ありますよー
ビリヤニでタバコを想像する人が多いようだけど、私はビリケンさんの仲間かな……と思う方
@namaehamada_nai ユーザー設定のその他をWebの方で開いてください。設定しておけば、featherからの投稿に対しても適用されるはずです。
featherで終了日時は指定できないため、デフォルト指定した際に期限付きにしたくないものは、Webから期限の指定を変更して投稿するなど使い分けが必要になるかと思います。
たしかに、セブンイレブンのビリヤニで、ビリヤニはカレーと組みあわせて食べるものって認識しちゃうの嫌だなぁ、っていうのもわかるよねえ。
そういうの突き抜けて、みんなビリヤニが気になって好きになって、その中の一定数の人がお店でビリヤニ食べるようになることで、最初の思い込みなんて吹き飛ばしてくれるって期待した方がいいと思うけど、そこまで到達できるか。
APIはクライアントの助けになるように実装したいよね。
WebUIだってクライアントだから、フロントとバックを両方やってれば自然にそうなるとは思うんだけども。
誰とどう出会ったかなんて、覚えてて数人だな……。もうずっと知り合いだったとしか認識してないぞ。（Fediverse内の話）
X (formerly Twitter) の諸々、だいたいバグなんだけど、たまに本気だったりするので、どっちにしても信用ならないってところに落ち着く話ではある。どんなシステムでもバグは出るけど、こんなヤベーの頻発させていいとはちょっと言えん……。
ただし、それでもだいたいの人は我慢できちゃう。ここにいる人は我慢ならなかった人が多いので、強い偏りがあることには注意。
思い返すと、私を含む2017年4月頃に来た集団は、これまでのものとは違う新しいSNSの仕組みや新天地にワクワクしてやってきたよね。
自分のサーバ立てられて、自分のコミュニティ作れたり、開発参加して一緒に成長を推し進めたり、好きな機能追加したり、そういうことが楽しくてやってた。
ま、いまもそうなんだけど！
せっかくなので、とりあえず簡単に補足情報かいておいたよ。
あとxanacさんの投稿も！
--
特務機関NERVの情報は、NERV自身の運営するサーバから発信されていて、マストドンやミスキーで受け取ることができます。
総合アカウントの他に、発信情報の分野ごとにフォローアカウントが細分化されていて欲しい情報を選択することもでき、それを時系列タイムラインで見られるので便利ですよ。
https://twitter.com/noellabo/status/1688438233338966017
現在のXのようにAPI制限が厳しく、不具合に振り回され、あるいはそこに多額の利用料を支払うぐらいなら、
NERVのように、自分でサーバを設置してマストドンやミスキーの世界に参加するのも有力な選択肢です。EUやオランダなど公的機関もやっていますし、最近はBBCも直接発信に取り組み始めています。
https://twitter.com/noellabo/status/1688441523556491264
--
https://twitter.com/rk_asylum/status/1688434598727102464
https://twitter.com/rk_asylum/status/1688434826104459269
fedibird.comの招待URLを500人分発行しました。
各URLとも100人の登録で無効になりますので、使えない場合は他のリンクをお試し下さい。
https://fedibird.com/invite/WDJLiARU
https://fedibird.com/invite/QGbP5Zie
https://fedibird.com/invite/qLpvfznW
https://fedibird.com/invite/CWqPEZBR
https://fedibird.com/invite/8mX5h4yv
fedibird.comは、比較的コミュニティ色がなく、自分のペースで活動しやすいMastodon系のサーバです。
一つのサーバに集まる・属するという感覚は薄く、たくさんのサーバに散らばった人々や情報にアクセス・発信する拠点としての性質が強い場所です。
全文検索機能も比較的機能しますので、X (formerly Twitter) に近い使い勝手が得やすいかもしれません。
現在招待制となっていますので、使ってみたい方は、招待URLからお試しください。
--
fedibird.com以外にも、Mastodon、Misskey他、お互いに繋がっているサーバは他にもたくさんありますので、
自分の感覚に合う、利用目的に沿ったサーバを見つけてくださいね。探す際は #サーバー紹介 タグを辿ることをお勧めします。
X (formerly Twitter) で紹介するときは、これ使ってもいいよ。
https://twitter.com/noellabo/status/1688456758166269952
これは、
NERV、停電＆避難情報の投稿を停止
「XのAPI制限が厳しいため」
公式アプリなどに切り替え
https://www.itmedia.co.jp/news/articles/2308/07/news134.html
っていうニュースをうけて、NERVの投稿に補足情報としてX (formerly Twitter)に書いてきたやつね。
QT: https://fedibird.com/@noellabo/110847008625160960 [参照]
@eat_them_all うまくいかなそうなら、そこ無効に設定するんで、アカウント添えて連絡ちょうだいー
#fedibird UN_NERVの件で、Fedibirdユーザー向けのTIPS。
本当に災害が起きた際は、各サーバとも高負荷になり、フォローベースのホームやリストタイムラインは遅延が目立つようになります。購読も同様です。
その時に一番遅延しないのは、連合タイムラインとその派生であるドメインタイムラインです。
従って、NERVのアカウントはお気に入りドメインに登録しておいて、そこをみるようにするともっとも低遅延になります。
なお、利用者が少なくてそこそこ丈夫なサーバに予備アカウントを作っておく方が本当は安全ですw
@makihara ハッシュタグタイムランも早いです。購読は遅延しがちです。
まず、投稿がリモートから到着すると、それを解析して投稿データなどに解釈する処理が走ります。①
次に、それを各タイムラインに振り分ける処理が走ります。②
この振り分け処理は、フォロワーに対して分配する部分でもう一回別の処理を呼び出す多段方式になっているので、その処理が走ります。③
①が遅延すると、全ての処理が遅延します。この処理は優先順位が低いため、本当にどうしようもなく負荷が高いときは意図的に後回しにします。
②の段階で、公開タイムライン（ローカル、連合、ハッシュタグ）などの全員で共有するタイムラインへ割り振りが行われます。従って、ホームよりもはやく配送されます。
③の段階で各自のホーム・リストに配送されます。購読も同様です。普段はそれほど遅延しませんが、処理がパンパンになっていると、②の2倍ぐらい遅延するようになります。連合が10分遅れなら、ホームは20分遅れになる感じです。
招待URLを5つ並べると、最初と最後が人気になるようです（だいたいいつもの傾向）
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
@Tonbi_ko nginxは何でも良いけど、PostgreSQLを他のものに置き換えるのはすごい大変だよ。まあ必須。
@H2N_moon_ もちろん限定効果もあるとは思いますけど、結局登録開放しちゃうとどんどん増えちゃうってことなんで、少しずつ解放していかないと負荷バランス崩れちゃうんですよねー
@akasaka 全投稿を一つずつ削除することに比べると、アカウント削除はものすごく軽い処理になります。
関係するもろもろに伝えるのも、何回も繰り返さずに一度で済みますし、それぞれの内部で効率的に一括削除処理ができます。
@14ma16116 自分の行った絵文字リアクションを一括でみられるカラムがあるので、確認やキャンセルはそちらを！
https://fedibird.com/web/emoji_reactions
@6u6_888 fedibird.comの人は誰でも招待状出せるので、実質いつでもアカウント作れますよ
Mastodonのように、たくさんのユーザーがいて、利用者が同時に使用していることが多く、短い投稿やそれに対する返信、リアクションなどが行われ、タイムラインに次々と新着投稿が流れるようなシステムは、
そのひとつひとつの処理（ジョブ）を実行するワーカーに分割し、必要に応じて順次処理していくことで、ユーザーの操作に素早く応答して結果を返し、たくさんの人が同時に利用してもスムースに流れるように工夫されています。
各サーバーは通常、このワーカーを遅滞なく実行できるだけのハードウェアを準備しているのですが、急激に投稿が増えたり、利用者が増えたりすると、処理能力が追いつかなくなります。（※ いつも処理能力不足のサーバもあります）
ワーカーは、処理が追いつかない場合、順番待ちの列を作って自分の番が来るのを待ちます。
列が長くなってくると、処理が完了するまで5分待つとか、20分待つといった状況になります。
そうすると、タイムラインに流れてくる最新情報が20分前だったり、お気に入りがなかなか反映されない、といったことが起きるわけです。
Mastodonでは 
Sidekiqと呼ばれるバックグラウンドジョブ処理システムを使っているので、『Sidekiqが遅延してる』などという言い方をします。
@saku_mio22 自由な入力を許しちゃうので、たとえば https: から書いてるとか、あと fedibird.com って書いてるとか！ #fedibird
Sidekiqによる、細分化されたワーカーを実行する仕組みは、ジョブの失敗をリカバリーすることに対しても強みを発揮しています。
あるサーバがメンテナンス中で接続できなかった場合、そのサーバに投稿を配送しようとすると失敗します。
このとき、投稿の配送をひとかたまりの処理として一回で実行するようになっていると、その時に繋がらないサーバにはもう配送するチャンスがなく、ダメだったら無視されてしまいます。
Sidekiqを使った仕組みでは、失敗したジョブだけを再実行することができます。
しかも、すぐにやり直しても失敗するので、失敗したら少しずつ間隔をあけていきます。
3時間後につながらなかったら、半日後にもう一回試す、というように、相手側が復旧するかもしれない時間を待つようにつくられています。
これにより、復旧したサーバにも配送が届くようになります。
あまりにも長くつながらなかったら、最後には諦めるようになっています。
連合を柔軟に運用できるようにするための、重要な仕組みです。
ジョブは短時間で実行できる単位に分割します。
そうしないと、ひとつのジョブが長時間占有しつづけることとなり、効率良く他のジョブを同時実行できなくなります。
また、ある処理を実行しているうちに、他の処理の影響で実行に失敗することも起きます。
たとえば、お気に入りしようとした投稿が、何かの都合でもう削除されているかもしれません。
ひとつのジョブが大きすぎると、こういう状況の変化に対応するのが難しくなります。
--
さて、リモートから誰かの投稿がやってきました。
この投稿者をこのサーバでは100人がフォローしているので、100人のタイムラインに投稿を流さねばなりません。
この時まず、リモートサーバから来たActivityの内容を確認するワーカーを実行します。投稿者Aの新規投稿であると解析されました。
次に、この投稿を各タイムラインに配送するワーカーを実行します。
やることの多いワーカーですが、公開範囲を確認し、公開タイムライン（連合、ハッシュタグなど）に流す処理、フォロワーのホームやリストに流す処理を行います。
このうち、フォロワーは人数が多いので、一人ずつのホームとリストそれぞれで100以上のワーカーに分割して走らせます。
難しいかと思いますが、なんとなくイメージできますでしょうか？
@yuicho blobcat系も、各所でオリジナルバリエーションが増えててそれぞれ権利主張があって制限事項などが増えていたりするので、もうなんとも。
統一された権利確認手段がないというのがシステム上の問題点で、運用だけで対応するの無理なところに来てるね。
フォローエクスポートすると、 @ 〜 @ 〜 形式のacctがずらっと並んでいるでしょう？
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
#fedibird このハッシュタグは、狭い意味でいえば、fedibird.comとnightly.fedibird.comのための共通タグですが、
Fedibirdに縁のある方（個人サーバに独立されたとか、最近別サーバメインだがFedibirdも長い方とか）も普通に使われていますし、どこの方でも、Fedibirdってどんなサーバ？ みたいな質問を投げるにも便利ですので、
上手に活用いただければと思います。
#fedibird このハッシュタグが作る空間の面白さ、
オープンコミュニティで、連合先どこからでも参照でき、参加できるところじゃないかなと思います。
自己紹介や挨拶に使うこと以外に特に目的は設定されていないし、
あわなかったら基本スルーやミュートで対応していちいちつっかからない、
ここに投稿する内容はこういう範囲にしておこうという配慮と、まあでも何を書いてもいいっちゃいい、っていう厳しくもなく緩くもないぐらいのバランス感とか、
まあよくこういう場所が成立したよな、と思います。
Misskeyにチャンネルという機能があって、やはりコミュニティ機能を果たしているのですが、
クローズドコミュニティで連合することができず、そのサーバにいないと参加できないなど、性質としては正反対だったりするし、何しろ観測できないので、
同じような目的でやっていても、いろんな形があって面白いなというのもあります。
#fedibird ちょっといま、検索インデックスが構築中で当時の投稿を掘り出せないのですが、
#fedibird タグをどう使えばいいか、という話はいろいろと議論があり、その中で、いまのような流れができた経緯があります。
もともとほとんど私がサーバーインフォメーション的にしか使ってこなかったので、そういう認識の人も多かったのですが、
初期の頃から、自己紹介や共有したいことを投稿するのに使うといいよ、ということもお勧めしてきていて、
ある時期に使われる機会がぐっと増えてから、使われ方が一変しました。
現在ではホテルのラウンジやカフェテリアのような共有スペースになっている感じです。たまにやってきてくつろげる場所なのかなと思います。
あまり干渉せず、楽しそうなら集まってくるし、雰囲気が悪くなれば自然に散っていく、という感じでしょうか。
なおインフォメーションはそういった経緯から #fedibird_info というハッシュタグをつけることにしていますので、その用途にはそちらをフォローしてください。
#fedibird いまのところ弱点としては、そのまま使えば良くて便利すぎるので、個人間のフォローなどにあまり繋がっていない様子なのがあります。まあそこはLTLと同じですね。
FedibirdはMastodonv4.2への統合で進めていくけど、いろいろと判断すべきことが多くなりましたね。
今度のMastodon、自分のアカウントで許可設定すれば、公開投稿を検索できるようにすることになってるのね。
https://github.com/mastodon/mastodon/pull/26344
その許可設定は、いわゆる『ディレクトリに掲載する』設定（discoverble）を使うことになっている。
このdiscoverbleはこれまで、
・ディレクトリに掲載する
・アカウント検索の対象にする
・おすすめアカウントの対象にする
あたりで使われていたもので、アカウントをパブリック運用するつもりなら設定しておくべきものだったんだけど、
・公開投稿を検索可能にする
という意味も付加されるようになるということね。
様々なオプションが検討されるなかで、一番シンプルなこれをEugenさんが選んだということなんだけど、
どのぐらい受け入れられるかな。
searchableのフラグを別にしたい人も結構いると思うけど、どう思う？
まあ、よほど反対が無い限りこの仕様で決まると思うので、ちゃんと反対するなら今なんだけども。
ちなみにFedibirdは、互換性を持たせつつ、詳細設定可能な現在の方向でやっていくよ。
仕様を複雑にすると、ユーザーも対応できないし、設計上の整合性を維持することも難しくなり、また、連合先やクライアントアプリが互換性を持たせる対応をしてくれなくなります。
たとえば、Fedibirdの購読には、個別の拒否設定はつけていません。
設計段階で真っ先に必要性を検討したものであり、なんらかの拒否機能を設けるつもりでいましたが、じっくり練った結果、結局この選択は『公開』と『未収載』の選択に他ならない、という結論となりました。
@tukine 絵文字の画像形式がいろいろあるので、それを調べると答えにたどり着けるかも？
@hyoyoshikawa こういう議題では何度もありましたね。リッチテキスト対応が一番白熱したかなー。
fedibird.comの招待URL、先の500名分がそろそろ終わりなので、追加200名分だけ出しておきます。各100名です。
https://fedibird.com/invite/zD2gVpLX
https://fedibird.com/invite/jJe7hgaU
紹介文については前の投稿を参照してください。
https://fedibird.com/@noellabo/110847195801607678 [参照]
Mastodon is preparing changes to allow searches of public posts, and a decision has been made to make the condition for allowing it a "discoverble" for accounts.
https://github.com/mastodon/mastodon/pull/26344
I have an opinion on this but discussion is not allowed.
If users want to keep their searches restricted as before, the server administrator should recommend that users turn off the "discoverble" setting.
Doing so will result in more users disappearing from directory and account searches.
@binarytango @Gargron As the social role of the Mastodon project grows, and the number of stakeholders, such as those who support the project in return, Github is no longer the place of discussion and decision. I feel very alienated. That's all I can say for now.
尾根ギア、めちゃくちゃよく出てきたのに、いまエラーコレクトされて『お願い』に修正されやがる……
ちなみにdiscoverableのスペルを間違えております。しょぼい……
編集機能でなおして良いのはこのへんかなと思いますw
@scott The important point is that Mastodon is changing the rules it has always followed. Unlisted" is not a solution to a past post.
I have already made a number of suggestions in my own fork, which you can look into if you are interested.
@mironal 挙動の確認には、WebUIでブーストの確認画面をだすのが簡単です。
基本的に、自身のデフォルトの投稿範囲に従います。また、自分自身のprivate投稿は、privateブーストになります。
あと、Fedibirdはブーストの公開範囲についてアイコンつけてますのでわかりやすいかと。
@mironal たぶんinitial_stateにしか出力してないと思うので、ログイン状態でhtml取得して <html><head><script id="initial-state">(json)</script></head>(snip...)</html> から持ってくるしか、いまのところ調べる方法ないんじゃないかな……。
マストドンのフォローアップ投稿がmisskey.ioでいっぱいブーストされてるの面白いな……（そのぐらいの汎用性はあるけど）
@tyk8417u 購読ではなくフォローにして、地域版のブーストを非表示にすれば良いですよ。
@tyk8417u あ、購読のままでも大丈夫か……。ブーストを拾わないように設定できるので、それで対応しましょう。
@takke @health_2023 Fedibirdには参照という機能がありますが、これは本来の参照機能により指定された投稿だけでなく、本文中に投稿URLが記載されている投稿に対しても働きます。
参照になっている投稿の詳細表示をする際、WebUIやクライアントアプリは、
GET /api/v1/statuses/:id
および
GET /api/v1/statuses/:id/context
というAPIを呼び出します。
前者は投稿そのものの、後者はリプライツリー（スレッド）のデータをまとめて引っ張ってくるAPIですが、参照の場合は後者のAPIが呼ばれた際に参照している投稿のデータもあわせて返します。
Mastodon公式アプリはスレッドを再構築して無関係な投稿を削除してしまうのでスレッドのみが表示されますが、
素直な動作をするWebUIやクライアントアプリでは、スレッドに参照が含まれる表示になります。
※ この追加情報はAPIのオプションで分離することが可能なので、参照部分を識別して特別な表示にすることも可能です。
with_reference=true
をつけると
ancestors, descendants の他に
references が返ります。
@_yayoi ウチでホストしてるPixelfedでFediSnapってのがあるんだけど、
写真上手な人も多いけど、自作イラスト用に使ってたり、飯テロしてる人もいたりで、他と少し雰囲気違うから覗いてみて！
久しぶりに硬い方の 
八ツ橋を食べているのだが（おみやげ）、これも美味しいな……。昔の記憶よりずっと美味しく感じる。
@ponpon_ てげどんっていう鹿児島のインスタンスがあって、もうなくなっちゃったんだけど、そこ出身の人が結構あちこちにいるよ。
学校に通ってて、自分のクラスとか部室いくと、いつもの顔ぶれがいて、なんとなくダベって楽しく過ごせたりするじゃない？
どこかのサーバに属して、ローカルタイムラインでダベってたり耳を澄ませてるのってそういう感じ。
でも、卒業しちゃうと、本当に親しくなった一部の人以外、もう連絡取り合ったり会うこともなくなったりするよね。
同じ進路に進んで、もう少し長く一緒にいる人も少しいるけど。
だいたいはそれでいいんだけどさ。
終わりが突然やってくることもあるから、離ればなれになる前に、お気に入りの人はフォローしておくといいよ。
相手も気に掛けてくれるし、引っ越した時に追従してくれたりするからね。
あとフォローリストは普段からエクスポートしておこうね。
セブンイレブンで売ってる『エリックサウス監修のビリヤニ』、私も食べたので写真のせとくね！
バスマティ米って細長いねえ。良い香り！！ #gochisou_photo
それで、これが辛いと言われてるチキンカレーの方。ごろっとお肉が入ってて、これだけでも美味しいよ！ #gochisou_photo
もう一方は、相対的にとても甘く感じるバターチキンカレー。辛い方を食べてると、この濃厚なバターが救いになるね！ こっちも美味しい！ #gochisou_photo
セブンイレブンの、エリックサウス監修 ビリヤニ を探してる方へ。
店舗の在庫って検索できるんで、調べてから行くといいよ。
セブンイレブンのアプリ、会員登録しなくても検索使えるから、これで商品検索して最寄りの店舗の在庫を調べようね。
@Azukyuda それぜんぶ食べて良いので、フラグたててないでさっさと帰ってきてくださいね！
@Azukyuda ちなみに私は食事制限されてた退院後一発目、ラーメン食べましたw
@dev 更新を受け取り損なったら、24時間後のどこかで必要になったとき再取得する感じですね。
@U_cauda_elongata ちなみにMisskeyもサーバの設定次第で ❤️ とは限りません。
今回Threadsで採用されたことで存在を認知された方も多いと思いますが、MastodonやMisskey、そしてThreadsでは、rel="me" 属性付きの相互リンクという、シンプルかつ強力な本人確認の方法があります。
たとえば、企業やブランドの公式ページ、個人サイトは、その所有者が公式・本人であると判断できますので、
それとSNSのプロフィールを結びつけることで、SNSアカウントが本物であると判断するわけです。
あるいは、アクティブに活動しているSNSアカウントであれば、その活動を普段から見ているフォロワーであれば固有の存在であることを判断できますので、
このSNSアカウントと、別のSNSアカウントを相互リンクして認証することで、ニセモノではないことを判断することができます。
X (formerly Twitter) などが行う特定サービスが管理・認証する仕組みと異なり、単に自分のサーバやアカウントに設定を行うだけで認証が可能です。
各SNSではURLを記述するだけで所定のリンク書式になります。
htmlでは
<link rel="me" href="〜">
あるいは
<a rel="me" href="〜">
と書きます。
https://developer.mozilla.org/ja/docs/Web/HTML/Attributes/rel/me
@dev Misskey側は、rel=meリンクをちゃんと生成します。Misskey上で確認できないのはそうなので、ま、半対応ですね。
@aoetk こちらでアカウント情報を再編集することで、もう一度threadsの情報を見に行ったら認証状態になるかもしれません。
バックグラウンドでワーカーが走りますので、アカウント編集、少し待つ、WebUIをリロード、という流れでどうでしょうか？
開発用サーバで確認しましたが、threadsは認証されました。
@mino90 デバッグがてらいろいろ調べてたけど、いつのまにか認証ついちゃった。うまくいかなかった原因不明。
@ARTi なんか書いてないですね。 /admin/announcements にCRUD各種あります。
@rna Fedibirdでは実際にそういう処理をしているので、できますよ。
@16kz_8s 直す方法は二つありますが、
『削除して下書きに戻す』という機能を使った場合、文字通り、自分のサーバ上で削除して、
つながっているサーバにそれを伝えて削除してもらい、下書きに戻した内容からもう一度投稿する、という動作になります。
『編集』を使った場合、自分のサーバ上で変更履歴を残した上で内容を変更し、ブーストしてくれていた人に変更したよって通知で伝え、
つながっているサーバに伝え、各サーバに内容の変更を依頼します。
ところが、内容の変更を受け付けない（そういう機能がない）サーバもあるため、反映されないことがあります。
古いMastodon（PawooやFedibirdを含む）や、Misskeyの全サーバなどです。
編集は履歴が残り、ブーストした人に変更したことが通知として伝わり、しかも反映されないこともある、など、失敗を隠したい方にはまったくお勧めできないので、削除して下書きに戻すことをお勧めします！w
なんか解説しようと思ったけど、とりあえずコーヒー飲んで、作業を続行しようね、のえるさん。
rel="me"のリンクって、ActivityPubとはは特に関係のない、普通のWeb技術です。
もっと普及させた方が良いと思う。
プロフィールとか自分の活動をまとめるリンクページ作成サービスとかは、まだ未対応だったりするけど、さっさと全力でサポートした方がいいと思うし、
本人証明という意味では、Pixivなんかは真っ先に対応したらいいハズの機能です。
でもPixivは逆に、外部リンクを間接ジャンプページ挟んで認めないぐらいで、まったく対応しようという気配がありません。
本来ならTwitterがそういう役割を果たせば最強だったと思うんですが、まあとにかく外部に送客したくないんだろうけど、閉じこもっちゃって……。情報ハブで勝利してきたのに、完全に捨てましたよね、その立場。
@matsbox 2chとかもそうでしたよね。（いまもそうか）
外部リンクが検索順位に影響するのを避ける意味合いが大きいのかな？（SEO）
どのページから辿ってきたのか隠したいという意図もあると思います（リファラー）
リンク元サイトとリンク先を一体としてみられると困るケースで、ここからは外部サイトだからねっ！ って主張したいっていうのもあるはずです。
そういうこともあって、rel= には nofollow noopener noreferrerなどの指定も存在します。
で、そのやり方をいま再評価すれば、意味ないんじゃない？ という判断もあるはず。
新しいサイトはさっさと導入するけど、古いサイトは昔からのやり方にこだわる、ということにも繋がっていくかな……
@matsbox 2chとかもそうでしたよね。（いまもそうか）
外部リンクが検索順位に影響するのを避ける意味合いが大きいのかな？（SEO）
どのページから辿ってきたのか隠したいという意図もあると思います（リファラー）
リンク元サイトとリンク先を一体としてみられると困るケースで、ここからは外部サイトだからねっ！ って主張したいっていうのもあるはずです。
そういうこともあって、rel= には nofollow noopener noreferrerなどの指定も存在します。
で、そのやり方をいま再評価すれば、意味ないんじゃない？ という判断もあるはず。
新しいサイトはさっさと導入するけど、古いサイトは昔からのやり方にこだわる、ということにも繋がっていくかな……
@kaakaa ご連絡ありがとうございます。登録申請を削除し一通りリセットされていますので、お手数ですが再度登録申請をお願いします。
@kaakaa 登録受理メールが届いていれば完了です。お手数をおかけしました！
クラシックギター素敵だなあ。
QT: https://fedimovie.com/videos/watch/80160397-e95d-40c9-a902-0c236b5d7cc7 [参照]
みんなでわいわいオンラインゲーム最後にやったの、ウルティマオンラインなんだよね。何年前だっけか。懐かしいなぁ。
私も例に漏れず草の根BBSやってたんだけど、INS64 × 4 でアナログ8回線確保してた力押し構成だったんで、メンバーみんなで、テレホーダイタイムからチャットルーム用回線の争奪戦やってたよね。
30分で時間切れになるんだけど、そこからの鬼リダイアルでまたこう……
SYSOPはサーバに直接ログインできるんで優先席。
あと通常接続優先の接続時間の短い回線を一つだけ用意してあったかな。
いやぁ懐かしいね、あの時代。 #fedibird
@donbe1961 最初はNapa Valleyでやってた気がする。日本シャードできたのその辺かぁ。
@kyu3a v4.2からそのへんできるようになるから、もう少し待ってるといいよー
#fedibird Mastodonは、他人のお気に入りは見せないようになっています。リストもそうです。
投稿にお気に入りした人の一覧はとれるので、地道に調べれば……
#fedibird ニフティには、その後インターネットで再構築されたコミュニティの原形は全部あったように思います。
各フォーラムにSIGOPやエキスパート達がいて、頼れる信頼出来る情報源だったなぁ。
@kaakaa 本件、修正入れました。
何かアップロードしないと確認できないかもしれませんが、ご確認よろしくお願いします。
@massa featherの場合、絵文字の一覧の右上にある再読み込みボタンを押して下さい。
@neachi いや、その症状ならリレーの方が死んでるのでは。ちょっと確認してきますー
@zekkainoheso 基本的な心構えとしての脅しで、実際にはかなりの部分はちゃんと消えるんですけど、消えないケースもあるのです。
RT（リノートとかブーストと呼ばれます）は、元のサーバに知らせが来ているので、削除するときにどこに削除を指示すればいいかは把握できています。
たとえば全国各地の図書館・図書コーナーに本を配って、あとで回収になったとして、普通の図書館はちゃんと応じてきっちり処理してくれるけど、たとえば児童館の読み聞かせコーナーだったり、小学校の図書室だったり、いろんなところがあるので、紛失とか対応もれがあって何冊か残っちゃった、みたいな感じです。
@kr96_m まったく同じように使えるわけではないですが、Fedibirdでは参照を使って投稿をまとめたり、
https://fedibird.com/@noellabo/108040360573754014
そのまとめた投稿だけを見せるURLは作れます。
https://fedibird.com/@noellabo/108040360573754014/references [参照]
Twitterという名前が消えてXになったこと、 
青い鳥がいなくなったことは、自分でTwitterを使ったりしない層でも知ってますね。すごいことだ……。
セブンイレブンのエリックサウス監修ビリヤニ、改めて食べるにあたって、しっかり混ぜて食べようかなということで、お皿にうつしてこうなりました。結構な量入っててびっくり。
ちょっと見栄えは良くないかもしれませんが、美味しいので良いのです！ #gochisou_photo
そういえばアナウンス忘れてましたが、FediMovieのPeerTube、v5.2.0に更新して、保存時にエラーが出て連合先に流れない問題が発生していた件も修正しました。
#fedimovie
#fedibird 絵文字ピッカーと、単独絵文字の表示サイズを変更する機能を搭載しました。
なお、単独絵文字というのは、絵文字だけの投稿、絵文字と他の文字や別の絵文字が一行以上離されているものです。
こういうやつです。
設定は、ユーザー設定 / 外観 にある『単独絵文字のサイズ』と『絵文字ピッカーの表示サイズ』です。初期値はスライダー一番左です。
単独絵文字は、右端にすると文字の4倍まで大きくなります。
絵文字ピッカーの方は、まん中ぐらいがバランスいいかな。大きくしすぎてもスクロールが大変です。
いずれも、それなりに大きくすると、これまでよくみえなかった細部が見えるようになります。まぁ、やってみた方がわかりやすいので、一度お試しを。
#fedibird 絵文字の表示サイズを変更する機能で、変更対象になる条件を緩和しました。
段落に絵文字を単独で書くと、一番大きな状態で表示されます。これが従来の動作です。
段落に複数の絵文字を書くと、最大サイズの1/3に拡大されます。この時、空白文字を含んでいても一緒に拡大されます。
段落にハッシュタグやURLなどリンクを含む場合も、最大サイズの1/3に拡大されますが、文字は拡大されません。
段落に文字が含まれる場合、絵文字は拡大されません。
それと、絵文字リアクションで絵文字ピッカーを呼び出す際のアニメーションが速度低下を招いていたため、これを行わないように変更しました。
スマートフォン等で著しく低速になるケースがありましたが、改善するかと思います。
【定期】フォローしている相手が行ったブースト・リノートは、個別に非表示にすることができます。
受け取る情報をうまく取捨選択して、快適なタイムラインを維持してください。
Mastodonの場合は、最初の添付画像のように、相手のアカウントを開いて、縦3点のメニューボタンを開き、『〜さんからのブースを非表示』を選択してください。
Misskeyの場合は、二つ目の添付画像のように、相手のアカウントを開いて、…のメニューボタンを開き、『リノートをミュート』を選択してください。
なお、Misskeyについてはv13.10.0以降に搭載された機能なので、古いバージョンの場合はミュートできません。
