/webだってmastodon v3のフロントエンドがそのendpointで動くからそうなってるだけだったわけだしね
/webだってmastodon v3のフロントエンドがそのendpointで動くからそうなってるだけだったわけだしね
あとは複数のフロントエンドを同時に動かすと名前空間のバッティング管理が面倒なのでやりたくないよねそりゃねって感じ
そもそもmastofeがglitch-socとの関係悪化で維持できなくなって消すことにしたやつで、glitch-lilyはpleromaとは関係がないプロジェクトなので別で用意してたfrontend付け替えに一応使えるよってだけのものなので……
このアカウントは、notestockで公開設定になっていません。
admin-feでlogin with pleroma-feとかあるしフロントエンドの変更、なんか色々面倒って気持ちになる
もうpleroma側で複数のフロントエンド同時に動かすのはできないよ。reverse proxyで頑張ってって感じになってる
このアカウントは、notestockで公開設定になっていません。
原語で見たら概念としては簡単なほうだと思うけど日本語に直訳されると何？ってなるかもしれない用語たち
@WakuwakuP configで`config :pleroma, :frontends, primary: %{"name" => "glitch-lily", "ref" => "servant"}`かしら
gitは常にリモートのブランチの状態を反映してるわけではないのでgit fetchでリモートのブランチをキャッシュしようねってやつ
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
性悪説に基づいて色々想定はするけど収集側にも信用ってものがあるので提示した条件を守る相手なら許容するよって感じの寛容さ
このアカウントは、notestockで公開設定になっていません。
DevToolsでdocument.createElementしたら呼び出されるんだからそうだ。確かに。なるほどなぁ
content scriptの中でReactiveElementのconstructorに関数登録されてないの、呼び出したDOM APIが動いてるのがpage contextでcontent context側のobjectにアクセスするような流れになってるからか…？
@WakuwakuP docker volumeなるほどね。pleromaが書き込みするの、:static_dir/{emoji,frontends}だけなはずだし予めfrontendsディレクトリ作ってhost側からownerをコンテナ動かすuidに変更してやったら良さそう
pleroma-feやsoapbox-feと違ってmastodonはwebuiにprofile editとか含めてないから昔のmastofeみたいな使い勝手にならないけど
pleroma.frontend install glitch-lilyでいいよ。soapbox-feとかと一緒
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
content scriptの中だとsuperClassのprototype functionをsuperClassのconstructor内で呼び出そうとしたらundefinedになってるの意味わからなさすぎる
@rollup/plugin-node-resolveでlitをiifeにしたやつ、violentmonkeyに@requireで読ませたらpage contextだとreactive-elementのprototype methodsがnot functionて怒られて使えないのにcontent contextだと普通に使えてなんねそれつってる
ほんでカタール側から金をもらってカタールサポーターになった人とかインタビューに「奇妙な」回答する人とかがいたとも書かれててわかりやすいねぇってなってる
