People have tried to solve the multicast problem before.

From wikipedia:

CastGate was an attempt from the ETRO-TELE research group at the Vrije Universiteit Brussel to break the chicken and egg problem of IP multicast adoption on the Internet ... The hope was if enough content providers and users used this service, then more Internet service providers would enable IP multicast natively to their customers.

Almost verbatim what I've been saying lately :-)

The project has been dead for a decade.

However, there are some key differences in both their definition of the problem, and their approach to solving it.

CastGate was mostly interested in content providers and rich media. Accessing streams of data. This is what most people think of in relation to multicast. A single sender, many listeners. Single Source Multicast (SSM) is a subset of Any Source Multicast (ASM), and not what I'm interested in.

CastGate provided a java web browser plugin and a client/server pair of programs for Windows and Linux that accessed a hierarchical network of tunnel servers. That kind of centralized design is exactly what I want to avoid.

What I'm talking about are many-to-many communications. Sure, multicast is a very efficient way of streaming large wodges of data to many nodes. It is also a very efficient way of managing group communication and disseminating even tiny amounts of data. The sender doesn't need to care who is listening. The listener doesn't need to care who is sending. The network takes care of all of that.

Installing and maintaining extra software is unacceptable. We don't do that for unicast, so we cannot for multicast.

A developer will include the librecast libraries, build and ship their program, and it will work. As more ISPs enable multicast by default, it will work better. It needs to be that simple. The end user will no more know that multicast is involved than they do TCP or UDP now.

That's the plan, anyway... watch this space.