自訂專輯有辦法分享給朋友嗎？產品如何設計？

我們想要的場景

自訂專輯是 Lossic PRO 在 Mac 上的一個功能：把一批 .m4a 拖進來，給它專輯名、封面、曲序，它就會以一個資料夾的形式上傳到你 Google Drive 的 Lossic/ 底下，iPhone 上的 Lossic 幾分鐘內就能播。

它從一開始就是為你自己擁有權利的內容設計的。你在自己的工作室錄的 demo、你的樂團排練與正式演出的錄音、你為朋友的影片寫的配樂、你在 Bandcamp 上買下且授權條款允許你這樣做的檔案。這些內容的共同點是：你有權決定它們去哪裡。

而這類內容天生就需要分享。你是創作者，想把新專輯的 ALAC 母帶先發給幾位樂迷試聽；你是演出者，想把昨晚整場錄音分給一起站在台上的夥伴；你和遠端的協作者反覆交換混音版本。所以我們想做到的事很單純：

我在 Lossic 裡把自己的作品做成一張專輯，分享給我選定的聽眾或協作者；對方在他自己的 Lossic 裡匯入，得到一模一樣的專輯——同樣的名字、同樣的曲序、同樣的封面。

界線先講清楚

這個功能的邊界，和它的技術設計一樣重要，所以放在前面說。

分享只適用於你擁有合法權利的內容：自己創作、自己持有版權，或已取得授權——並且只用於符合資格的個人用途。別人的錄音、你買來聽但沒有再散布權的商業發行，不在這個功能的範圍裡。這不是我們附加的一條免責聲明，而是自訂專輯這個容器本來的定義：裝的是你的東西。

另一個要說清楚的是 Lossic 在這件事裡的位置。我們沒有中央伺服器。沒有一台機器存著任何人的音樂、也沒有一條 URL 是「從 Lossic 下載」。分享發生在你自己的 Google Drive 裡，用的是 Google 原生的分享機制，受 Google 的服務條款約束；Lossic 做的事只有一件——把檔案從你的 Drive 搬到你授權的收件人裝置上。誰能拿到什麼，由你在 Drive 上決定；你對這些內容的權利與責任，也在你身上。

這一段是產品的願望與界線。下面是它在技術上撞到了什麼。

我們原本的假設

檔案都在 Google Drive 上，Drive 本來就有很成熟的分享功能。所以最初的直覺是：創作者在 Drive 把專輯資料夾分享給對方，對方的 Lossic 下次同步時就會看到新專輯。整件事好像不需要我們做什麼。

這個假設錯在一個地方，而且錯得很根本。

真正的限制：帳號層與應用層是兩件事

Lossic（iOS）和 Lossic PRO（Mac）向 Google 申請的權限是 drive.file。這是 Drive API 裡最小的一個 scope，規則只有一條：app 只能存取它自己建立的檔案，或使用者透過系統檔案選擇器明確選過的檔案。這不是我們在 UI 上做的選擇，是 Google 在 API 層強制執行的——沒被授權的檔案，請求就是 403。

我們選這個 scope 是刻意的。另一個能「讀整個 Drive」的 drive.readonly 是受限 scope，會觸發每年一次的 CASA 安全評估。對一個純 client-side、沒有後端的 app 來說，那是為了一個我們不需要的能力扛一筆年年要付的合規成本。而且從使用者的角度，一個音樂播放器只碰它自己建立與被親手交給它的檔案，本來就是比較合理的權限形狀。所以我們一直守在 drive.file 裡。

回到分享。當你把專輯資料夾分享給對方，發生的事是：對方的 Google 帳號取得了那些檔案的存取權。他可以在 drive.google.com 看到、下載、「加到我的雲端硬碟」。這一層是真的通了。

但對方手機裡的 Lossic 是另一層。那些檔案不是它建立的，對方也還沒在檔案選擇器裡選過它們——所以在 drive.file 的規則下，app 對它們一無所知。帳號看得到，app 讀不到。整篇文章的核心就是這一句。

橋在哪裡

限制本身也給了出路。drive.file 的第二條授權路徑是「使用者在系統檔案選擇器裡選過的檔案」。而分享已經讓對方的帳號有了存取權，所以那些檔案會出現在對方 iPhone 的「檔案」app 裡（Google Drive 的 File Provider 底下）。

換句話說：分享解決了帳號層，選取解決了應用層。對方只需要在 Lossic 的匯入流程裡把那些檔案選一次，Lossic 就拿到了讀它們的權限。分享沒有白做——它是必要條件，只是不是充分條件。

