t_wの輪郭

デライト自体がActivityPubと連携すると…

• デライトにとっては、連合宇宙からの集客が見込める
  • デライト側の整備が追い付かない恐れがある

　
t_w個人がデライトへの投稿をActivityPubへ流すと…

• 連合宇宙からの反応が期待できる
• デライトへの投稿を起点とした会話ができる
• おかしなことを書いた場合に突っ込みを受けられる

■デライト→連合宇宙：

• コピペだと手間がかかる
• 引き入れや輪結などが継承されないのがもったいない。
• 自動化して全輪郭をActivityPubに流し込むとノイズになってしまう。
  • 連合宇宙で可能な表現とデライトで可能な表現が重なっていることしか書けなくなってしまう。（気持ちの面で）。
• マストドンに投稿を投げるブックマークレットやブラウザアドオンは簡単に作れそう

　
■連合宇宙→デライト：

• 連合宇宙で可能な表現⊂デライトで可能な表現 なので、連合宇宙で書いたことをデライトに転送すればよさそう。
• デライト側にいい感じの書き込みAPIがない
  • Scrapboxだと、GETで新規ページ作成ができる
    • Scrapboxへページ遷移→GETパラメータに従って新規ページが作成される
  • デライトだと、POSTで新規ページ作成ができるが、Cookieを事前に取っておく必要がある
    • 検索機能を使えば、表題を入力された状態のページに遷移することはできる
      • 表題なので、改行は使えない
      • https://dlt.kitetu.com/?kw=連合宇宙での投稿内容

デライトの ActivityPub 対応は結構前からある課題なのですが，やはり難しい問題が色々あり保留中ですね。

どの範囲を流すか，設定をどうするか，負荷はどうするか……特に負荷は Mastodon 運用で結構キツかった経験があり，中途半端な実装ではまずいだろうなというのがあります。

範囲と設定については，特殊な輪郭を用意して，その中に入れれば KNEST を通じて配信される，というのが一番単純に済むだろうと考えています。

マイクロブログとデライトは投稿の意識・意味合いが違うので，やるとすれば「マイクロブログ互換描出」としてやることになると思います。それが私がやっているツイストです。

結局，実装だ柔軟性だと考えると手動連携ツイスト，要するにコピペのコスパになかなか勝てませんでした。例えば，コピペ先で少し書き加えたり省略したりと融通も効きますし，PC で慣れれば1回あたり数秒の手間なので。

リンクが有効というのはありがたい情報でした。デライトの描出のようなツートが Mastodon あたりに流れ出したらかなり目を引くだろうな，とは思っていたのですが，なかなか実験出来ませんでした。

デライトのActivityPub対応にはまた別の問題もあって，デライトは投稿内容=輪郭を自由に更新できるけど，ActivityPubによるSNS実装の多くは投稿内容の編集ができない場合がかなり多い，というかSNSを銘打ってる実装で投稿内容を弄れるのを知らない。実質的に「削除して再投稿」するしか方法がないのが現状。

ActivityPub規格自体には「更新」「編集」に相当する操作を連合宇宙で遣り取りする "Update Activity" というのは実在するんだけど，これと既存のSNSの枠組みの相性が悪い（なぜなら，繰り返すけど既存のAP対応SNS実装にそういう機能が存在しない為）。

編集内容を更新ごとに別のURLで参照できるようにして，言及 (投稿に対する@付きtoot/noot) やboost/renoteの対象をその時点のもの（利用者がそのtoot/note/...を閲覧したその時刻におけるtoot/note/...）にしたりするような配慮も必要になってくる。

変更されないことを期待してるrepostとかlikeとかのリアクションが変更後にも残ることを危惧する考えがあるので現行のSNSっぽいやつには投稿のUpdateは期待できないかもしれない。change logが要る

https://pl.kpherox.dev/objects/af6606d3-16b1-4079-ad0b-960fce7a9bea

CreateとUpdateを全部残してAnnounceやLikeの時間と突き合わせてAPIでそのNoteのrevisionを取得できるようにしてようやく安心？

https://pl.kpherox.dev/objects/705ff8f8-9673-40cb-8c7b-cbe47acfa0ff

YouTubeのeditedの表示ぐらいでいいならflagつけるだけでいいけど変更前どうなってたのってなる

https://pl.kpherox.dev/objects/87b41e09-5475-406a-b0d2-3a8fb42e65e5

輪郭選り手周りの作業は「輪郭選り手整備」としてまとめることにした。

デライトの ActivityPub 対応について，必ずしも ActivityPub 捌き にすることにこだわらず，Twitter 連携も含めた「自動連携ツイスト」として実装することを検討し始めた。この場合，任意のアカウントを指定して自動投稿するような形になる。

デライトから立求する場合の用影として Delitebot を検討。

朝，右吹き描きはやはり右横書き等への対応に使うべきという考えが強くなり，自輪郭に使う代替案を探し始めていた。

そんな時，K#9-D657 氏の描き出しを見て，そもそも吹き出し感に拘り過ぎていることに気付いた。自輪郭の自我アイコンは省略しているが，鼻を残していたためやはり吹き出し状に見えた。これだと，どうしてもインスタント メッセンジャー風に左右に振り分けたくなってしまう。

自輪郭は中央寄りで，他輪郭は左から吹き出してくる，という形でも十分直感的ではある。折角試行錯誤を重ねて作った鼻付き吹き描きを一部とはいえ鼻無しに戻す，という考えに辿りつくのは自分だけなら時間がかかっただろう。これも面白い開発者心理だと思った。

ここで，鼻付き吹き描き以前の「鼻無し吹き描き」を自輪郭のために復活させることにした。

ただ，角の形を変えるのは難しかった。自分でも数時間試行錯誤したが，現状の吹き描きは波括弧を象りつつ自己相似になっており，どう変えても徹案上の整合性が取れない。とりあえず，鼻無し吹き描きの輪郭線を太くするという方法で凌ぐことにした。

この日最大の収穫は，吹き描きの理論的根拠を手に入れたことだった。吹き描きも膨大な試行錯誤の結果こういう形になっているが，どちらかといえば直感頼りで，なぜこの形でなければいけないのか，その理由が自分でも把握しきれていなかった。ルービックキューブのように散々いじり回して，あまりの隙の無さに自分でも驚いた。

そして，早く試して早く過ちに気付けたことも大きかった。前日，前後景一覧整備の中で最も簡単に実装出来そうということから着手して，すぐに出振るいして，すぐに違和感に気付き，用者から反応してもらわなければ，その後の開発にもかなりの無駄が生じていただろう。右吹き描きにも右横書きという新しい活用法が見つかり，無駄にならなかった。

自分で思っていた通りに上手く行ったこともある。20日4歩で考えた通り，前後景部の輪符を表示し分けたが，これはなかなか愉快で，交鳴通類としてのデライトの可能性が感じられた。

あとは，散歩しながらデライトの ActivityPub 対応について少し再考した。これまで，ActivityPub に対応することが集客の観点からデライト収益化に役立つのではないかと思っていたが，ここに来てより現実的になったのか，これは難しい気がしてきた。

多少の話題性はあるかもしれないが，デライトの魅力ではなく ActivityPub の魅力で呼び込める人数は高が知れている。最悪の場合，余計な負荷だけを背負い込むことになりかねない。デライトの魅力が伝われば ActivityPub に頼る必要はない。今はあくまでもデライトの魅力を高めることに専念して，収益化を実現して余力が出来てからの話だろう。