Profile img

AmaseCocoa

@cocoa@hackers.pub · 18 following · 20 followers

I maybe use Engrish in this account

Pythonista/Author of apkit. An Modularized ActivityPub Toolkit.

Akkoma
ak.amase.cc/@AmaseCocoa
My Website
amase.cc
Zenn
@amasecocoa
AmaseCocoa @cocoa@hackers.pub
Public

I don't like FEP-044f...

I think the idea itself is good, but the problem is that it adopts an opt-in approach. First, it cannot be quoted in software that hasn't implemented it. Second, static file-based servers cannot support quoting (044f requires sending a QuoteAuthorization when approving a quote). I've never actually seen a static file-based ActivityPub server, so you probably don't need to worry too much about that...

Also, since the canQuote policy seems to only serve as advice, it appears we can't make it approval-free... :(

(Please let me know if there are any errors in this; it would be helpful.)

5
2
0
1
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
1
0
0
0
0
0
0
0
AmaseCocoa @cocoa@hackers.pub
Public

まぁ念の為typeフィールドのチェック自体入れるつもりだけど (例えばtypeが指定されてた場合はそのtypeの一致もチェックで効力するみたいな？少なくともActor関連はtype違いのモデルがあるから必須になる)

とはいえそれは微妙な気も

0
0
0
0
0
0
0
0
0
1
0
0
1
0
0
AmaseCocoa @cocoa@hackers.pub
Public

Anyone have same errors Astro running in Bun?

I can't know how reproduce this...

Bun Canary v1.2.24-canary.26 (e3a1ae09) Windows x64
Windows v.win11_dt
CPU: sse42 avx avx2 avx512
Args: "node" "F:\amasecc\foxtail\node_modules\astro\astro.js" "dev"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) fetch(115) http_server jsc spawn(3) transpiler_cache(28) tsconfig process_dlopen(3)
Builtins: "bun:main" "node:assert" "node:async_hooks" "node:buffer" "node:child_process" "node:crypto" "node:dns" "node:events" "node:fs" "node:fs/promises" "node:http" "node:https" "node:module" "node:net" "node:os" "node:path" "node:perf_hooks" "node:process" "node:querystring" "node:readline" "node:stream" "node:tls" "node:tty" "node:url" "node:util" "node:vm" "node:zlib" "node:worker_threads" "ws" "node:v8" "node:http2"
Elapsed: 1791059ms | User: 47062ms | Sys: 25015ms
RSS: 1.45GB | Peak: 1.55GB | Commit: 1.41GB | Faults: 1572143 | Machine: 68.34GB

panic(main thread): Segmentation fault at address 0x2E
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

To send a redacted crash report to Bun's team,
please file a GitHub issue using the link below:

 https://bun.report/1.2.24/wn2e3a1ae04gBugk0ggC228qyB+3p8wB__0omt2CA2A8C

error: script "dev" exited with code 3
1
1
0
1
0
0
0
1
0
0
0
0
1
1
0
1
0
0
1
1
0
1
0
0
AmaseCocoa @cocoa@hackers.pub
Public

鍵のローテーションで問題起こる実装があった記憶なのでユーザー名の変更機能、実装したさがあるけどできない気がする

あんまりいい方法じゃないけど鍵の使いまわしできれば別かな (ユーザー名がimmutableな前提で設計されてる実装あるだろうし無理)

1
1
0
2
1
0
1
0
0
1
0
0
1
1
0
1
0
0
0
0
0
AmaseCocoa @cocoa@hackers.pub
Public

taskiq-psqlpyはブローカーのサポートがないから候補にならないんだよなぁ (PRはあるけどそれのコードのもとになってるtaskiq-pgにも少し不安なバグがある)

0
0
0
1
1
0
2
0
0
AmaseCocoa @cocoa@hackers.pub
Public

方針を変えた

Connectorサーバーを別途で用意してプラグインはそこに対して収束するようにする

そうすればクライアントライブラリさえどうにかなれば言語関係なく実装できるようになる

0
0
0
0
0
0
1
1
0
AmaseCocoa @cocoa@hackers.pub
Public

問題としてソフトウェアがAGPLだと感染する (個人的にはプラグインが拡張するソフトウェアのコードを含まない限りコピーレフトの制約に縛られることを望んでいない)のでどうしようってなる

この場合はプラグインAPIの概念をコアに分離してKagura (Mastodon API, Admin UI等)自体をそれのプラグインとして実装するのが妥当なんだろうけど悩む

ただその場合はコアにapkit.serverを実装しないと結局ライセンスに縛られかねない (Mastodon APIの実装側をAGPLにする方針の場合)

2
2
0
2
1
0
1
0
0
3
1
0
2
0
0
1
0
0
3
0
0
1
1
0
2
0
0