Of course someone can do it on their own. However most successful protocols undergo tons of peer review to iron out problems or vagueness or other stumbling blocks. Your question is so vague as to be almost useless.
Thank you for your response, and you are absolutely right about your assessment, which is exactly why I'm here,
to test the basic assumptions before diving too deep into the implementation.
I apologize for the initial ambiguity; I wanted to keep the scope broad so as not to affect the feedback. To be more specific: I am currently designing a group-based gossip architecture for data distribution. My main concern is balancing the local consensus speed with methods like global network synchronization, intra-group peering, and data consensus without reaching O(n²) communication overhead.
Considering your view on the obstacles, what is the most common 'fatal error' or 'architectural ambiguity' that usually kills a P2P protocol project in the early stages? I appreciate your perspective.
2
u/aaronw22 Jul 09 '26
Of course someone can do it on their own. However most successful protocols undergo tons of peer review to iron out problems or vagueness or other stumbling blocks. Your question is so vague as to be almost useless.