t_wの輪郭

文章の途中で改行した時→親を両方のアウトラインに持たせる
文章の先頭で改行した時→親を下のアウトラインに持たせる
文章の末尾で改行した時→親を上のアウトラインに持たせる

チャットっぽくすれば改行周りの処理が不要になる（改行が不可能になる）

PCの場合は引き入れに便利そう？
スマホの場合はサイドバーと本文を同時に表示できないため、操作のしやすさが低下する

悩んでいる
Scrapboxみたいに書いたものが随時公開される仕組みだと、公開前の確認とかができなくて困る
チャットぽい感じにして、Ctrl+Enterで公開に進むようにしたら良い？
チャットぽくすると、いよいよデライトやcotoamiに近づいてしまう

ページにアウトラインが属するようにして、ページごとに公開・非公開を設定可能にしたら良い？

こうもり問題が起こるので嫌だな

公開/非公開フォルダにする？

アウトラインごとに公開設定/非公開設定にするのと変わらなくなる

アウトラインごとに公開・非公開を設定する？

ネットワーク構造なので、親の輪郭が公開されたら子の輪郭も公開にするといったことがしづらい
再起的に伝搬して、ネットワーク全体が公開になってしまう
行ごとに公開・非公開設定をするのは大変

全非公開・全公開のどちらかだけであれば、トリッキーなことはしなくても済む

いっそのこと有償のローカルアプリにしてしまった方が楽かもしれない
ただ、ローカルアプリ開発を考えた時、iOSアプリとかMacアプリとかを作るにはMacが必要になりそう

　文輪は一旦、自分専用のツールにしたほうがいいかもしれない。設計がこなれるまでは他人のデータを持ちたくない。

　収益についてはWordpressみたいにブログみたいにしてしまって、そこに広告を張れば良いだろうか？いや、よくよく考えればそれができるだけの文章力があって集客ができるのであれば、デライトの利用者を増やそうという試みがもっと成功しているはずで、そううまくはいかないだろう。

　ブログ的な方向性で考えると、アウトラインを時系列順に並べたくなる。そうなるとデライトと方向性が似通ってしまう。輪郭法と同じ構造を用いて合理的に進めようとすると、どうしてもデライトと似通ってしまうのかもしれない。もしくは頭の中にデライトがあるために、つい真似てしまうのだろうか。

　Dynalistのファイルみたいに複数のアウトラインを持てるようにして、そのファイルが時系列に並ぶみたいな形にしてもいいかもしれない。ただし実装を考えるとちょっとしんどい。後、個人的にファイル分割があまり好きではない。

「アウトライナーの操作性とナレッジグラフの一覧性・整理機能を持った何か」というのが文輪の目指したい方向性を良く言い表していると思った

■残務
利用者登録機能
ログイン機能
ログアウト機能
クラウド保存機能
キー操作でアウトラインの位置を変更
TauriかElectronでアプリ化
スマホ対応（見た目が崩れる）
indexedDBへの保存機能
ドラッグアンドドロップで親を追加
親が増えた時の見た目を整える
ランディングページ作成
複数行をコピペできるようにする
UNDO/REDO

■実装済み
カーソルを上下に移動した際に、カーソルがいい感じのところに移動するようにする
アウトラインを閉じたり開いたりする機能
■テスト済み

検索機能（スクロール追加）
文輪のファイル出力・読み込み機能

■リリース済み

ドラッグアンドドロップでアウトラインのミラーリング
クリックしたアウトラインを表示
親アウトラインの表示
行削除機能

サーバーレス構成で考えたけど、サーバーレス構成にしないほうがいい気がしてきた

• AWSにベンダーロックインしてしまう
• 開発環境にもRDSの費用が必要になるので高くつく
• AWS Lambdaが実行されるたびにAWS LambdaとDBの接続が発生するので、コストがかさみそう
• Websocketが使えないので入力するたびにブラウザとサーバがHTTPで接続すると、コストがかさみそう

文輪のデータベースはPostgresqlでもいいかもしれない。再帰クエリを使うことができる。

どちらもグラフ構造なので

@startuml

entity outline {
    ulid
    text
    created_at_timestamp_ms
    edited_at_timestamp_ms
    first_outline_relation
}

entity outline_relation {
    ulid
    parent_outline_ulid
    child_outline_ulid
    next_outline_relation
}

entity home_outline {
    outline_ulid
}

outline }-- outline_relation
outline ||--home_outline

@enduml

