抱歉這麼晚回，因為這個問題有點大。
這個問題，現在是有構想，不過長期怎麼變就不大確定了。
首先網站的初期是由創辦人管理，基本上我們想做的自然是能自由就多自由，因為也沒有太多時間管理。只有傷害到 kaif 發展的，我們才會動刀砍文刪帳號。另一點是我們的理想跟用戶是一致的，都是想要一個中立且自由發言的環境，所以利益上沒有衝突。
接著是未來會補上版主的功能，版主有義務維持討論區的中立與自由。而版主則是由投票選出或投票罷免，所以方向由整體用戶決定。
如果網站有幸成長，開始變成大社群，那就不是原本的開發團隊可以處理了。到了那個階段會需要金流支持營運。金流大了之後，就要成立第三方監督機構了，同時也要成立基金之類的組織管理、並且公開資金的流向。到了那個階段原創辦人會交出管理權變成委員會的方式管理吧。
有背後的金主，他就會主導網站的言論走向。所以如果要做廣告收入，那只能走自動廣告投放的系統 (例如 adsense) ，這種不會介入發佈商營運的收入來源。不然就是走群眾集資或是捐獻的方式募資。也許還有其他選項，但總之就是不能有金主在干擾運作。如果做不到獨立運作並且保持言論自由與中立，我們會趁早收了這個站，台灣不需要假內容的網站。
討論發散的問題，我們會先做 最新討論 的功能。我想短期內可以解燃眉之急。rss 的話就要晚一點了。
不過真的很好奇 rss 還是有需求啊，是用 feedly 嗎?
看範例：
FsLo5xllxHinTYAGyEVldE (22)
RUID 22 個字啊，這不能接受....
其實我們做的 FlakeId ，日期最少是 2015 年，這樣算起到今年 3 月，就要十碼了。我看其他網站做的都 6、7 碼而已，也不知道怎麼做的。十碼我已經覺得很遜... 22 碼受不了...
自己寫的，叫 FlakeId，類似 SnowFlake1 的設計。原本是打算全部用 UUID 的，不過為了讓 URL 好看，只好退回用 64bit int，所以現在 db 的 key 是 UUID 和 FlakeId 混用，我們不靠 DB 產生 key。
原本也是打算找現成的，結果 SnowFlake 居然收了，只好又花了二天寫這個...
速度快是因為沒什麼人用.... 哈。這個站架在 google cloud，有台灣機房，應該是比其他的雲端快。
右三角形的確是個問題，因為我借用的原本是拿來展開收合的 icon。kaif 這個站的設計元素就是三角型，所以才會在重要的地方都會有三角型出現。先看看會有多困擾，或者是之後試試其他的三角形狀。