KKBOX 如何走向物聯網
===

###### tags: `2018`, `R2`

##### 位置: R2
##### 講者：陳俊諺

{%slideshare 貼這裡xxxx/yyyy %}
[TOC]
---

## 過去十五年來專注提供服務的主流平臺
- Win、Apple、Android

## 如何在其他系統讓使用者聽到 KKBOX 的音樂？
- 甚至還有一堆 Android 的分身
- 車機
- 後照鏡
- 喇叭
- 機器人
- 魔鏡？
- 時鐘？
- 相框？
- 要在這些東西上基本上是很困難的

## 無法輕易被取代的東西
- 5000 萬曲庫
- 唱片公司對 KKBOX 的信任是時間累積而來的
- 龐大的用戶來支持我們
- 隨時間和使用量累積而來的資訊
- ex:排行榜（依據使用者收集來的資訊）
- 擁有強大團隊來分析使用者習慣（使用體驗）
- 自製內容
- 了解時代潮流、時事

## KKBOX Open API/Partnter API

> 從眾多的資料中挑選出最有價值的內容並用簡潔一致的方式呈現
- Restful API
- ex:
- 各式各樣的歌單(排行榜、曲風、情境)
- 個人化的資訊
- 蒐藏內容
- 不同的推薦結果
- 問題
> 如何讓第三方應用只取得到要的內容就好?

## 第三方平台的整合關鍵 - OAuth 2.0
> 就是來解決提供使用者需要的內容

- OAuth 2.0 讓使用者授權第三方平台資料

### 要解決的四個問題
- 服務必須在所有地方支援密碼認證，但密碼太危險
- ss token
- 第三方擁有了密碼，就等於擁有了你
- 為了讓一個第三方不再能存取你的資料，你只能修改密碼，連帶影響其他的第三方
- ex:如果把密碼交給其他10個應用，如果一個應用密碼不用了，會連帶影響到其他 9 個應用
- 解決方法：加入授權方式，所以不用了只需要移除權限

- 其中一個第三方被攻破，你就失去了一切

## 第三方平台的整合關鍵 - OAuth

- RFC 6749 - The OAuth 2.0 Authorization Framework 定義的四個 grant flow
- Authorization Code Grant
- Implicit Grant Flow
- Resource Owner Credentials Grant Flow
- Client Credentials Grant Flow
### Device Flow 讓更多裝置可以取得使用者的資料
- 沒有瀏覽器的裝置
- 喇叭
- 操作介面受限的裝置
- 電視
- 手錶
- 車機

- 透過一個方便輸入的裝置來輸入密碼 -> 通過後才給予授權

### 那個不能說出名字的東西

> 那個不能說出名字的東西，讓 KKBOX 變成遙控器，使音樂在不同裝置上流暢地切換

- 讓 KKBOX 變成一個遙控器

### 無線音樂體驗的問題
- 藍芽
- 音樂播放受其他音訊干擾
- 消耗裝置資源
- 對聲音多做一次有損壓縮
- 會再次破壞音樂品質
- 雖然有號稱無損壓縮，但還無法證實
- 距離受限

- AirPlay
- 音樂播放受其他音訊干擾
- 消耗裝置資源
- 不是給個人都是果粉

- Chromecast （現在還比較少人使用）
- 針對音樂設計的裝置稀少

### 那個不能說出名字的東西

#### 遇到的問題
- 藉由 pub/sub pattern protocol 讓裝置獲得彼此的資訊
- 為了達到用最少的資源，達到最大的效益
- 盡可能 POSIX - compliant 已達到 DRY
- 盡可能最大化可以共用的部分
- 盡可能地減少 dynamic library 大小
- 盡可能地減少商業邏輯

#### KKBOX Assistant
> 憑藉著對音樂資料的掌握，KKBOX Assistant 更能了解你對音樂的需求

- 智慧音箱所需
ASR (自動語音辨識) -> NLU (自然語言理解) -> Intent Handling -> Session Managing

### KKBOX x Google

## Takeaway
- 了解自己的長處，找人一起打群架
- 盡可能用最少的資源，達到最大的效益