たぴおか

残り参事官は絶対嘘

.

アップデート1GBはつらい

なでなで

.

@mei23@misskey.m544.net わー

nothingness

@mei23@misskey.m544.net もしくはここを false にしておくと起動したときにデータベースとスキーマの同期が行われなくなるので、配列が初期化されることがなくなるかも
https://github.com/syuilo/misskey/blob/pg/src/db/postgre.ts#L93

@mei23@misskey.m544.net プロセス再起動したらそのたびに手動でデータベースを初期化するか、ここを強制的に true にしておくと自動で初期化してくれるかもしれない
https://github.com/syuilo/misskey/blob/pg/src/db/postgre.ts#L94

@foxhkron@cybre.club @succfemboi@iscute.moe That image is a joke. Misskey will continue to use Node.js.

プログラミング得意でないし好きじゃないのでRustのようないかにもプログラミング言語みたいなのは扱えなさそう

deno普及するのかな～～～

名だたるメンバーが

なんかMisskeyそのうちこうなりそう

うーんあんまつよく感じない

☔

地獄

めいめいに送金する方法募集中

@mei23@misskey.m544.net TypeORMのバグで、Misskeyプロセスを起動するたびにデータベースの配列型カラムの内容が初期化される問題があるけどそれに関係してそうな気がする

@ai 起きろコラ

11のリリースはまだまだ先

まだ 10.x のリリースは続くと思うのでそのままで

マージするぞ

v11大丈夫そうかな

藍たそのお賃金が支払われるまでお待ちください

This account is not set to public on notestock.

死じゃん

かわいい

村上カーで妨害

許せん

草

散歩

なんとなく相手はMisskeyじゃないと思った

そのインスタンスのユーザーページにいきリモートフォローボタンを押す

あれ、秘密にするんじゃなかった？

RE: https://misskey.xyz/notes/5ca2c3a40c61030032c39706

よう of the おは

アプリがあるサービスのIDの生成方式について感知してそれに依存するプログラム書くのはどうなんだろうというのがある

@mei23@misskey.m544.net それは今でもあるしね

@mei23@misskey.m544.net それこそ createdAt の出番ではない？

@mei23@misskey.m544.net 10から移行するインスタンスはほぼみんなObjectID方式に切り替えると思う 新しく作られるインスタンスでだけ新しい生成方式が使われそう
misskeyのIDは「文字列であり、アルファベット順で大小の比較可能である」という共通する点だけを仕様とすればサードパーティアプリでも問題ないと思う
現時点でMisskeyのIDがObjectIDであるという前提でプログラムしてるアプリってなさそうな気がするので

@mei23@misskey.m544.net オプションで切り替えられる案ダメ？複雑にはならないし手間もかからないと思うけど

記憶にある限りではりんすきはこんな感じだった

@mei23@misskey.m544.net ひーっ

@mei23@misskey.m544.net 長さが...

設定ファイルで legacyId とかを有効にするとObjectIDで生成されるようになる
ObjectIDも時刻順でソート可能なのでプログラムの動作に影響することは無いはず

なんで

インスタンスごとにIDの生成方式を設定できるようにすれば解決する

@mei23@misskey.m544.net できれば36文字フルに使いたいと思ってた

おなかいたい

ぱそこんでテレビ録画できるんだね

https://misskey.xyz/notes/5ca255860c61030032c16eb7

これ買おうかな～～～
https://lilium.bandcamp.com/album/krazy-psycho-bass-3

IDは何かと目にする機会が多い(URLだったりデバッグだったり)ので極力短い方が良いというのもある

Misskey v11独自のID生成方式は 2089年 まで使える

MongoじゃないのにObjectId使い続けるのはなんか気に入らない

よしよし

ulidなどの生成方式だとミリ秒単位が同じでもそれに加えランダムなノイズが加えられているのでそれぞれ区別できる

ミリ秒単位で同じ時刻の投稿がある場合がある

created_at だとページネーションができない

リモートの古い投稿がタイムラインの先頭に来てしまう問題を解決するためだね

snowflake id を導入しろというIssueがあったので

created_at と id は同義になる(idにはcreated_atが埋め込まれる)

ulidを元にしたようなデザインで、時刻情報が埋め込まれてアルファベット順にソート可能な独自のID生成方式にする

最近の高解像度化したディスプレイでは、フラットなデザイン(ベクターなデザイン)でないとぼやけてしまう

こう考えるとフラットデザインは流行りではなく必然ということがよくわかる

様々なSQLに登場するので一箇所にまとめるのはきつそう

つまり、以降ユーザーは送信時やリプライ先として明示するときにも旧IDを使う必要が出てきて、あっちこっちで永遠に新旧分岐をすることになっちゃうわ

その案は却下された
https://misskey.xyz/notes/5ca1974af6ef6b0039ec84e4

アイライニャー

高解像スクショやめれ

チーズとフランスパンの相性は抜群だな～

おおん

This account is not set to public on notestock.

村上さん様

菅官房長官可愛いわかる

なでなで

@mei23@misskey.m544.net 運営者的にはこの3択かしら
* マイグレしない
* マイグレする(federation無し)
* マイグレ+ドメイン変更する(federation有り)

@mei23@misskey.m544.net マイグレかつドメイン変更すればなんとか...

かわいい

気にしないで

IDは引き継がない方針にするか
マイグレは書くけどその場合リモートのフォロー関係はリセットされる

https://github.com/syuilo/misskey/blob/develop/src/misc/reaction-lib.ts#L6-L15

設定ファイルが間違ってそう

#元号は変わったがあなたはどうなるのか

Android持ってない＞＜

me

かわいい

もうマイグレは無理ですっ！って言えば全てが解決するんだけどなぁ

@mei23@misskey.m544.net そこも含めて考え中

TODO
* IDの仕様を確定させる
* リプライの仕様を確定させる
* テストする
* マイグレーション書く
* 破壊的変更などのドキュメントを書く
* リリースする
* マイグレする
* ✌️(´･_･`)✌️

巻きだくら

途中@aqzくんにスニッカーズ差し入れしてもらったりして概ね順調に開発は進んだ

テストとマイグレーションは面倒なので「だけ」という表現はアレだな

Misskey v11本体の開発作業はほとんど終わってて、あとはテストとマイグレーション書くだけ

よくばり

まこちゃんください

あと最近は長期開発によりデータベース上のスキーマが一致しないことが多くなってきて、それによってプログラムの書き方を少しトリッキーにしなければならず生産性が低下してきていた
そこでリレーショナルデータベースにしてスキーマをきっちり定義しなおして自然にプログラムを書けるようにしたいという思いがあった

あるコミットでObjectIDに起因する問題が露呈し、あーーーーーもうこうなったらPostgreSQLにしてやる となった

MisskeyをPostgreSQLにしようと思ったきっかけは、かねてから村上さん(や他の運営者)に圧力をかけられていた村上さんの運営の負担を少しでも減らしたいと思っていたのと、あるコミットでObjectIDの扱いが面倒だというのを再認識したのが決定的だった

Misskey v11で不具合がないかテストしてくれる方募集中
私はそのうちオンラインでv11のテストサーバー建てる予定だけど

meitter.net

@mei23@misskey.m544.net めいったーにしようぜ

適当に
リクエストくれたら撮影するけど

高画質でいろいろあるよ

公式イラストのやつ？