# お気持ち設計メモ

# Okimochi Network

## User,Tx,Score

Networkには、Userがいる。Userは秘密鍵・公開鍵のKeyPairを持っている。UserはTxを発行し秘密鍵でSignする。Txは必ず1以上の参照元TxのハッシュであるPrevHashを含むDAG構造。Txは参照元のTx以外には依存しない。それらの基準を満たしていればrejectされることはありえない。Tx発行時にScoreが計算される。Scoreは自分が知る全てのUserに対して皆同じ計算式で計算される。つまり、どのノードも同じScoreを持つ

TxDAGは全て検証可能なもののみで構成されている。おそらくPeerはMarkleTreeのような構造を利用してTxDAGを保持する

## Peer,ImportantPeer

NetworkにはノードとしてPeerが存在する。Userは自分のPeerから別のPeerにTxを送信(bloadcast)する。Txを受け取ったPeerは、Txを転送するか、新たにTxを発行して送信する。一部のTxは「インフラスコア」などに応じて選出されるImportantPeerのみが発行可能である。

## Txの種類

Txには、OkimochiTx, ModerationTx, NewContentTxなどが存在する

OkimochiTxは、NewContentTxか、自分に向けられたOkimochiTxか、URLに対して発行できる。対象URLが電子署名を持つ場合はユーザーが特定できる。特定できないものはいったんちゅうぶらりんになる。後で署名がほどこされるなどした場合は「確定Tx(?)」が発行される。

ドメイン所有者はDNSのレコードに署名することで、自分のドメインの管理権限を主張し、それぞれのコンテンツ(ページ？)に対して、あるユーザーのものであるという電子署名を施せる。この時ドメイン所有者が、Userのアドレスを知っていればそのアドレスに対する署名になるし、知らなければ自分のドメインのユニークなIDに対する署名になる。後者であればそのIDとUserをBindする情報をUserが流す必要がある。これは、たとえばTwitterやGithub, Qiitaであれば、当人がこのIDは自分の物であるという電子署名と、それに対するアナウンスのTxを流すことでBindできる (この場合、有効期限が存在する)

## Token

「一定期間」が経過したスコアに対して一定数のImportantPeerが合意の上で、TokenGeneratedTxを発行する。この時点を持って各UserはTokenを所持していると認められる

tokenの送受信を行うPeer同士で合意したらTokenPaymentRequestTxを二人で発行して二人がそれぞれSignしてbloadcastする。ImportantPeerは、Timestamp的な何らかのルールに乗っ取って、正式なTokenPaymentTxを発行する。この時点を持って、ユーザー間のTokenは移転する

(おそらくImportantPeerが)Bridgeになる。自分のBridgeで対応してる暗号通貨のウォレットを作成する。対象暗号通貨のブロックを監視しつつ常に皆がバリデーションが行う。

受信用アドレスはHDウォレット的にBridgeが発行する。Bridgeは分散してウォレットを管理する。受信したのを検知したらDonatedTxを発行する。(計算式的に、寄贈した本人のスコアが上がるのと、保有資産が増えた事がわかる。対象暗号通貨のBlockchainとの検証も行える)

暗号通貨の送信はTokenBurnTxでのみ行われる。バーンしたいUserはTokenBurnRequestTxを投げて、ImportantPeerは、TimeStamp的な何らかのルールに乗っ取って、Userの指定した暗号通貨ウォレットに送金した上で、正式なTokenBurnTxを発行する

## storageはどうすれば実現できるか？

まずOkimochiNetworkで分散DB機能を持つ必要がある。分散DBはハッシュによってゾーンが分かれる。また、経路情報みたいなものが分散DBで管理される。分散DB用のChannelがあり、問い合わせはChanelにQueryを投げる。

channelは直接Peerに繋ぎにいったりリレーしたりで実現される?

データはBlobと呼ばれる。Blobは、サイズに応じてBlobFragmentに分割される。BlobFragmentを保持してるPeerはその情報が分散DBに記録される

Blobを保存する場合インフラTokenを使用する必要がある。publicなBlobは安いコスト、private(特定の人だけがアクセスできるもの)は少し高いコストを支払う。(保持期間やレプリケーション度とかも指定できるといいかもしれない)

BlobStoreRequestTxを投げると、ImportantPeerがそれを承認したらBlobStoreApprovedTxを発行する。この時どのPeerが実際にBlobFragmentを保持するかが書かれているので、ユーザーは対象のPeerに直接BlobFragmentを送信する

Blobを取り出すのはコストは最小限のコストか、コスト無しでできるようにする。

ユーザーは分散DBのchanelにQueryを投げて、BlobFragmentを持ってるPeerのリストを取得し、Peerに直接接続してBlobFragmentを受信する

