このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
Mastodon 4.2.4 の app/lib/request.rb の timeout指定 https://github.com/mastodon/mastodon/blob/v4.2.4/app/lib/request.rb#L69 はちょっと変えて様子見するかな。日本と海外の間でconnect 5秒 read 10秒制限は短い過ぎる
https://mastodont.cat/@versions/109757045251123540 を棒グラフに。そろそろ3.5未満の対応を捨ててもいい？
複数のアカウントを誰にもバレないように使い分けたい場合、まずサーバから分けておけという話になるか
「IPアドレスでも分かるじゃないか」は「アカウント切り替え時にVPNも切り替える」などユーザ側の対策があるが、それをしていた場合でもプッシュ購読エンドポイントURLに埋め込まれたパラメータによって努力が無駄になるかもしれない、ということだ
URL中に情報を入れてDBなしで中継できることの方が、彼らにとっては素晴らしく思えたらしい。
まあ俺も別件でこないだDB飛ばしたので気持ちは分かる
マストドン公式アプリの通知中継サーバはデバイストークンを漏らす。このトークンは１アプリに１個なので、悪い鯖の管理者が照合すると複数アカウントのユーザが同じだということを検出できてしまう。
STのアプリサーバはnode.js だったが、今回はKotlinでKtor (Server,Client), Exposed, HikariCP という構成。やはり書きやすいわ… https://github.com/tateisu/ProtPushProxy/blob/main/AppServer/src/main/kotlin/Main.kt
端末側で鍵生成とプッシュメッセージの暗号解除をやる部分。 https://github.com/tateisu/ProtPushProxy/blob/main/PushReceiverApp/app/src/androidTest/java/jp/juggler/pushreceiverapp/WebPushCryptTest.kt
マストドンにアカウント登録してプッシュ通知を受け取って表示するだけのプロトタイプを書いてる。受信時にAPIアクセスしない。Unified Push対応。複数アカウント対応。Androidアプリ側でWebPushのデコードやるのマジ面倒だった
#SubwayTooter 5.511 https://github.com/tateisu/SubwayTooter/releases/tag/v5.511 is now on pre-release state. v5.510 is now on production state.
Android gradle plugin 7.4.0 はバグいな…。リリースビルドで謎エラーおおめ
@highemerly Linkヘッダが複数ある場合にそのうち１つしか読んでなかった、という問題がありました。なおします。
@highemerly アカウントは審査待ちになりました。よろしければ承認してください。
@highemerly リストの終端とでるのは「次回どこから読むか」を見失った場合、マストドンでいうとLinkヘッダーに次回どこから読むかの情報がない場合です。とりあえずそのサーバにアカウント作って試してみますか…
給与の支払いをデジタルマネーにする前に、税金の支払いをデジタルマネーで出来るようにしろよ
P2PでSNSというやつはモデレーションがないので、それよりは多少マシと言える
鯖缶にしてみれば外部から削除依頼が来ても「サーバにはデータを保存してないしクライアントにデータ削除を強制する方法もない」ので全く対応しないできないことになる。よって管理は楽だ。 モデレーションもチャンネルオペレータ任せ。
IRCなんてサーバ上ではデータはディスクに保存されないんだぜ。だからクライアント側がログをとるので、むしろ上流から削除を強制する方法がない。
Chromiumはオープンだけど、Google APIのいくつかはオープンではない。Chromum派生ブラウザではこれまではAPIキーが提供されてアクセスが許されていたが、今後は使えなくなる。
…これに関してはダブスタとか邪悪とかの感想は出てこないなあ。何が邪悪なの？
@Cutls STはPlayストアに対して「PlayストアにあるChromeとほぼ同様です」という論法で通してるけど、MSのはEdgeがストアにはないんだっけか
@Cutls 自由なSNSは子供にはまだ早すぎる、とMSが考えるのは理解できなくもない。実際、子供向けとは言い難い
Mastodonの時に「複数のサーバにアカウントを作って相互フォローすることで自分の投稿が広範囲に流れるようにする」とかする人が結構いたけど、#Lemmy ではフォローするのはユーザではなくコミュニティになる。lemmy.juggler.jpにも海外からそんな人が来てコミュニティを拡散させようとしていた。
テストサーバに政治的なコミュニティを宣伝されるのは割と困るのでモデレーションした。モデレーション記録は公開されるhttps://lemmy.juggler.jp/modlog
https://lemmy2.juggler.jp/ を建てて連合機能の動作確認を行った。 うまく連合できてれば投稿の作成と編集、コメントの作成と編集、voteの変化は自動的に伝達されて ブラウザにもWebSocketでリアルタイムに反映されるんだな。 #lemmy
#Hexo のdb.jsonを読んでblog記事のURLとタイトルを #Lemmy に投稿するコード https://lemmy.juggler.jp/post/186
Kotlinで雑に書いた。エンティティとかなんも考えずにJSONベタに扱うけど、一応動く。
今日も麻婆豆腐を作るよ。ひき肉をふわふわにしたくて、炒めるんじゃなくてそぼろっぽく炊いたのを入れてみたら、甘すぎた。加減が難しいな
もし観光地が温泉の看板で埋め尽くされたら、それは観光地ではなくなってしまう。
またリーチしてないけども確率的に興味を持ちやすい対象に向けて広告を出すべきで、全員がそれに興味を持つ訳でもないのもまあ当然。観光地に温泉の看板があるのと変わらない。
問題は存在するかどうかじゃなくて、どの程度邪魔になるか。この点で今のモバイル広告は本当に酷い
このアカウントは、notestockで公開設定になっていません。
コンテンツにマッチした広告だと新規顧客の開拓にならないのでは…。
なろう小説にソシャゲの広告が出るとかの方が適切な例だと思う。客層だけマッチ。
https://github.com/tootsuite/mastodon/blob/b9d74d407673a6dbdc87c3310618b22c85358c85/app/javascript/mastodon/reducers/announcements.js#L64 うへ、JVMのPODでもコレやるのか…
starts_at > ends_at の時は webUIは告知をフィルタしない。
長い告知を作るとWebUIはうまく機能しません。この領域は上下にスクロールせず、告知を左右に切り替えるボタンもスマホUIでは投稿ボタンも表示されません。
WebUIをリロードした時に告知の表示順が変わることがあります。ストリーミングで受け取った告知は常に先頭に表示されますが、REST APIで受け取った告知をソートする時はイベント時刻がないものはリストの終端に表示されます。そういうものらしい。
API応答から見るにアナウンス表示はこの程度はテストした方がよさそう。 メンションの2つめは外部のアカウント。
改造系の人たちはAnnouncements にも profile_emojis つけたりするの？
ああ…Android Studioのビルド終了時に #巻乃もなか の声を出せるようにIDEプラグイン書いてよかった。癒される…。
all_day がtrue だと starts_at ,ends_at は "2020-01-28T23:59:00.000Z" のようなUTCタイムゾーンのタイムスタンプを返す。当然だが日本時刻の0時ではない。
また、scheduled_atやイベント期間をチェックしてpublishedフラグを変更したりストリーミングしたりするワーカーは5分おきに動作するそうです。編集したら5分待つ。
告知の管理者UI、オイゲンさんの認識では日時は全てUTCだそうです。そしてscheduled_at(UTC)がくるまで announcements.publiched=falseでAPI応答に含まれません。scheduled_atを日本時間で書くと期待通りには動作しません。
app/javascript/mastodon/actions/streaming.js
case 'announcement':
dispatch(updateAnnouncements(JSON.parse(data.payload)));
case 'announcement.reaction':
dispatch(updateAnnouncementsReaction(JSON.parse(data.payload)));
ストリーミングの関係でホームカラムに置く、1行表示と拡大表示を切り替えられるようにする、くらいが落としどころか
@Gargron @dgold @lain @shadowfacts
However, in reality, there are only two options: "Pleroma withdraws breaking ID modification" or "support for Pleroma ID by application developer (who not saying support for Pleroma)"
If they keep singing "Mastodon API compatible" without retracting anything, that would be bad news for app developers.
@dgold @lain @shadowfacts @Gargron
As already mentioned by Gargron in this conversation, the Mastodon API is not intended to be used throughout Federation. Mastodon 's ecosystem does not have to take care of changes made by Pleroma.
@dgold @lain @shadowfacts @Gargron
The Mastodon API document is not intended to create compatible APIs. It is intended to create an application using Mastodon's API.
After seeing your(s) point of view, I felt "part of the information necessary for creating the application is undocumented", so I provided a short 1-line PR.
I just revealed the undocumented part, so I think that there are no Mastodon applications whose implementation will be changed by this PR.
@dgold @lain @miya @charlag @WAHa_06x36 @tootapp @shadowfacts @Gargron You should not use the API document as a disclaimer to force app developers to respond.
The API document is originally intended to make an application using the API. We do not generate IDs by the application, so it usually is not necessary to describe how the ID should be generated.
一回目の乾燥が終わったのでコインランドリーと自宅を2往復して追加2回分の乾燥をしかけてきた。今着てる服の洗濯があるから、また明日もやる
MFMで一番ヤバいと思うのは打ち消し線が連合に流れないこと。文意が伝わらなくなる
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
コインランドリーに来た。海外メーカーの乾燥機だ。温度調節機能はなかったが、張り紙に80度とあり期待できる。肌着と手袋を回してみて30分。手袋の中が70度以上になっているのを温度計で確認した。これなら長時間回せば衛生的に大丈夫そう
@sakko2005 ネットで議論して何かが変わるかというと、変わらない事の方がおおいですからね…。
https://github.com/syuilo/misskey/commit/4b191c7f68a13e1a9acb00b8b8c1b7638465f5f5 Misskey のMFM はコードの強調や数式の表示を外部のJavaScriptライブラリに依存するので、JavaScriptではない処理系で再現するのは労力的に難しいな。妥協が必要だ
@valerauko IDの発行なんて普通のAPI利用者はしないわけですよ。サーバが発行したIDを使う。IDの発行に必要な定義がアプリ開発者向けのAPIドキュメントにないからといって「仕様がおかしい」というのは変です。
@valerauko 今回の話だと「互換APIを作りたい」人の調査不足が主な理由でしょう。想定されてない使い方に対して「仕様がまとまってないのが悪い」は筋がおかしい
@valerauko まずAPIを作ってるのは俺ではないので、そうですか、としか…。
@valerauko 誰がそのコストを払うの、という話です。特にAPIドキュメントの更新は外野からのPRが主です。
@valerauko 狂信者と呼ぶ理由は、Pleromaの作者がトラブルを認めてるのにまだ古い論点で粘ってるユーザがいるからだよ
@miya @charlag @lain @Gargron @tootapp I wrote PR for mastodon API document and it's merged. https://source.joinmastodon.org/mastodon/docs/merge_requests/18/diffs now API document says ID is string representation of 64 bit integer and comparing order is numeric.
@valerauko 事前にアプリ開発者と協調してればこうはならなかったよ。あと繰り返すけどドキュメントは仕様ではない。 まあさっき仕様に明記するPRかいて通ったので、IDの扱いに関する議論はもう出ないけども。 https://source.joinmastodon.org/mastodon/docs/merge_requests/18/diffs
マストドンのAPIドキュメントに1行だけのPRを投げた https://source.joinmastodon.org/mastodon/docs/merge_requests/18/diffs
Pleroma狂信者たちの認識では「Mastodon APIドキュメントは仕様であり、必要な全てが定義済みで、仕様の範囲なら何をやってもいい」なんだと思う。当たり前だけどドキュメントは仕様ではないし全てが定義済みでもない。彼らが行った変更はソート順に関する挙動が既存の数値IDと異なるし、128ビットIDをいきなり導入してトラブルを起こさない訳がない。
FSNSに興味のあるiOS開発者は絶滅危惧種なんだからそんな雑な扱いしたらあかんで
https://weeb.academy/notes/5c4cce1b60161c2910eb201b
https://pleroma.soykaf.com/objects/dbd55f76-d117-4cc9-8501-4ec432b8223e
https://letsalllovela.in/objects/d2b889ae-e309-40f3-ad4a-fe243ba93ee2
Pleromaユーザ最低だな
issueだけ投げて放置する https://github.com/tootsuite/mastodon/issues/9923
@rinsuki あとはもうタンス側のデバッグが必要な話だし、サンプルファイルつけてissueなげとけばいいんじゃね？
最近のマストドンは添付メディアのファイル名に非ASCII文字があるとうまく扱えない
@rinsuki OSからみたファイルのmimeタイプではなく、ブラウザがサーバに送ったmimeタイプがどうなってるかだな
で、アップロードできないって人はMacに偏ってるみたいなのですよ。マルチパート送る時のファイルのContent-Typeがおかしいんじゃねーの？だとしたらブラウザのバグ
@miya @charlag @dgold @tootapp @WAHa_06x36 @lain @Gargron @shadowfacts
We have never expressed Pleroma support, then so the frequency of looking at Pleroma's community is very low. https://mastodon.juggler.jp/@tateisu/101436082701177563
@YUKIMOCHI https://git.pleroma.social/pleroma/pleroma の頭の方で「いろんなアプリが動きますよ」ってリストアップしてる。
@lain @charlag @Gargron @tootapp @WAHa_06x36 @dgold @shadowfacts You should have cooperated with more application developers. This situation could be avoided if hearing with the application developer in advance rather than trusting only insufficient documents.
とまあ言葉がキツくなってしまうのは、PleromaでSTが動かないというのがSTにとっても迷惑な評判だからだ。こっちは一度もPleroma対応を謳っていないのに。
Pleroma開発者の言う「MastodonのIDはソート可能な文字列だと仕様にあるから大丈夫だろう？」には苦笑した。文字列比較と数値比較の区別ができてないらしい。たまに間違うのは仕方ないとして、なぜ事前に周辺に打診しなかったのか
Pleromaは最初からアプリ開発者と協調する気はなく、単に既存の実装にタダ乗りしようとしていた。事前にアプリ開発者にヒアリングせずにIDのフォーマットを変えたのは完全に失敗だと思う。これまでロクに協調してこなかったツケで、STに限らず他アプリの開発者からも冷たくあしらわれてる。
@lo48576 APのIDはuriであり全タンス間でユニークです。マストドンAPIのIDはタンス内部でユニークです。APとは無関係。そしてデータ型は文字列ですがソート順は数値なので、アプリ内部で数値として扱うのは自然です。
Picrewの「女の子アイコンメーカー」でつくったよ！ https://picrew.me/share?cd=aT0kYfAKf6 #Picrew #女の子アイコンメーカー
Picrewの「かわいいおんなのこメーカー」でつくったよ！ https://picrew.me/share?cd=mc8oqIb1D6 #Picrew #かわいいおんなのこメーカー
v2.1.3
- カスタム絵文字が動かない症状を改善
bintrayに登録するの面倒だったんでSubwayのソースに入れちゃったけど、これ https://github.com/tateisu/SubwayTooter/tree/master/apng/src/main/java/jp/juggler/apng とこれ https://github.com/tateisu/SubwayTooter/blob/master/app/src/main/java/jp/juggler/subwaytooter/util/APNGFrames.kt が Kotlinで書き起こしたAPNGデコーダ―になります。前者はJVM汎用部分、後者はAndroid依存部分。http://www.libpng.org/pub/png/pngsuite.html のテスト画像全部で表示確認したよ
Subwayでカスタム絵文字が動かないの、使ってるライブラリがIndex colorに対応してないとか色々あったのでAPNGデコーダをフルスクラッチで書いた。ライブラリをjcenterとかのリポジトリに登録するのはどうやるんだろ… https://mastodon.juggler.jp/media/b5WAbed_FoSWnZXLJ5Y
