配送前に消すことがMUSTになってるのでC2Sじゃない場合に使われることはないが
リモートから届いた投稿の可視性なんて後から検証できないよなみたいなことを昨日考えてたけど、ActivityPubにはbto/bccなんてめんどくさい仕様もあったんだったってなってる
このアカウントは、notestockで公開設定になっていません。
の投稿
masha_aq@misskey.io
このアカウントは、notestockで公開設定になっていません。
の投稿
2ton@misskey.io
このアカウントは、notestockで公開設定になっていません。
MastodonやMisskeyだけじゃない、Fediverseはもっと広い範囲だよみたいな気持ちがないわけではないのでシェアボタンでFediverseと示すことに少し好感を持つことがないわけではないんですが、ActivityPub C2S でもなく他の標準化された共有プロトコルでもないMastodon固有のシェアページのリンクを示してFediverseとされてると持った好感がそのまま失われてしまう
オーテクの完全ワイヤレスイヤフォンで充電ケースから発煙・焼損のおそれ 「直ちに使用や充電を中止して」 無償交換へ
https://www.itmedia.co.jp/news/articles/2411/15/news174.html
sakiと賭ケグルイとアカギぐらいまでは同ジャンルっぽさがあったけど今はもうそうじゃないだろうし
「雀魂」×「アイドルマスター シャイニーカラーズ」，コラボを11月25日から開催。情報は雀魂の公式Xで公開予定
https://www.4gamer.net/games/456/G045646/20241115012/
このアカウントは、notestockで公開設定になっていません。
TwitterのTL、エロイラストばかり流れてくる状態だったのになんか昨日一昨日辺りから反AIクソツイばっか流れてくるようになっちゃって泣いてる
このアカウントは、notestockで公開設定になっていません。
日本語に翻訳する都合上「馬」と書かれ、映像として起こすためにデザインするときに翻訳の影響を受けて他の特徴を拾い上げられないために現実の馬として描画されてしまった悲しい存在かもしれない
rn> いつも思うのですけれど ファンタジー世界で人間さんが魔法とか行使してるのになんで現実そっくりの馬とかに乗っちゃうのかって
㍂
> Microsoft Visual C++ 2005以降では、既定で`time_t`は`__time64_t`と等しく[11]、32ビットアプリケーションであってもtime_tは64ビット化されるため、古いアプリケーションを新しい処理系およびランタイムで構築し直せば2038年問題を回避できる。
2038年問題 - Wikipedia
https://ja.wikipedia.org/wiki/2038%E5%B9%B4%E5%95%8F%E9%A1%8C#%E5%AF%BE%E7%AD%96
OPFS、Firefoxもサポートしてて最近のストレージAPI事情何もわかってねぇとなってます
EmailのSMTPはIPアドレスを育てるし中央集権型SNSではアカウントを育てるし分散型SNSはサーバーを育てる
一極集中して周りからのインセンティブがなくとも内需だけで回るようになると崩壊するって恐れが常に付き纏うところが玉に瑕ってやつ
ActivityPub は、
> Misbehaving users are banned from instances, and misbehaving instances are cut off from others through “defederation.” This creates some stakes for maintaining good behavior, for users and moderators alike.
ところがいいと思うんよね。ユーザーとモデレーターがそれぞれの層で他のユーザーやモデレーター（サーバ）から評価されて、良い振る舞いをするインセンティブを与えられる。
What’s the Difference Between Mastodon, Bluesky, and Threads? | Electronic Frontier Foundation
https://www.eff.org/deeplinks/2024/06/whats-difference-between-mastodon-bluesky-and-threads
elixirからrubyを見てるのでpolymophicな操作が基本になってる言語がRDBと整合性取るのむずくねー？ってなる
MastodonってLikeを対象以外に転送することがないから別のサーバーから別のサーバーに向けたLikeの処理をする必要ってないはずなんだけどちゃんと集計されるところ不思議だなぁってふと思った
なのでサーバー間の信用問題で実装は分かってるから見えないことを尊重するならやるべきことはあるよねという感じで
確かにinboxに届いてないんだからHTL相当に出てくるのはおかしいんだけどto/cc/audienceに自分が含まれてるなら見えて然るべきなのでそのユーザーのところまで行ったら見えない方が不自然
実装の問題だろってのはそうかもしれないって思ったけどfollowerアドレスのコレクションを向こうが検証できないのにfollowerに入ってないって伝わってないから見えてしかるべきじゃんって実装になるのは当然かもって思い直してる
ドメイン変えてない側が変えた側の新しいユーザーからフォローされてPublicではない投稿を投げるようになったときの問題なのでサーバー間の信用問題
follower only の可視性に対する不信が発生することはあるかもしれないので問題のサーバー管理者ができることはシャットダウン時点のフォローリストを各ユーザーに用意してあげてサーバー側はフォロー関係を全て解除してあげるとかかなという感じ
これで実際に困ること、複数のフォロワーがそこにいて、そのうちの一人だけFollowの投げてきて向こうのユーザーの他はフォローできてると思っててこっちでは全然そんなことないのでフォロー解除を伝える手段がないってことぐらいかしら
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
リレーとか普通のユーザーのフォローで壊れた時にDBで順番に消してUndoを投げて向こうでも整合性とれてること期待しながら直したことはあるけどUndo投げさせるのが面倒にゃんね
Pleromaでフォロー不整合発生した時、following_relationshipsテーブルに追加とかUndo投げるときに Follow activity が多重にあってUndoとかAccept/Rejectが揃ってないと更新まともに動かないっすね
そういうの、要求の中で動作を保証できる最小バージョンでリリースしちゃうかもねみたいな感じになる
そういやOTPリリース版はそろそろOTP25になるんすかね。そろそろOpenSSL 1.1.1に依存してるのつらいんですけど。