### メール

分散DB用のChanelに、SendMail用のQueryを投げると、経路情報を使って対象Peerがオンラインであればそのまま送信される。SendMailQueryは、対象ユーザーの公開鍵で暗号化されているので、対象ユーザーしか読めない。内容はBlobと同じような感じで？

----

## NewContentだけにOkimochiを送る仕組みであれば、OkimochiTxはTxに対してのみ発生する

Txに対するOkimochiTxを発行できる
自分へのOkimochiTxへのお礼
NewContentTxへのOkimochiTx

## NewContentが発行されていないコンテンツへの Okimochi はどうやって発行すればいいのか？

URLに対してOkimochiTxを送る場合、対象URLにSignされていればそれは問題なく成立する
いったん宙ぶらりんにしておいて、対象URLが誰の物かを後で証明して、証明されたスコアが計算される、でもいいかもしれない。証明する方法としては、対象のコンテンツに「特定の形式で電子署名」するなど。

OAuth対応しているものであれば、Oauthを利用して認証したユーザーに対して証明することもできる

ドメイン所有者が、対象URLについて証明する(義務を負う)こともできる

TwitterやGithub, Qiitaなどであれば、当人がこのIDは自分の物であるという電子署名と、それに対するアナウンスのTxを流すことでBindできる (この場合、有効期限が存在する)

## blockって必要なの？TxのDAGだけでいけるんでは？

たとえばTx DAGのみ

* Tx DAGをひたすら積み重ねる
* Txを承認するのは、Txのprev(複数)をも承認するということ
* これらが全部bloadcastされる

たとえばTx DAGとBlock

* TxのDAGを積み重ねる。
* ImportantPeerによりTx DAGを承認してBlockを発行する
* BlockにはDAG構造のTxが含まれるほか、スコア計算されたサマリーが記録される
* Blockはブロードキャストして全ノードが受け取る
* Blockを受け取ったら、余力がある限りBlockの検証を行って、ValidationTxを発行する

結論: Blockいらない

ユーザー
* 秘密鍵・公開鍵のペアを持っている
* アカウントプロバイダ経由でIDを持つ事ができる (持たない場合、自分のIPが毎回記録される)
* プロフィール情報を持つ
* ユーザーはそれぞれのトランザクションを発行できる

トランザクション
* お気持ちの表明
* モデレーション
* revoke
* 公開鍵の更新、アカウント情報の更新
* 新作情報
* 削除情報

お気持ちネットワーク
* WebRTCのdata channelでつながったP2Pネットワーク
* ウェブブラウザでも動く
* [WebRTC API \- Web API インターフェイス \| MDN](https://developer.mozilla.org/ja/docs/Web/API/WebRTC_API)
* 特定のノードは外とのつなぎ込み、などを行う
* コンテンツプロバイダ
* アカウントプロバイダ
* 暗号通貨ブリッジ
* ブロックチェインエクスプローラ
* つながったピアに対してトランザクションを送信する
* 受け取ったトランザクションは検証をしてから、別のピアに転送する
* 誰かがトランザクションをとりまとめてブロックを発行する
* 例: DHT的にハッシュグループでとりまとめる
* ブロックが発行されたらブロックをブロードキャストする
* 定期的にサマリーブロックが生成される
* 接続時間、信頼スコアなどによって選出される重要なノードは、発行されたトランザクションが正しく受け取られてるかチェックする。もしこれらの重要ノードの一定数に承認されていないトランザクションは信頼性の計算からは除外される (重要ノード承認がタイムスタンプサーバーとなる)
* 攻撃検知 (判定)

お気持ち
無限に存在し誰かが誰か(もしくはURL)に+1〜+5でプラス評価を投げつける。
感想を促す仕組み

お気持ちスコア
お気持ちの価値を計算したもの。スコアはmoderation以外では減らない
スコアの計算はブロックとして承認されてから一定時間の猶予が存在する

お気持ちトークン
お気持ちスコアに応じて定期的にトークンが発行される
トークンには、全体を示す Okimochiトークンと、各種ジャンルのタグのトークンがある。
お気持ちネットワークが暗号通貨に対応した時、トークンをバーンする事で暗号通貨の分配を受けられる
トークンを誰かに贈与、あるいは交換することもできる

user
公開鍵/秘密鍵

markle tree (user list)

network

Transaction
Block

Peer
自分に対応したハッシュをとりまとめる

send
const tx = await sendOkimochi(address, score, comment, tags)
誰かにお気持ちを送る

const tx = await sendModeration(tx, reason, optionString?)
モデレーションをする

txが発生したら、peerに対してブロードキャストする

network
WebRTC P2P?

peer間通信