okdistribute
commented
3 years ago Hi @milo-trujillo ~! Thanks so much for opening this issue, we'd welcome a pull request from you to update the network health indicator pattern and other related patterns, or add a new pattern if you think it's warranted! I've added some thoughts inline below on your specific points 👍
Discussion
What are broader applications of this pattern? My starting thoughts:
* Confirm that files are widely available
Yes, I'd also expand this to include data more generally, not just files!
* Confirm that hosts supply files for a long time (reputation/trust management, maybe related to [cautious optimism](patterns/cautious_optimism.md) or [conditional file sharing](patterns/conditional_file_sharing.md), or simply preventing DDoS or Sybil attacks)Yes I do think that cautious optimism and conditional file sharing are related. We're aiming to update all patterns with at least two or three links to other related patterns so that people can traverse the library through links, which I think would be pretty nice (and wikipedia-like!)
This also makes me think there could be another pattern here that is more focused on archival and long-term uptime, which you are alluding to in your following point
* Confirm that hosts do _not_ continue providing files after a deletion request (as part of the implementation for the [tombstones](patterns/tombstones.md) recommendation)
Yes, it would be great to add this as part of the tombstones pattern -- it should back link to the network health indicator pattern!
* Identify hosts or users with similar interests (someone mirroring files on an obscure topic likely shares that obscure interest - this is an opportunity for social peer discovery)
This seems like it could be a pattern on it's own, similar to tombstones and conditional sharing?
Note that some of these applications involve UI and informing users, while others (mostly thinking of trust management) are more algorithmic and internal to the network software.
Totally, we are looking at ways to surface this perhaps through a tagging system, where each pattern has a list of tags which indicate whether it is more UI focused or internal/algorithmic. Maybe there is a tag also for these patterns that are related to network health & conditional data sharing? Is conditional sharing less of a /pattern/ and more a /category/ of patterns?? Curious as to your thoughts on this..
There's also a potential limitation of network health indicators in offline-first or sneakernet networks, where peers are online and synchronizing data infrequently, and disconnect from the network for large stretches of time. In these scenarios, we may need a more detailed network health history or notification protocol, such as nodes pushing notifications that they are present and ready to be tested, rather than nodes polling all peers periodically to see which are online and available.
Yes, it would be nice to add a section to network health indicator (perhaps Best Ways to implement...?) for how the network health history is saved on disk and gossiped between peers.. especially useful for offline cases or high-churn networks!
I'd love to brainstorm more applications and add them to the proposal.
Thanks for offering to add; if you have time to do so please feel free; we are planning on keeping this round of patterns widely open for changes and comments through the end of the year, but want to have a first release by mid-December. Your contributions would be really welcomed for that release!
milo-trujillo
Network-Health-Indicator
patterns/network-health-indicator.md describes a reporting + heartbeat system for tracking where information has been replicated and whether those replicas remain available. The design is well described, but the rationalization is currently limited to "[Use this pattern] when users are trusting your application with storing data that is important to them."
Discussion
What are broader applications of this pattern? My starting thoughts:
Confirm that files are widely available
Confirm that hosts supply files for a long time (reputation/trust management, maybe related to cautious optimism or conditional file sharing, or simply preventing DDoS or Sybil attacks)
Confirm that hosts do not continue providing files after a deletion request (as part of the implementation for the tombstones recommendation)
Identify hosts or users with similar interests (someone mirroring files on an obscure topic likely shares that obscure interest - this is an opportunity for social peer discovery)
Note that some of these applications involve UI and informing users, while others (mostly thinking of trust management) are more algorithmic and internal to the network software.
There's also a potential limitation of network health indicators in offline-first or sneakernet networks, where peers are online and synchronizing data infrequently, and disconnect from the network for large stretches of time. In these scenarios, we may need a more detailed network health history or notification protocol, such as nodes pushing notifications that they are present and ready to be tested, rather than nodes polling all peers periodically to see which are online and available.
I'd love to brainstorm more applications and add them to the proposal.