15 điểm bởi GN⁺ 2025-12-08 | 1 bình luận | Chia sẻ qua WhatsApp
  • Xây dựng tiện ích mở rộng duyệt web dựa trên nguồn cấp RSS để người dùng có thể khám phá và đánh giá ngẫu nhiên nội dung từ các website độc lập
  • Hiển thị trang web mới chỉ bằng một cú nhấp nút, đồng thời hình thành cấu trúc đề xuất dựa trên cộng đồng thông qua các chức năng thích, không thích và báo cáo
  • Xây dựng backend bằng FastAPI và SQLite, sử dụng danh sách RSS small web của Kagi để lập chỉ mục khoảng 600.000 trang
  • Không có quảng cáo hay thu thập dữ liệu người dùng, chỉ cung cấp trải nghiệm khám phá nội dung web thú vị trong thời gian ngắn
  • Một dự án thử nghiệm cá nhân nhằm giảm sự mệt mỏi của các trình đọc RSS hiện có và hướng đến việc tái khám phá hệ sinh thái web nhỏ

Tổng quan dự án

  • Bắt đầu từ nhận thức rằng trải nghiệm dùng trình đọc RSS tạo cảm giác nặng nề
    • Chỉ ra áp lực khi các bài chưa đọc cứ chồng chất và sự kém hiệu quả của cấu trúc nội dung theo thứ tự thời gian
    • Người dùng bày tỏ mong muốn khám phá ngẫu nhiên những bài viết thú vị
  • Lấy cảm hứng từ cách đề xuất của TikTok, dự án thiết kế một cấu trúc cung cấp ngẫu nhiên nội dung từ các website nhỏ
    • Khi người dùng đánh giá nội dung, tần suất hiển thị tăng theo số lượt thích
    • Áp dụng thuật toán đề xuất đơn giản, không có quảng cáo hay thu thập dữ liệu cá nhân

Tính năng và luồng người dùng

  • Được cung cấp dưới dạng tiện ích mở rộng Firefox, có thể tải tại timewasterpro.xyz
  • Người dùng nhận website mới bằng cách nhấp nút và đánh giá bằng Upvote/Downvote/Report
  • Cần tạo tài khoản; nếu liên kết bạn gửi trở nên phổ biến với người dùng khác thì thứ hạng sẽ tăng trên Leaderboard
  • Backend định kỳ thu thập các nguồn cấp RSS và lưu vào cơ sở dữ liệu
    • Cứ mỗi 600 giây kiểm tra 5 nguồn cấp, với tần suất cập nhật không quá một lần mỗi ngày
    • URL bị báo cáo sẽ được chuyển vào hàng đợi xem xét, đồng thời ghi lại số lượt thích và không thích

Cấu hình kỹ thuật

  • Viết API bằng FastAPI, quản lý cơ sở dữ liệu bằng SQLAlchemy
  • Lưu trữ dữ liệu bằng SQLite
    • Khởi động nhanh và sao lưu đơn giản nên phù hợp với dự án làm vì sở thích
  • Xác thực bằng cách tạo tài khoản qua email rồi kiểm tra bằng liên kết
    • Từng thử đăng nhập bằng Passkey nhưng bị hạn chế do tính không ổn định của các triển khai OSS
    • Sử dụng xác thực JWT, nhưng được đánh giá là kém hiệu quả về mặt trải nghiệm người dùng
  • Sử dụng danh sách RSS trong kho lưu trữ GitHub small web của Kagi làm nguồn dữ liệu

Thiết kế và trải nghiệm người dùng

  • Sử dụng thư viện System.css để tái hiện phong cách Apple System OS thập niên 80~90
    • Truyền tải trực quan rằng đây là “một thử nghiệm cá nhân chứ không phải dịch vụ chuyên nghiệp”
  • Không thể phân biệt phím tắt theo từng hệ điều hành nên cố định bằng phím Alt
  • Gặp vấn đề với việc chỉ định ID theo từng trình duyệt trong cấu hình manifest.json của tiện ích mở rộng
  • Không tích hợp công cụ phân tích nên phản hồi người dùng được thu thập chủ yếu từ các lỗi được báo trực tiếp

Kế hoạch sắp tới

  • Dự định cải thiện bằng cách phân loại nội dung theo danh mục để người dùng thấy các thể loại yêu thích thường xuyên hơn
  • Đang xem xét chức năng chuyển nội dung có mức Downvote vượt ngưỡng nhất định sang hàng đợi riêng
  • Cần xây dựng cơ chế để người dùng mới ban đầu có thể ưu tiên tiếp cận ‘nội dung tốt’
  • Mong muốn mở rộng thêm các website độc lập về ảnh, khoa học và thủ công
  • Hiện đã lập chỉ mục khoảng 600.000 trang, mã nguồn sẽ được công khai sau khi ổn định

