Rust、read_exact しようとすると Vec を一旦何かで初期化する必要があり、capacityだけでなんとかなりませんか？という顔に
Rust、read_exact しようとすると Vec を一旦何かで初期化する必要があり、capacityだけでなんとかなりませんか？という顔に
`Vec::spare_capacity_mut`と`Read::read_buf`をベースに安全で効率的な抽象化を作れそうな予感はあるけど、かといって自前で`unsafe`を書くのも書くのも微妙だし、その上`read_buf`はまだ不安定なので、`std`で出来合いの実装が提供されると嬉しそう
Xのリンクサービス（https://t.co/）について
https://help.twitter.com/ja/using-x/url-shortener
ユーザーの投稿するコンテンツ（UGC）中の外部リンクの扱いは確かに面倒なシロモノで、かつてCGI掲示板を各自が設置していたときも、一律禁止にしたり、特定アドレスを弾いたりする処理を入れていたことを思い出すね。SEO目的の被リンク稼ぎでスパムだらけになったのがつらかった。利用者としては、ttp://で張っていた。
＼(^o^)／
でも、短縮URLである必要ないしなぁ。文字数も実際には無関係（URLの文字数カウント一律）だし、弾きたいURLだって直接処理すればいい。なんなら短縮URLより柔軟に処理できる。
結局、クリック回数数える介入と、都合の悪い外部の存在を排除するために使われてしまっている。
t.coはXと共に滅んでも差し支えないかもしれないけど、仲介する仕組みが機能しなくなるとURLが無効になるリスクもあるし、ユーザーもユーザーをアシストするプロセスもリンク先の事前判断ができないし、デメリットが多すぎる。
本筋とあまり関係ないけど、旧TwitterにおけるURLの文字数のカウントってt.coの桁数と連動していなかったっけ？
Counting characters | Docs | Twitter Developer Platform
https://developer.twitter.com/en/docs/counting-characters
> All URLs are wrapped in t.co links. This means a URL’s length is defined by the `transformedURLLength` parameter in the twitter-text configuration file.
Twitter [sic] Developer Platform (?)
#fedibird #fedibird_info なおFedibirdでは、ローカルユーザーが投稿した場合、プレビューカードは遅延させずその場で生成するようになっています。
リダイレクトするリンクは、特にプレビューカードにおいて、プレビュー時と異なるリンク先に誘導する悪意あるものがでてきており、プレビュー時に解決したURLをそのまま保存してそちらに飛ばすようにしてあります。
通常のリンクにおいても、主に短縮URLがそうですが、実際の飛び先を事前判断できないこと、リダイレクト時にアクセス解析などが挟まることから、同様の処理を入れるようにしてあります。
X (formerly Twitter)で実際にありましたが、短縮URLの胴元による、リダイレクトの解決を遅延させるという嫌がらせまで仕込まれていたこともあります。
URL短縮サービスによる悪意への対策として投稿されたURLのリダイレクト先を保存しておくというのは理解できるけど、PURLなどの場合はリダイレクトを解決されると意義が薄れてしまうよなあという気持ちもある
まあPURLとか気にするようなオタクならそのあたりを自分で制御できるサーバを建てるのが筋だろうし、一般的なレベルの情報リテラシーの利用者を想定した寄り合い所帯としては予防策として適当でしょうね
かつてTwitterだった場所がx.gdまみれになってしまって悲しいですよ、私は（？）
いや、x.gdという特定のサービスに対して特に文句があるというわけではなくて、一般に短縮URLが濫用されてしまうような状況が不健全であるという話なのだけど
RFC 7033 - WebFinger
https://datatracker.ietf.org/doc/html/rfc7033#section-4.2
> A WebFinger resource MAY redirect the client; if it does, the redirection MUST only be to an "https" URI and the client MUST perform certificate validation again when redirected.
リダイレクト時に証明書の検証をしろとわざわざ要求しているの、ひいき目に見てもWebFingerプロトコルの領分ではないし、接続の再利用などを考えると実際のところ怪しい記述な気がするのだよなあ
他にも4.1.節ではリクエストのURLのクエリ部分を作る方法について、パラメタの名前と値をパーセントエンコードして`=`でつなげてさらにパラメタ間を`&`でつなげて……などと1段落かけて`x-www-form-urlencoded`の再発明をしているし（これに関してはWHATWGのURL Standardへの参照を避けたいからとか？）、4.2.節ではエラーの場合においてもnon-secureなHTTPで再試行してはならない（MUST）などと要求している（TLSへの執着が激しいな）
それでいて、JRD文書の`subject`がリクエストの`resource`と異なる場合にクライアントが行うべき処理のような重要なケースについての記述が抜けているという。この場合は新たな`subject`を`resource`としてWebFingerクエリを再試行するのが一般的なのだけど、それはあくまで実装が気を利かせて勝手にやっているだけであって、規格として定められたわけではないっぽいのが困りどころである（これが規格に明記されていたら`subject`をカノニカル化しない実装に対してその旨を堂々と指摘できて話が楽だっただろうに）
こうしてMisskeyユーザは`threads.net`の代わりに`www.threads.net'を目にすることになったというわけです（？）
QT: https://fedibird.com/@tesaguri/111646377615491667 [参照]
まあMisskeyについては<https://github.com/misskey-dev/misskey/issues/7922>の"wontfix"ラベルが外されているから、対応する気がないわけではないのだろうけど
WebFingerのクライアントライブラリみたいなのはないこともないけど、少なくとも私が探した時点ではどれもリソースを取得してJRDをデシリアライズする薄いラッパといった感じで、このあたりの処理を扱っているものはなかったと記憶している。まあ難しい処理でもないから必要なら自分で書けば良いわけだけど（一応多少のセキュリティ上の配慮が求められる処理ではあるけど）
（いや、その多少のセキュリティ上の配慮のせいで真面目にやろうとするとそこそこのテストコードが必要になるわけだけど）
一般論として、ユーザの制御の及ばないところで`hyper`やら`reqwest`やらのクライアントを生成するライブラリは使うのに気が引けるところがある。これをされると例えばせっかくアプリケーション側で持っているコネクションプールを利用できないし、証明書だのプロクシだのの細かい設定も反映させられない
このアカウントは、notestockで公開設定になっていません。
#53 - Fediverse Unicode Emoji - fediverse/fediverse-ideas - Codeberg.org
https://codeberg.org/fediverse/fediverse-ideas/issues/53
Guidelines for Submitting Unicode® Emoji Proposals
https://unicode.org/emoji/proposals.html
Unicodeが絵文字の追加の提案を受け付けているということを初めて知った
例えば「（電子）メール」の概念を封書のイラスト（✉️）象徴できるように、"social media"という概念を象徴できる都合の良い記号があれば良かったのだろうけど、「（SocialHubコミュニティが規定するところの？）Fediverseのロゴ」はそのような汎用性を有しているのかしらね