本文闡述視頻應用在區塊鏈上的應用的個人想法和觀點。
2種結構的數據：
- 文件存儲
主要引用IPFS的概念：基於文件內容的尋址，分佈式存儲。不存在全節點，即使存在（創造）意義不大。 - 資源索引
主要引用eth的感念：分佈式、p2p，挖礦，內容是同步的。每個全節點擁有完全一致的數據和狀態變量。
即一致性數據和非一致性數據集。
例子：
以下內容爲學習solidity時的見解，其他描述語言可以雷同.
1.用戶
在區塊鏈中無法分辨用戶，識別個體採用地址，因此在此一個地址即爲一個用戶。用戶需要有自己的描述屬性，即【暱稱】【簡介】【頭像】，在此筆者嘗試了2種實現方式，
① address => ipfs object.
將頭像文件上傳到ipfs空間上得到hash值，或者頭像做base64編碼，組合到一個用戶對象（json字符串），將用戶對象上傳到ipfs空間上，得到一個ipfs的hash，儲存到eth網絡中。看起來像：
或
② address => struct.將頭像文件上傳到ipfs空間上得到hash值，其他文本摘要保存到eth數據庫裏。
當然也可以將圖片二進制文件直接丟進eth數據庫，但是在實踐過程中2K大小的頭像加一些說明文字，儲存一個用戶實例曠工費超過0.0007eth,（按照當前匯率已經超過1美元）。
其實用戶個體出現在區塊鏈中，目的還是要與用戶對於起來，更具有人性化，畢竟這些應用都是服務於人的。
2.視頻
視頻檢索可以參考優酷等視頻網站的數據結構，但是也要考慮傳統數據庫的優勢和區塊鏈的劣勢，因此將結構定製成以下這樣：
id自增=>視頻結構
視頻結構：
1.視頻文件：ipfs對象；
2.視頻文件的描述：(此內容冗餘，可以直接讀取ipfs獲得)，比如文件大小，內容格式、媒體內容的寬高，時長；
3.視頻描述：視頻的標題，描述，封面，時間戳，縮略圖
4.應用數據：作者地址、評論、標籤、打賞
同理，在此也使用上述用戶結構的描述方法，將部分索引變量、儲存變量置換位置。
在這裏要思考一個問題：儘可能的將數據放到檢索變量上還是儲存變量上。
所有用戶都是不可信任的，在協議中規定要提交ipfs對象，在eth中如果提交非ipfs對象也能記錄，eth無法調取ipfs端去驗證真僞（話說eos呢？在索引協議中是否可以調取儲存網絡上的信息？未來一定會實現的。）
寫本文時作者未能實現在協議（合約）內去調取ipfs對象，封面可以自定義（最好的情況是在視頻時間內截取）
縮略圖對象包含2部分，1 縮略圖的圖片文件，
2該圖片的描述。
{
寬：
高：
橫向切片數量：
縱向切片數量：
時間：{
第一切片：0秒
第二切片：1分鐘
第三切片：2分鐘
}
}
在播放器加載時可以在進度條加載該資源進行預覽。
爲了更好的統一協議，第一切片 應該被描述成橫向第N塊，縱向第M塊，或者 直接座標點（x，y，w，h）或者（x1，y2，x2，y2）
3.視頻存儲
視頻存儲需要考慮到多個方面：
1.同一個視頻資源內容，應該對應多個質量（即360P、720P、1080P、4K、60FPS、以及不同碼率）
2.同一個視頻資源內容，應該對應多種封裝容器（mkv容器、mp4容器、mov容器、flv容器、f4v容器、ts切片）和編碼（h264編碼、h265編碼、aac編碼、flac編碼）
3.上文視頻結構定義中的視頻描述應該適合視頻存儲的整個對象。
這裏列舉2種方案：
這是一種錯誤的示範↑。
注意：目前支持原生ipfs協議的軟件並不多，因此要特別注意網關轉換，讓不支持ipfs的軟件能從http(https)網關處拿到數據。協議的迭代是不容易的，一旦完成協議部署，或者未來升級，都要考慮到對舊數據的兼容和包容，因此在在以上圖示中應該包容那種錯誤的示範，在初期應用階段也應該判斷是否爲錯誤架構，並作出相應的對待。
視頻存儲需要做到誠實，同一個資源的不同編碼、封裝、質量，其對於是同一個內容，同一時間點的截屏應該完全相同。
注意：本文只涉及到協議（合約）部分，不包括前端調用，但是要爲前端調用做好充足的準備，比如要爲窄帶網用戶提供低碼率或者低分辨率的視頻流，在協議普及過程中（推廣、分享），勢必通過ipfs網關轉http傳輸協議來完成，也要爲網頁用戶提供視頻流。
注意：上文圖示中多個視頻流的描述方法並非首選，應該使用視頻編碼器、音頻編碼器、視頻像素、比特率來描述視頻的清晰程度，但由於此類參數過於專業化，使用者無法立即理解其中的含義，因此要做好易用性和專業性的平衡。
4.評論/彈幕
這裏的評論也指代彈幕功能，不僅僅存儲文本信息，需要完成簡單富文本格式，還要包括彈幕的位置等。針對回覆評論，需要得到回覆給哪條評論，所以評論包含以下幾類信息。
1.評論內容
2.彈幕數據（彈幕類型、顏色等信息）
3.時間（①評論的UTC時間；②評論在視頻的第幾秒時間）
4.是否回覆之前的評論
關於直播的彈幕和評論也應該符合以上結構
5.標籤
標籤主要作用是訂閱、分類、投票，單個視頻可以有多個標籤，每個標籤應該包含投票是數量，比如 一個視頻的標籤爲【短視頻】15票；【搞笑】80票；【遊戲】1票，可以使用標籤分辨出該視頻屬於什麼類別？它是一個搞笑的短視頻。但是【遊戲】標籤有1票，有人給他打了遊戲的標籤，但如果視頻內容不是遊戲，它也僅僅只有一票，算不了什麼。
6.贊/打賞
這是內容提供者的主要經濟（代幣）收入，內容質量決定一切。
7.ipfs 直播
ipfs 直播 功能很好的利用了ipfs pubsub pub 和ipfs pubsub sub。
這裏着重要解釋一下回看：其實可以合併當前分片和歷史分片的m3u8信息，廣播一次即可，但是這樣做一定會對ipfs空間造成浪費，廣播當前ts分片hash和廣播歷史分片hash可以選擇不同的頻率、或者廣播歷史分片hash可以做訂閱，由客戶端發送一個廣播，我需要獲取歷史hash，處理進程再發送一個歷史分片的hash也可以。
在回看過程中發的互動信息，由於是過去時間，不應該顯示給主播看，或者展示給主播看到是回看發的信息，但這些信息需要存入自己記錄的這份視頻文件中，因爲在直播結束或者直播過去時狀態下可以發佈視頻，這回車記錄彈幕。
8.分類目錄
到這裏，所有視頻都是平行的，並不進行分類。分類的功能並不包含在協議中，在Dapp應用中，如果有中心組織去設置分類，將破壞Dapp的規則。
使用標籤作爲分類依據，這一點很好的提現了民主。
9.專輯
這一點和大多數視頻應用一樣，也需要專輯（分組視頻）的結構，其中要實現：
1.分組的名稱、簡介、封面、分組的封面
2.引用的視頻的id
備註
對於區塊鏈應用編程思想來說：
1.可以不設計刪除、更改功能，因爲數據是依賴於日誌寫入生成的，而非當前狀態，這意味着，想看到刪除之前的狀態變量非常容易，需要消耗的資源量不比重新發佈一個新的要少。
2.內容監管，這一點希望evm這樣的虛擬機環境能提供或者調取判斷資源合法性的接口，協議本身能保證數據合法性，無法保證內容合法性。特別是儲存類區塊鏈，這裏建議採用中心化的核審模式。