I've been arguing that DC-Nets are among the crypto protocols that we've not exploited much so far. I was working on an implementation, till I got stuck with the 'net' part of it. Speaking of long-term integration on the internet, might it not be a good idea to get some IP address range assigned for dc-net use? To integrate with the rest of the Internet, there should be some IP address that this message appears to originate from. These are the addresses that need reservation. Class A,B,C addresses are the standard unicast addresses for network interfaces. Class D addresses are multicast addresses. Class E addresses are reserved; there are 27 bits of address space available. If we could reserve some 11 bit prefix of this address space, that would leave us with 16 bits of address for dc-net addresses. This will certainly suffice until the new IP is fully deployed. As far as social mechanisms go, how does one go about reserving some prefix of the Class E address space? Could our resident IETF gurus comment, please? Very Simple Review: To send one message, (1) a group of people make a bunch of bilateral communications. (2) Each person publishes the sum of all the messages the receive. (3) The sum of all the broadcasts in item (2) is the message. There are a bunch of integration issues to deal with as well. For communication internal to the dc-net, i.e. from one member to another, a Class D multicast address will suffice. All the dc-net members would be members of the multicast group, and any of them could reconstruct a message. Communication from the dc-net to the rest of the internet is the problem. How does someone send a message into the dc-net? How does the dc-net send a message outside itself? How do you properly do name service? For sending a message into the dc-net, a message directly posted from the outside to the internal multicast address for the dc-net would suffice. But most systems can't route to a Class D address yet. Sending a message from the dc-net should appear, in an ideal world, to originate from the Class E address for the dc-net, but the same routing problem is even worse here. Unicast proxy addresses for the net solve both of these. By using multiple loopback interfaces, you can given a machine on the Internet more IP addresses than it has physical interfaces. That is, if a single machine has only an ethernet connection, adding two loopback interfaces could give that machine three IP addresses. These extra IP addresses can be used as proxy addresses. These proxy sites would have to be trusted at least against denial of service. If one assumes higher level authentication and integrity checking, alterations in the message stream by the proxy can be detected. Failure recovery could then include choice of a new proxy or reconfiguration of the dc-net. I can't really comment now on how might a proper long term solution might work. One would at least keep the proxy addresses for backward compatibility, since it's unlikely for many years to have direct support for dc-nets shipped as standard kernel features, although that _is_ the eventual goal. It's likely that the protocols for discovering and joining multicast groups, as one example of an aggregate addressed entity, will apply here. Eric