G4KLX is saying what I've been thinking for at least a year now. The fact that BM and to a lesser extent DMR-MARC, DCI, TGIF and others have created a closed-source, walled-garden approach to interlinking leaves the individual repeater operators at the relative mercy of these networks. The recent UK master server crash is a clear indicator that the centralized technique needs some refactoring.
It's not original, sadly. Other analog-based interlinking tech has the same problems (I'm looking at IRLP and AllStarLink as two easy examples). Hams generally like the interconnection to be plug-and-play. A new approach would require people to actually do things like RTFM and test their changes in isolation before unleashing it on the network, possibly wreaking havoc.
I'm all for an open and decentralized approach to interlinking. The obvious downsides is that it moves more of the work to the repeater operators to be on the lookout for bad actors, or at least LIDS. Some of what I'm getting at is that there needs to be tools to help a sysop/control op check that their configuration changes are going to do what they think it will. That's a tall order.
I'd say that philosophically speaking, HBLink is aligned with this particular view of interlinking and interconnection. I think we have some real architectural challenges (not to mention devops, developer community, and all the rest) to become a robust contributor to this new approach. I also think that IPSC_Bridge and HB_Bridge (to a lesser extent) need to be brought up-to-date to Python 3 through a focus on creating a testable code base and then evolving it from there.
I love this manifesto. I hope we can build something from it.
Randy Hall AA6RH (not K7AGE, quit asking) 😁