1 bình luận

 
GN⁺ 2025-12-08
Ý kiến trên Hacker News
  • Ý nghĩ rằng phải đọc hết mọi nội dung là lỗi trong thiết kế UI của trình đọc

    • Vấn đề nằm ở cách hiển thị RSS feed như một “hộp thư đến” giống email

    • Nên tiếp cận theo kiểu “dòng sông tin tức (river of news)” trôi qua như TikTok

    • Cốt lõi là chỉ ghé xem nhanh những bài thú vị, còn lại cứ để chúng trôi qua

    • Twitter về bản chất cũng có cấu trúc gần giống RSS — chỉ là cuộn xem mà không có dấu “chưa đọc”

    • Vì vậy nên tắt bộ đếm “số mục chưa đọc”. Giá trị của RSS nằm ở việc tôi chọn đọc cái gì

    • Nếu là bài thật sự hay, sớm muộn gì những người đăng ký khác cũng sẽ chia sẻ liên kết đó

    • Tôi lại thích kiểu hộp thư đến hơn là “dòng sông”

      • Nếu sắp xếp feed theo từng danh mục thì việc đánh dấu “đã đọc hết” cũng không khó
      • Thay vào đó, tôi hủy đăng ký ngay những feed đăng quá thường xuyên. Blog đăng bài hằng ngày thì tôi không theo nổi
    • Tôi cũng từng muốn xây một hệ thống tự động tìm nội dung hợp gu của mình trên toàn web

      • Cuối cùng tôi nhận ra tầm quan trọng của nguồn dữ liệu chất lượng cao, và đi đến kết luận rằng chỉ cần theo dõi một số ít người thật sự tốt là đủ
      • Nghĩ lại từ đầu thì hóa ra đó chính là RSS — một khái niệm đã hoàn thiện từ năm 2005
    • Vài năm trước tôi cũng có một ngộ ra tương tự

      • Vì không muốn theo dõi những gì đã đọc, tôi đã tạo bot cho từng RSS feed rồi mirror sang Diaspora
      • Giờ tôi đã chuyển sang Mastodon nhưng nguyên lý vẫn vậy — chỉ đơn giản là cuộn và xem những gì thú vị
    • Twitter là dịch vụ đã từng như vậy, còn bây giờ thì không

  • Có vẻ một số người đang dùng RSS reader sai cách

    • RSS không phải công cụ để tiêu thụ hết toàn bộ nội dung như một kênh YouTube, mà là công cụ nhìn tiêu đề rồi chỉ đọc những bài thấy hứng thú

    • TikTok thậm chí còn tệ hơn — đó là cấu trúc giữ chân người dùng bằng một luồng nội dung vô tận

    • Với kiểu người này, có lẽ danh sách “đọc sau” sẽ phù hợp hơn là một RSS reader mới

    • Engine gợi ý của TikTok rất hiệu quả vì nó đo phản ứng ở cấp độ từng nội dung đơn lẻ

      • Trong khi đó YouTube bắt người dùng chọn một trong nhiều thumbnail, nên bị mất thông tin về 9 cái không được bấm
      • Không phải bản thân thuật toán là xấu, vấn đề là nó được tối ưu cho điều gì
      • Reader của tôi cũng hiển thị từng nội dung một như TikTok, nhưng được tạo từ các bài báo khoa học hay bài viết về LLM do chính tôi gửi vào
    • Không cần phải khẳng định dứt khoát rằng ai đó đang “dùng RSS sai”

      • Chỉ là cách tiêu thụ nội dung đã chuyển từ “đọc thứ vừa được đăng” sang “đuổi kịp đống đã tích lại”
      • YouTube cũng có thể được dùng theo đúng nguyên lý đó
    • Hồi trước khi dùng NetNewsWire tôi từng thấy lo lắng vì huy hiệu bài chưa đọc

      • Nếu dùng lại bây giờ, tôi sẽ tắt huy hiệu và tự động đánh dấu đã đọc với những bài quá 2 ngày
    • Tôi đang dùng bản tt-rss năm 2005 đã được tùy biến

      • Có feed tôi đọc từ đầu đến cuối, có feed chỉ thỉnh thoảng lướt qua
      • Về sau tôi muốn thêm feed thuật toán dựa trên hệ thống gợi ý
      • Đặc biệt tôi muốn thử một feed gợi ý phi tập trung dựa trên các bài được gắn sao/gắn thẻ bởi những tác giả mà tôi thích đọc
    • Dấu “chưa đọc” của Google Reader trông giống email nên tạo cảm giác như một “việc phải làm”

      • Đó là UI khiến việc chỉ lướt tiêu đề trông như một “công việc”, thay vì chỉ là hành động lướt xem đơn giản
  • Nhiều người dùng RSS như một danh từ chung chỉ web feed

    • Khi triển khai thực tế, vấn đề là nên dùng RSS, Atom hay JSON Feed

    • Podcast vẫn dùng RSS làm nền tảng mặc định

    • Tôi chỉ dùng JSON Feed

      • Nhờ cấu trúc đơn giản, nó hoạt động tốt trên hầu hết reader và cũng dễ xử lý bằng lập trình
      • Khi tự tạo feed thì tôi dùng JSON Feed 100%. Tôi không thấy lý do gì phải dùng Atom
  • Phần lớn feed reader có vẻ được làm bởi những người thực ra không dùng RSS

    • Tôi đang quản lý 211 feed trong hơn 20 danh mục, với 13.000 mục cache

    • Tỷ lệ tôi thực sự bấm vào để mở bài đầy đủ chỉ khoảng 1–5%

    • Đồng cảm hoàn toàn. Có quá nhiều reader thiếu tính năng lọc hoặc cấu trúc để xử lý lượng bài lớn

  • Ưu điểm của RSS là không bị chi phối bởi thuật toán gợi ý

    • Không bị lặp đi lặp lại một vài domain nhất định, và có thể xem bài từ nhiều lĩnh vực một cách cân bằng
    • Cảm giác này giống như quay lại mô hình luồng thông tin tuyến tính truyền thống
  • Tôi rất vui khi thấy dự án kiểu này

    • Trước đây tôi cực kỳ thích StumbleUpon, nên rất mừng khi có dịch vụ tương tự xuất hiện

    • Ước gì ai đó làm ra hậu duệ của DIGG

    • Hoàn toàn đồng ý. Nó gợi lại cảm giác hoài niệm về StumbleUpon, đồng thời có điểm hay là có thể tự chọn trọng tâm nội dung

    • Nhân tiện, Digg gần đây đã ra mắt lại dưới dạng beta

  • Tôi thích kiểu tuyển chọn phi thuật toán của RSS, nhưng không muốn kiểu tuyển chọn đặt “niềm vui” làm trung tâm

    • Tôi muốn tránh cấu trúc thúc đẩy “tương tác” như TikTok
    • Lý do tôi quay lại RSS là để được kết nối trực tiếp với các tác giả mà tôi yêu thích
    • Sau này nếu nội dung quá nhiều, có lẽ kiểu tuyển chọn bản tin hằng tuần nơi thuật toán tóm lược nội dung sẽ là lý tưởng
  • Việc có giữ nguyên thứ tự thời gian của nội dung hay không còn tùy tình huống

    • Tôi từng thử hình dung UX có thể giải quyết vấn đề này trong RSS reader hay podcast, nhưng vẫn chưa tìm ra cách nào thật sự tốt
  • Tôi xin giới thiệu dịch vụ Scour

    • Nó xếp hạng các bài viết theo mức độ liên quan cao với mối quan tâm của người dùng

    • Có thể nhập RSS feed hoặc tìm kiếm từ hơn 15.000 nguồn

    • Nó được thiết kế như công cụ chọn lọc ra những bài hay để tránh hàng nghìn mục “chưa đọc”

    • Nghe thú vị đấy. Tôi tò mò không biết có tính năng loại trừ một số feed bằng blacklist hay không

  • Tôi đang cố giải quyết vấn đề phân loại danh mục trong RSS

    • Nhiều feed không dùng trường category, nên tôi đã làm một crawler phân tích hashtag trong phần mô tả

    • Để giữ trạng thái RSS “inbox zero” mỗi ngày, tôi hủy đăng ký những blog đăng bài quá thường xuyên

    • Tần suất đăng bài và chất lượng nội dung có xu hướng tỷ lệ nghịch

    • Tôi đăng ký RSS bằng ứng dụng Karakeep

      • Nó tự động lưu nội dung và tạo thẻ bằng AI tạo sinh
      • Có thể tạo RSS feed theo điều kiện nên rất hợp để dùng cùng reader hiện có
    • Website của tôi cũng cung cấp nhiều loại nội dung khác nhau, nhưng đa số reader không hỗ trợ thẻ category

      • Cuối cùng tôi phải phân biệt bằng cách thêm tiền tố như [Blog] vào tiêu đề