這個設計還有一個我們喜歡的副作用：每一次匯入都是收件人自己在系統選擇器裡做的明確動作。沒有任何檔案會「自動出現」在誰的 Lossic 裡。

選不了資料夾，但選得了檔案

我們做過一次 spike 實測 iOS 檔案選擇器搭配 Google Drive 的行為，有兩個結果直接決定了流程長什麼樣：

• 資料夾不能被選取。Google Drive 的 File Provider 沒有實作目錄挑選，選擇器裡所有資料夾都是灰的。「點一下專輯資料夾就匯入」這條路不存在。
• 但資料夾裡的檔案可以多選、可以全選。進到資料夾裡，全選，按完成——裡面的每個檔案都被授權給 app。

所以收件人這邊的操作是：打開 Lossic 的匯入 → 檔案選擇器 → 進到創作者分享的專輯資料夾 → 全選 → 匯入。多一步，但不多一個決策。

manifest.json：把資訊寫在檔案旁邊

到這裡權限問題解了，但還剩一個品質問題。全選拿到的是一堆檔案：十幾個 .m4a 加一張 cover.jpg。Lossic 要怎麼知道這是一張專輯、叫什麼名字、哪首排第幾？從檔名猜是一條路，但我們在其他地方已經吃過檔名的苦——編碼、前綴、大小寫，猜對七成的結果就是三成的專輯長得不對。對一位創作者來說，自己的作品在別人手機上曲序亂掉，是很難接受的。

我們的做法是：Mac 端建立或上傳自訂專輯時，在資料夾裡除了原本就有的 cover.jpg，再多寫一個 manifest.json。內容很單純——專輯名、演出者、年份、封面檔名，以及有順序的曲目清單（檔名對應曲名）。

收件人全選資料夾內容時，曲目、封面、manifest 三者一起被選中、一起被授權。Lossic 匯入時先找有沒有 manifest.json；有，就照它還原專輯名、曲序、封面；沒有，才退回檔名推斷。結果是一次乾淨的匯入：對的名字、對的順序、對的封面，跟創作者在 Mac 上看到的一樣。

manifest 不是通行證

這裡必須說清楚，因為很容易誤會：manifest.json 帶的是資訊，不是存取權。

如果收件人只選了 manifest.json 一個檔案，Lossic 讀得到清單，但清單裡列的每一首曲目對 app 來說仍然是未授權的檔案——去讀就是 403。manifest 裡就算寫了檔案 ID，也不能靠它「夾帶」任何存取權。drive.file 的授權只認使用者在選擇器裡實際選過的東西，沒有例外。

所以 manifest 解決的問題只有一個：不用從檔名猜。它是 metadata 的 sidecar，永遠不是 token。收件人還是得把曲目本身選進來，而曲目能不能被選到，取決於創作者在 Drive 上有沒有分享給他。存取權的來源始終只有一個：Drive 的擁有者。

各自擁有自己的副本

匯入完成後，那張專輯會被複製到收件人自己 Drive 的 Lossic/ 底下，成為他的收藏。兩個人各自擁有一份，不是共用同一份。

我們知道「直接播共享的那一份、不佔自己空間」聽起來更優雅。但那需要 app 能讀取「不是自己建立、也不是每次都選過」的檔案——也就是 drive.readonly，也就是每年一次的 CASA。我們目前不打算為這個場景走那條路。

各自一份副本的代價是佔一點 Drive 空間；換來的是零合規成本，以及一條清楚的責任鏈：創作者決定分享給誰，收件人親手選取並匯入，副本存在收件人自己的空間裡。沒有任何一個環節是 Lossic 替誰做的決定，也沒有任何一份檔案經過我們的伺服器——因為我們根本沒有伺服器。

但這裡要誠實：因為匯入會產生一份副本，這個功能只在「你對內容有合法權利」的前提下才成立。這一點值得和 Apple 的 Home Sharing 對照——它不複製、只在同一家庭的區域網路內串流播放，版權風險本質較低；我們會複製、且不限家庭與網路，所以責任更重、界線更要守。正因如此，我們不會把「跨人、跨網、各自副本」當成賣點來推銷；分享的正當場景，始終是你自己創作、擁有版權或已獲授權的內容。工具能做到什麼是一回事，鼓勵你拿它做什麼是另一回事——我們只鼓勵前者。

狀態：Mac 端寫入 manifest.json 與 iOS 端讀取匯入的實作正在進行，本文描述的是設計與已驗證的限制，不是已上線的功能。

你買下的音樂，值得比檔案管理器更好的家。