activitypieces 立てて、青空への投稿 piece 作っても良かったんだけど、まあ code 書ける人は client 叩くのを systemd-timer 登録すればいいだけだしな感はやっぱあるよな
activitypieces 立てて、青空への投稿 piece 作っても良かったんだけど、まあ code 書ける人は client 叩くのを systemd-timer 登録すればいいだけだしな感はやっぱあるよな
Rust で Bluesky に投稿するなどした (まだ色々実験段階)
https://github.com/mizunashi-mana/mstdn-rss2bsky-post
というか、そういう方向に Google とかは舵を切り始めてる感がある
そもそも、nginx とかの大手 Web サーバが証明書をファイルから読み取って reload しないと再読み込みしないのが全ての元凶だが、証明書如きを一々ファイルで管理して設定として指定する必要はないので、証明書配布の方のプロトコルが標準化されて、それに大手の Web サーバが対応し、配布サーバのデファクト実装が爆誕すれば、かなり時代が変わるんじゃないかとは思っている
ただ、現状その普及に足りないものがあると思っていて、それは証明書の配布システム。ACME ネイティブな Web サーバはいくつかあるけど、多分実用的に必要なのはそれではなくて、ACME CA からの証明書取得と CRL 参照の一元化、そして証明書の配布なんだよな
ACME x short-lived certificates 標準の時代は近いうちに来ると思っていて、というか既にきているところはあると思うが、そんな時代を到来させてくれた Let's Encrypt の功績はやっぱ大きいよな
CA の安定性が気になるので証明書の有効期間ある程度長くしときたい人は、そういう CA 利用すればいいので
ただ、現状必須なのは微妙で、CA の SLA に合わせて OCSP を option にするのは昨今の事情鑑みると普通に賛成だな
証明書の lifetime 短くする場合の問題点が、CA の安定性をどれぐらい信用していいかにあるというのはまあそうですね
Let's Encrypt は安定してると思うけど、ZeroSSL はタイムアウトになってる感触があったかな……まぁ、90 日の証明書でも 60 日経過で更新するので 30 日の猶予があるとか、そういう状態なので、通常は気にせず、たま～に証明書が更新されているのを確認すれば良いのですが。
RE: https://mstdn.mizunashi.work/users/mizunashi_mana/statuses/110480311817709008
daily で有効期限が切れる証明書のために daily で OCSP stapling とるの馬鹿らしいのはそうだし、そのために OCSP responder 実装するのも馬鹿らしいというのもそう
これな。ACME level で証明書発行自動化されて、十分証明書の lifetime 短くなれば、明示的な失効なんていらないんだよなあ (いやまあ完全にいらないかは微妙なとこではあるけど)
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
なぜか発信力が高いと就職に有利っぽいが、なぜそれが採用の指標になってるのかよく分からん
僕は世の中にまともな情報がない部分については自分用に記事書いてるが、まともな情報あるならそっちを参照すればいいのでいまいち記事書くモチベが起きないし、記事書いたところでなあ感がある
なんか最近技術記事書こうぜみたいな風潮があるっぽいが、技術記事を書くことにより失う時間に対して、記事を書いて発信することが何かメリットがあるかと言われるとうーんという感じがある
そう考えると、めちゃくちゃアウトプットしてる気になってくるな。発信力めっちゃあります！（）
マストドンはマイクロブログなので、そこで技術的なことを呟けば、技術記事が一つ完成するってわけ
handle を custom domain にすることが推奨されてるが、custom domain を使ってるか確認する方法はないので、custom domain 使うとむしろ偽装がしやすくなる (*.bsky.social の方の handle が空くので)
青空、割と簡単に偽装アカウント作れる割に本人認証の仕組みがないのか
AT Protocol (BlueSky Social)仕様解説 ～ W3C DID仕様を添えて ～ https://qiita.com/gpsnmeajp/items/eb665d639f088b85454e #Qiita Seg_Faulより #miteru
いや、個人情報保護法に照らし合わせれば当たり前の勧告ではあるし、被害も実際出てるが
> 利用目的の通知等
> 利用者及び利用者以外の者を本人とする個人情報の利用目的について、日本語を用いて、利用者及び利用者以外の個人の双方に対して通知し又は公表すること。
厳しそう
> 機械学習のために情報を収集することに関して、以下の４点を実施すること。
> ① 収集する情報に要配慮個人情報が含まれないよう必要な取組を行うこと。
> ② 情報の収集後できる限り即時に、収集した情報に含まれ得る要配慮個人情報をできる限り減少させるための措置を講ずること。
> ...
そんなことが可能なのか？
個人情報保護委員会から、生成 AI 使用ユーザへの注意喚起と、OpenAI への行政指導情報がでとる | 生成AIサービスの利用に関する注意喚起等について
https://www.ppc.go.jp/news/press/2023/230602kouhou/
notestock のワードクラウド、チューニングがイマイチ感があるな | notestockでワードクラウドを作成しました！ https://notestock.osa-p.net/wordcloud.html?uuid=6c91378e2e1d4da0bce59c46f288ba40
Cloudflare 様と Google 様には個人的なインターネットインフラを色々握られてる
ただ、まあビジネスモデルどう作ってくのかは分からんが
青空は、ちゃんと招待コードをユーザに発行して、SNS の入り口をソーシャルのつながりから作り、リコメンド利かしてつながり増やす導線も作り、かつクローズドである程度フィードバックもらいつつ期待値コントロールしてるところがマストドンよりちゃんとビジネス戦略考えてそうで好印象だな
まあ、もちろんユーザはビジネスのことは考えてくれないので、ビジネスはうまく考える必要があるが
ユーザにアイデアもらいつつ、高い品質のものを運営側からも提供するスタイルの方が発展性あると思うんだよな。その点が ActivityPub / ATProtocol の他ビジネス SNS に比べての魅力だよな
このアカウントは、notestockで公開設定になっていません。
青空の custom feed 機能おもろいな。これは欲しいやつやん
しかし、やっぱ青空はマストドンより発展途上って感じだな
青空 -> マストドンは、現状青空側が closed なのでやめとくか
じゃあ、マストドン -> ブルスコは RSS 経由で良いか
Mastodon は RSS feed 標準対応なのか。流石やな
https://mstdn.mizunashi.work/@mizunashi_mana.rss
Bluesky、リコメンド周りはマストドンに比べてしっかりしてそう。流石ビジネス目指してる人たちがやってるだけはある
うちのドメイン使うように変えた
https://bsky.app/profile/social.mizunashi.work
ActivityPub にはいないが青空にはいる人も結構いるんだな