文輪のデータモデルが単純すぎてこれで大丈夫か不安になってくるな。
まあ単純すぎて不足がある分には追加すればいいから大丈夫か。「複雑かつ問題がある」よりも対処しやすい。

@startuml

entity outline as "outline\nアウトライン" {
    ulid
    text
    created_at_timestamp_ms
    edited_at_timestamp_ms
}

entity outline_relation as "relation\n関係" {
    ulid
    parent_outline_ulid
    child_outline_ulid
}

entity home_outline as "home outline\nホームアウトライン" {
    outline_ulid
}

outline }-- outline_relation
outline ||--home_outline


@enduml

@startuml

entity outline as "outline\nアウトライン" {

}

entity relation as "relation\n関係" {
    
}

entity home_outline as "home outline\nホームアウトライン" {

}

outline }-- relation
outline ||--home_outline

@enduml

　PlantUMLでER図を書いていて気づいたのだけれど、輪郭のデータ構造ってどれだけ親ノードをたどっていっても根ノードにたどり着けないな。なんてデータ構造だ。
　なので、読み込みをした直後に表示するノードは、特別に記録しておかないといけない。

　OPMLでやろうかなと思ったけど、ほかのアウトライナーから読み込めるようにするのがめんどくさい。OPMLはあくまでエクスポート専用にしたほうが幸せになれる気がする。

　sql.jsでDBにして保存…！なぜこのような危ない橋を渡ろうとしているかというと、セキュリティ的に安全にRDBの知見をためる必要性があるためです。

• クラサバでサブスクで提供
  • 一番儲かりそう。というか今っぽい。
  • クラサバは開発が大変。
  • データ吹き飛んだ時が大変。１，２回データ吹き飛ばして知見が溜まるまではサブスクしないほうがよさそう。
  • WorkflowyやDynalistとガチンコ勝負になる。
• クラサバで広告モデルで提供
  • デライトの劣化コピーを目指す形になってよろしくない。
  • サブスクよりもデータに対する責任をあまりとらなくて良さそう。
  • ペルソナとして作家のTak.氏があるので、利用者の注意を広告で煩わせるのはそれに沿ってない。
• ローカルアプリでサブスクで提供
  • ビミョー。「商用利用は有料」みたいにして、本当に金払ってくれんの？みたいな疑いがある。
  • 結局サブスクの管理機能が必要になるのでサーバー不要とはいかない
  • Mac対応でMac買う羽目になるのでどこかでちょっと大きめの投資が必要。
• ローカルアプリで買い切りで提供
  • 一番儲からなさそう。というか古臭い。古いから悪いというわけではないということを肝に銘じていただきたい。
  • でも一番楽。
  • ライセンス管理とかは大変そう。そういうことをしだすと結局サーバーが必要。
  • Mac対応でMac買う羽目になるのでどこかでちょっと大きめの投資が必要。
• 寄付で運用
  • 論外。寄付で回っているところをWikipedia以外で見たことがない。大体ヒーヒー言ってる。と思ったけど、Rustとかは寄付（というかスポンサー）でやっていってるらしい。

気持ち的には「クラサバでサブスクで提供」に傾いている。

名前：文輪（BUNRIN）（仮）
お試しページ：https://towasys.github.io/BUNRIN/

あ～～～～サーバー持ちたくねぇ。
サーバー持つと、お金かかるわセキュリティのリスクが発生するわで大変。
セキュリティ三ない運動をしてきたので、知識がたまらずに来てしまった。

　株式会社という仕組みは発案者が金を持ってなくてもいいというのがいいな。

　特許申請の段階から出資を受けにいくというのは面白いというか、私になかった発想だ。そんな気軽に出資を受けていいものなんだな。

　文輪も出資を募ってみたら面白いかもしれない。ただ、出資者に縛られるのはなんというか面白くない感じもするし、他者からお金をもらうことに対して恐怖もある。精神が弱い。

　正直、この先開発を進めるか悩むな。ノリと勢いで開発を始めてしまったので、どういう位置づけにするか決めていない。デライトの劣化コピーになるのは避けたいし、応用はしつつも別の山を登りたい。というか、KNSにまで作り上げる技術力がない。
　進めるとして、WorkflowyかObsidianのような感じにするのがいいかもしれない。クラウド、もしくはローカル。

文輪(輪郭法を用いたアウトライナー)がようやく最低限、試してもらえるだろうところまでこぎつけた。
https://towasys.github.io/BUNRIN/

保存機能はまだないし、操作性もまだまだ改善したいところがあるけど、一番肝の機能は実装が完了した。