`bsky.app`のURLを踏まずにPDSを直接読む縛りをしているのだけど(?)、`app.bsky.feed.post`のレコードは自己に対するリプライへの参照を持たないので、スレッドすらろくに読めない。`app.bsky.feed.getPostThread`を実装してください(?)
`bsky.app`のURLを踏まずにPDSを直接読む縛りをしているのだけど(?)、`app.bsky.feed.post`のレコードは自己に対するリプライへの参照を持たないので、スレッドすらろくに読めない。`app.bsky.feed.getPostThread`を実装してください(?)
`bsky.app`とかは今のところそれ単体のみから`at:` URIを再構築できる形式のURLだから良いけど、`whtwnd.com`はrkeyでなく`title`しか含んでいないこともあるので困る(何が?)
This account is not set to public on notestock.
分散システムのサービスとしてのBlueskyに対する評価としてはこんなところだよね(スレッドの方は未読)。というか"decentralized"という自称が無用な幻想と失望を招きすぎている
これはBlueskyが"decentralized"という形容をPDSレイヤーに限定せずに用いているのが悪いのだけど、FediverseにおけるBluesky批判の多くがBluesky側のビジョンについてそれに同意するしない以前に議論ために最低限必要な理解もそこそこに「分散していない」の一点の批判に終始しがちだし、擁護者も「Blueskyは分散している」という雑な主張で返してグダグダになりがちという感想
まあもちろん細かい点で共感できない部分もあるけど。例えば自分で鍵を管理していないユーザを保護できていないことについての批判は流石に酷なように思う。
個人的にはまずはやる気があるユーザが現実的なコストで自分のデータを確保できることが重要かなと
まあこれについてもMatrixのようにもっとユーザフレンドリーながらサーバを信用しない鍵管理とかも考えられるのかも知れないけど。いや、Matrixが実際に何をしているのかは正直一切把握していないですけど……(?)。
あと詳しくはないけど、これも実際恐らく真なのだよな:
> And *even if* Bluesky delegates authority to that user to control their identity information in the future, there is still a problem in that Bluesky will *always* have control over that user's key, and thus their identity future.
"72hr window"とかもPLCサーバ自体が敵対的なら恐らくどうとでもできる程度のものだろうし(<https://web.plc.directory/spec/v0.1/did-plc>の"PLC Server Trust Model"節を参照)
あとハンドルシステムが無意味かのような評価も過剰かなと。以前に解決したことのあるハンドルについてはその"DID"との対応の変遷はクライアントが記録を付けておけば良い話だし(新規の解決はまた別問題だけど)、現実的にそのような運用を可能とするだけの枠組みは提供されているように見える。
Petnameシステムについてはこの記事で初めて名前を目にしたくらいなので、それとの比較でどうなのかについては何も言えないけど
あとこれは純粋にPDSとそのホストするユーザのハンドルの関係を勘違いしていそうな雰囲気がある
> Most users are mapped to domains controlled as `*.bsky.app` [sic] subdomains, so Bluesky can remap those to different users, and this will be true with any "Personal Data Store" [sic] provider one might use too
しかしLemmer-Webber氏もFediverseにアカウントを持っていらしたんだな。
当たり前だろ、どなただと心得ている。すみません(?)