Xây dựng trên Nostr: Những thách thức kỹ thuật thực sự
Đây là Phần 2 của loạt bài gồm hai phần.
Phần 1 bao gồm các nguyên tắc cơ bản về giao thức — sự kiện, chuyển tiếp, NIP và kiến trúc làm cho Nostr trở nên khác biệt.
Thiết kế của Nostr có vẻ đơn giản: một loại dữ liệu, rơle câm, máy khách thông minh, nhận dạng mật mã.
Nhưng sự đơn giản đó có nghĩa là mọi vấn đề mà máy chủ truyền thống sẽ giải quyết — xác thực, tính nhất quán của dữ liệu, quản lý kết nối, kiểm duyệt nội dung — giờ đây sẽ thuộc về máy khách.
Khi nhóm của chúng tôi tham gia dự án diVine, chúng tôi đã nhanh chóng học được điều này.
Những thử thách mà chúng tôi gặp phải không phải chỉ có ở video.
Chúng có tính cấu trúc, được hiểu rõ về ý nghĩa của việc xây dựng trên một giao thức mà máy chủ cố tình không hoạt động.
Máy khách của bạn duy trì các kết nối WebSocket đồng thời với nhiều rơle độc lập — thường là 5 đến 15 cùng một lúc.
Bởi vì các rơle không liên lạc với nhau và những người dùng khác nhau xuất bản tới các rơle khác nhau nên việc kết nối với nhiều rơle là không bắt buộc.
Vòng đời kết nối là trách nhiệm của bạn.
Mỗi kết nối rơle có thể ngắt độc lập.
Khách hàng của bạn cần logic kết nối lại với độ trễ theo cấp số nhân, theo dõi tình trạng trên mỗi kết nối và giảm tốc độ một cách nhẹ nhàng.
Cách tiếp cận thực tế là một lớp trình quản lý kết nối chuyên dụng giữa logic ứng dụng của bạn và các kết nối WebSocket thô, sở hữu vòng đời, định tuyến đăng ký và lập ngân sách tài nguyên ở một nơi.
Quản lý đăng ký trở nên phức tạp nhanh chóng.
Việc tải nguồn cấp dữ liệu yêu cầu đăng ký trên nhiều kênh chuyển tiếp cho các tài khoản được theo dõi, phản hồi, phản hồi và siêu dữ liệu hồ sơ — nhân với mọi màn hình trong ứng dụng của bạn.
