Nostr as cache system in federated networks
The nostr protocol has exponentially proven to be useful in different fields. While I believe the community should continue prioritizing native applications that fully utilize the protocol, there's one area I think is still worth exploring: using nostr as a secondary support system, especially in decentralized networks.
Light Federation
While creating the Robosats federation, our primary aim was to maintain maximum independence among coordinators. As a result, coordinators did not communicate to each other; instead, data merging occurred at the client level.
However, this approach posed a clear scalability problem. By requiring the client to independently fetch Coordinator data, the federation presents issues as more coordinators joined: increasing the number of requests the client had to manage, resulting in a poor user experience and penalizing coordinators with lower-level infrastructure.
One solution is to aggregate information from all coordinators into a cache system. This approach ensures that regardless of the number of available coordinators, clients can simply connect to a centralized source, reducing the workload on clients and lightening the load on coordinators.
Decentralized Cache
If you're reading this document on this platform, the term "centralized" likely prompted a reaction. We aim to avoid single points of failure; instead, we prefer information to be easily accessible yet decentralized.
Our concept was for coordinators to operate their own caching systems and establish a network among all federation coordinators. This would ensure nodes dynamically spread and receive updated data.
Nostr as cache system
While exploring various straightforward technologies, nostr emerged as the right choice. Here are the primary reasons for our decision:
Decentralization: Intrinsic to the nostr protocol. No additional workarounds or efforts are required in that regard.
Verification: All nostr notes are signed, enabling clients to verify the authenticity of received data and discard any untrustworthy information.
Maintenance: Robosats can delegate the maintenance of this system to other open-source projects tailored for this purpose. Specifically, we opted for STRFRY (https://github.com/hoytech/strfry) due to its robust data synchronization capabilities using the negentropy protocol.
Extension: Nostr's flexibility facilitates integration of additional features such as private messaging or direct notifications, leveraging the infrastructure already in place for the federation.
Isolation: Nostr operates as an independent network, allowing the cache system to function separately from the rest of Robosats. This setup requires only a communication channel between the coordinator and the relay, minimizing vulnerabilities to exploits or bugs.
Standardization: Establishing a protocol for our data enables seamless integration outside the federation, allowing others P2P markets to include Robosats' updated orders in their listings without concern for alterations in the structure or the service.
Nostr as a secondary support system
And yet, Robosats is not planning to be nostr native. I believe it shouldn't be. Robosats remains committed to maintaining the independence of its coordinators from each other and ensuring the highest level of user privacy, which can be challenging to achieve solely through nostr.
This does not implies Robosasts can't get advantage of nostr unique features in specific scenarios or secondary necesities, emerging to something better than the combination of their parts.
Containing:Light FederationDecentralized CacheNostr as cache systemNostr as a secondary support system
Published:2 mo. ago Friday, July 26th, 2024
Author:
Z
z6MkhZDb...yhteqdn7First Version
Powered by Mintter + The Hypermedia Protocol