從 gslin 那邊看到 Pocket 要收攤的消息：《 Pocket 總算要關掉了… 》
Pocket 這種「稍後閱讀 (Read it Later)」的工具，在我 GTD 的流程裡扮演了一個很重要的角色。
需要閱讀的東西，用方便的小工具 (早期是 bookmarklet，現在是 iOS的 share 跟 browser 的 extension) 丟進去 pool 裡，讀完的 archive 起來。 早期還會想要分類下 tag，但後來實在太麻煩，而且全文搜尋太好用，就不下 tag 或分類了。
我記得早期我是用 Instapaper 的，(可能是) 2014年初轉到 Pocket。
當 Mozilla 買下 Pocket，我也沒什麼在意。頂多是後來帳號整合在一塊，登入的時候，要想一下用哪個密碼 (其實也不用記，有自動填入)。
之後就一直留在 Pocket 沒移動過。一直到 Mozilla 決定關掉這個服務為止，我才驚醒：哇！工作流程要被影響了！
即使現在有那麼多 AI powered，跟桌面程式深度整合的「資訊整合/閱讀」服務，我還是用著古老的 Pocket 跟 Simplenote。一個負責連結，一個負責文字、其他、和初步整理。深度的整理現在是在 Obsidian 上進行，閱讀後的發佈和分享則是交給 blog / twitter / thread 等。閱讀網路文章時，如果覺得適合分享，又不需要(或不適合)打太多心得，早期我用小海的 twitthat，後來就把 Pocket 打星的文章經過 IFTTT串到 twitter上。這麼做，已經很多年了。
但事情來了，就要面對。
於是這一週就花了兩天處理跳船的事情。
處理的同時，也在擔心 Simplenote 的狀況：跟 Pocket 一樣，被大型服務 (Automattic，就是Wordpress的那家公司)併購後，Simplenote 的開發一直…處於放生的狀態。雖然說服務只要穩定就好，不一定要一直疊加功能上去，但 Simplenote 的狀況比 Pocket 更悲戚一些：沒有穩定的付費模式，本來開放的 API 陸續收回 (雖然某程度上還有辦法用)，第三方的工具一直隕落，也一直缺乏和其他服務的串接 (沒有太多自動化的機會)，也沒有針對AI 世代有什麼明顯的回應。
簡單來說，就是一個放著 run，燒不了太多錢，但也沒有花心力維護的服務。
但他還是我用過最「方便」，最順手，也留在我GTD 工具清單最久的工具之一。
這樣一個服務，要是某天 Automatic 把它關掉，我應該會哀嚎得更大聲。
好了，扯遠了。
回到 Pocket 跳船。
選擇
在找了幾個相類似的服務，包括公開服務的網站 跟 self-hosted (自托管)的選項後。最後我決定先試 Karakeep 這個可以自托管的服務，然後把工具架在自己的伺服器上。
以下是我評估過的服務：
公開服務
- Raindrop.io — All-in-one bookmark manager
https://raindrop.io/self-hosted (自託管)
- Karakeep
https://karakeep.app/
- wallabag: a self hostable application for saving web pages
https://wallabag.org/
- go-shiori/shiori: Simple bookmark manager built with Go
https://github.com/go-shiori/shiori
- Readeck
https://readeck.org/en/
我會選擇 Karakeep，最主要的原因有兩個：
- 除了 Instapaper 外，現在其他的服務我都沒有把握不會在接下來的十年內消失。
- 我希望用 AI 來協助處理，而 AI 產生 tag、全文搜尋、支援 MCP 等，聽起來很吸引人。
安裝
現在的軟體安裝，有了 Docker 之後真的很方便。
下載 docker-compose.yml 後，把 .env 設好，nginx 的reverse proxy 設一設，避開會衝突的port。機器很順利就run起來了。
可以設定的東西不多，先初步玩一下發現沒什麼大問題，就準備把資料從 pocket 搬過來了。
Pocket 有支援 export 功能，匯出的 .csv Karakeep 也可以匯入。
嗯…從2014 到現在…13000筆書籤。不知道我的小機器吃不吃得下。
跑了兩天，終於重新 index、抓內容和離線頁面、請 AI tag 完成。還好機器撐住了，沒掛掉。
一些統計數字如下：
- 13000 筆書籤 ，其中 2285筆 (占17.45%) 現在已經消失，無法再連得到。部份是Google feedproxy 的連結 (又是該死的 google)
- 下載下來的網頁文字、banner 圖檔、和頁面存檔 (snapshot) 占了 4.79GB 的資源。
- Pocket 資料裡的歸檔狀態 (Archived) 沒有過來，導致我必須想辦法把 12900 筆資料設為歸檔。在寫程式用API處理、使用 CLI 處理、以及手動歸檔 (有批次編輯)這三種選項中，我選擇了… 第三種 人工。
- AI 產生 tag 消耗了 8鎂 的 OpenAI credit。
Update 2025/6/8:
v0.25.0 已經支援把 Pocket 的歸檔狀態 (Archived) 一併帶入。但我沒有試過。只是根據 release note 所言。
目前手動的書籤管理 (新增/編輯)已經轉到 Karakeep 上作業了。加書籤的速度跟 Pocket 一樣快，但是AI 處理跟 index 需要時間，所以出現在首頁的時間會需要 30秒左右。
再觀察看看，真的受不了，再看看如何改善。
還需改善的地方
書籤進系統後，處理的速度不夠快
因為要讓 AI 處理過書籤，抓取內容，再讓內建的 Meilisearch index，感覺出現在首頁的速度還是有點慢 (30s 左右)，目前還在勉強接受的範圍。
因為在我 GTD 的流程裡面，新增書籤是 Capture 資訊進 InBox，跟後續的 Clarify/Organize 是在不同階段處理的事。所以我有多的時間讓系統去處理。
半自動化/自動化流程還需要重新打造。
主要是因為 IFTTT 不支援 Kerakeep。之前的自動發佈流程就失效了。
但正好拿來作為我練習 n8n 的作業之一。
沒有夠強大的瀏覽器擴充工具
自從發現 In-My-Pocket 這個 firefox 的擴充之後，我就把Pocket官方的擴充工具給丟了。甚至連官方的首頁都很少上去。
現在 Karakeep 的的瀏覽器工具加書籤很順，但也才僅止而已。要閱讀等還是要去首頁。閱讀/打星/歸檔還是沒有那麼流暢。
我看 In-My-Pocket 的作者也在煩惱未來的路怎麼走。我想，就讓子彈飛一會兒吧。
資源占的硬碟空間有點多
13000則書籤，即使包括文字，應該不會占太多空間。但實務上占了4.8 GB的空間。初步分析了一下，主要是他抓下來的網頁 banner 並不會處理，就直接存進去。對某些網站一張4K尺寸 PNG 的banner，占了11MB 也照存不誤。累積下來當然很可觀。
看了一下 Karakeep 的資料架構，之後應該可以把這些圖檔取出來處理成尺寸較小、壓縮率較高 (例如 Jpegli 或是WebP) 的檔案再存回去。這就等有空再處理，反正目前還有空間。
未來潛力
目前除了手動切換到 Karakeep 使用一陣子，看看有沒有什麼致命問題外。
有空的時間會先花時間打造輪子，回到之前習慣的工作流程模式。順便升級一下成自己之前想要，但受限於 Pocket 跟 IFTTT 而無法實現的工作流。
之後如果不分心的話，會想把這13000筆資料，請AI幫忙，整合進我在思考時的架構之中。畢竟這些文章我當年都有讀過，只是忘了。 XD 怎麼做還不清楚，但可能用 MCP 去 refer 吧。
還是希望不要再跳船了，都一把老骨頭了…
在〈從 pocket 跳船到 Karakeep〉中有 1 則留言