I really like the flood-style approach Michael mentions below, especially because it could allow for all nodes to listen continuously (and undetectably) and only broadcast on random occasions (in very short, very high bandwidth multicast bursts). Maybe also use GPS or accelerometers to suppress broadcasting twice from the same location to complicate triangulation.
The "signed channel" idea is also really good, as I expect the goal of the system is to get a relatively small set of messages out to the widest audience -- this is a collaboratively-filtered broadcast medium, not a private individual chat medium. So everybody's device is constantly showing a stream of messages in each channel, with the option to flag certain messages for rebroadcast. Given that broadcasting is a risky thing, it makes sense to reserve that for messages/sources the broadcaster has explicitly endorsed. -david -- Sent from my Palm Pre On Jun 14, 2011 8:25 AM, Michael Rogers <[email protected]> wrote: On 14/06/11 04:42, Julian Cain wrote: > On Jun 13, 2011, at 8:38 PM, Jan Brittenson <[email protected]> > wrote: >> I think all you need is something that can be turned on at specific >> times, to get a message out. Then shut it off. People will have >> their phones on, then all of a sudden they get service, a text >> message or two, after which the service promptly drops again. A >> station only needs to be on long enough to get the message out. > > ... and to receive the acknowledgement regarding said message. Acks may or may not be necessary, depending on the protocol. With a Usenet-style flooding protocol it's sufficient to transmit each message opportunistically to everyone you meet and discard duplicates - no acks are needed. >> I think the main challenge is how to prevent a regime from >> hijacking the network. This will probably require an organized >> structure with isolation, redundancy, a revocation protocol, and >> careful safeguarding at the top. Funnily enough I'd argue for the opposite approach - the way to make it robust isn't to safeguard the top, it's to have no top. ;-) Imagine a completely distributed publish-subscribe network organised into "channels", where each channel's subscribers flood the channel's messages among themselves using a simple Usenet-like protocol. How do we prevent agents of the regime from drowning such a system with spam? Solution 1: Restrict who can post to each channel. (For example, by associating each channel with a public/private key pair - subscribers discard any messages that aren't signed with the private key.) That would create a bloggish/twitterish style of interaction where each channel would have one author (or a small group of mutually trusting authors) and an unlimited number of readers. Solution 2: Peer moderation. In this model, any subscriber can post signed messages to a channel, but each subscriber will only forward messages signed by authors who that subscriber has manually marked as not being spammers. Thus new authors can't reach a wide audience until they've won the trust of some other subscribers. Solution 2 involves more work for subscribers than solution 1, but it allows multi-way discussions, whereas solution 1 could potentially devolve into people shouting past each other. Fortunately both solutions require similar infrastructure, so we can build them both into the same system and see which one people prefer. > The number of dissident operated devices need only outweigh a > "regime" in order to protect the network. The same rules apply to > most overlay networks. Not really - most P2P and wireless overlays can be jammed by a small number of malicious nodes, including the mesh protocols that have been discussed for these "internet in a suitcase" type ideas. Cheers, Michael _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
