icon

そういえばBridgy Fedの :fediverse::bluesky_butterfly: で、CWがMastodonは展開された状態で反映されるけどMisskeyはそもそもCW投稿は反映されないっぽい話、例えばMastodonユーザーがMisskeyのCW投稿をブーストするとどうなるんだろうな…?

icon

自分でMisskeyアカウントもブリッジして確認してみなよって話なんだけど、あんまり無闇に常駐してないアカウントのブリッジアカウントを作りたくないなっていう。

icon

ゆれゆれ

icon

なんか強くはないんだけどゴゴゴゴゴ……って感じの揺れだったな… :jojo_gogogo:

icon

こちらちょこちょこブーストしていただいてるのでぶら下げて追記しておきますが、CWについてはMisskeyは投稿自体反映されない可能性があります。

ただ、現在のBridgy Fedの仕様としては本文が展開された状態で反映される挙動が正しいようなので、今後いつの間にかMisskeyでも同様になる可能性も念頭に置いておいた方が良いかと思います〜

[参照]

Web site image
投稿の参照(4件) by 月音 (@tukine@fedibird.com)
icon

@ebinir 先日の一時的な不調の影響のようです。キャッシュ削除などで解消する確率が高いのでお試しください :Shiropuyo_Photobomb:
のえるさんの投稿も参照に付けておきます〜 [参照]

Web site image
投稿の参照(1件) by 月音 (@tukine@fedibird.com)
icon

この画像が立ち絵なら、立ち絵のビジュアルは好きな感じだ :Shiropuyo_hohoemi:

2024-10-07 17:43:31 のえるの投稿 noellabo@fedibird.com
icon

Threadsが連合するサーバには条件があって、

そういう情報は基本的にここから辿ればいいんだけど、
threads.net/moderated_servers

Threadsがフェディバースの他のサーバーとの通信をブロックするケースについて
instagram.com/accounts/login/?

理由としては以下の4つ

・Metaのコミュニティガイドライン、Instagram利用規約、またはThreads利用規約に繰り返し違反したか、それらに関して重大な違反があった(管理者またはモデレーターによるものも含む)。

・フェディバースでシェアされたThreadsの情報を削除するようThreadsが利用者に代わってリクエストしたにもかかわらず、そのリクエストを尊重しなかった。

・十分なプライバシーポリシーが定められていない。

・一般にアクセスできるフィードがない。

が条件としてあげられているのね。

で、今回fedibird.comは、

fedibird.com
公開されているフィードがありません

ということで、連合が止まってます。

たぶん、先日のダウンタイムに/publicにつながらなかったからだと思うんだけどね。

Web site image
Moderated Servers • Threads
Attach image
icon

乙女ゲームかとは言ったけど、主人公の性別固定されてないタイプだといいなぁ。
敦との会話を見る限り、どの性別でも違和感ないから期待。

今後太宰とのシーンが来れば分かりやすいだろうから楽しみだ。

icon

私がFediverseに来た頃って、Misskeyの人が「積極的にハッシュタグを使おう!そうすればMisskeyだけじゃなくて広い範囲に投稿を見てもらえるよ!」みたいに声掛けする投稿を結構見かけたんだけど、最近めっきり見なくなっちゃったな。私が見える範囲に無いだけなのか、みんなチャンネルに篭るようになってしまったのか…

2024-10-07 22:13:05 のえるの投稿 noellabo@fedibird.com
icon

えっとね、MastodonやMisskeyのサーバが抱えている投稿のうち、ローカルのものは大事な過去データだけど、リモートから来たものは、単なるキャッシュなのね。一時的なコピー。

私たちがアクセスするときに使うクライアント(Webもアプリも)は常時インターネットにつながっていないから、サーバがキャッシュしていてくれないと自分の時系列順のタイムラインがみられないので、必要なものなんだけどさ。

これ、タイムラインが時系列であることもあって、そんなに何日分も保持してなくたって大丈夫なんだ。

Mastodonの場合、2週間ログインしないとホームタイムラインをリセットする仕様なので、そのギリギリで、遡りで+2週間とすると、まあ30日分ぐらい保持していればいいかな。

古いものは、消しちゃって大丈夫。必要なときはリモートからもらえばいい。

この運用を実際に実践しているのがドン・ゴロツキというMastodonサーバで、MAUが33、まあ20人ぐらいが、日々面白おかしく過ごしてる小さなサーバなんだけど、

もう6年ちょい運用してるけど、データベースの総量は6GB、投稿データであるstatusesテーブルのサイズはたったの714MB。

ストレージ25GBのVPSだけど、これからもやっていける見通しだよ。

icon

というかこの立ち絵の感じだと、Live2Dでアニメーションしたりする!?そうだったらいいな〜!

icon

今日の18時過ぎの投稿がいくつか :bluesky_butterfly: に反映されてないなぁ。一時的エラーだろうか :Shiropuyo_hatena:

icon

ライエモ、間違ってフォロー解除してしまった人をすぐフォローし直したらフォロワー上限のメッセージ出てフォロー出来なかったって人見て、これってリリース当初は上限無くて、どこかのアップデートのタイミングでサイレント実装したのかもな〜。

例えば上限100人だったとして、上限実装前の時点で120人フォロワーがいる人をフォローしていて、間違ってフォロー外したら119人になって上限超えてるから、もうフォローできなくなった、と想像 :blobcat_muzukashi_thinking:

2024-10-07 21:44:35 未来情報産業㈱ 宣伝・広報の投稿 miraicorp@misskey.io
icon

いち早くFediverse​:fediverse:に移住した弊社としては色々と思うところはありますが、この記事にはあまり賛同できませんね。
もちろん
:activitypub:が最高で良いとも思ってはいませんが、AT Protocolの掲げる理想より、ActivityPubのほうがずっと現実的であり場合によっては優れているとも考えています。

この記事で「グローバル検索性」のなさを指摘していますが、本当にそれが必要なのか、それを実現した
:unicode_1d54f_bg_black:での悲劇などを考える必要があるでしょう。

1に、これを実現するためには全ての投稿を一箇所に集める必要があり、それは検閲に繋がります。ActivityPubは、検閲できないようにするため、あえてグローバル検索を犠牲にしたんだと思います。機能が劣るのではなく、そういう設計思想、割り切りだと思います。

2に、結果としてActivityPubでは、ブースト・RNで範囲は拡大されますが基本的には投稿が届く先はフォローで繋がっている先までに限られます。
このため縁もゆかりも無いところにはあまり届かないので、あらぬところから唐突に反抗的なメンションが来たりする可能性も少なく済み、棲み分けで平和に暮らすことができると思います。
:unicode_1d54f_bg_black:では意図しない先にまで届いてしまうグローバル検索性があるため、マウントを取ろうとする人の登場など日常茶飯事でした。

RE:
https://misskey.flowers/notes/9z2jht3d4dyq0ef5

Web site image
あまさとしおん(Bridgy Fed接続中) (@ShionAmasato)