Actually ... Is it such a bad thing to lose the connection to people behind somebody when we lose the connection to him? This is exactly what we want to do when there is spam going on - a web of trust. If the web is very straggly, then it won't be very stable.
Alice is connected to Bob and Charlie. Bob is connected to Evelyn and Fred. Evelyn is connected to Fred and Charlie. Alice invites Bob to a chat. Bob invites Evelyn to the same chat. Evelyn invites Fred. So now we have Alice <-> Bob <-> Evelyn <-> Fred Fred starts spamming the channel. The topology of the web of trust is known. Alice's user decides that Fred is spamming the channel, and ignores him. This sends a message to Evelyn indicating that Fred was spamming the channel. Evelyn invites George, who also starts spamming the channel. Alice complains again. The complaints are routed through the above path. If a particular node constantly spams with many identities behind it then it can be blocked. So we use the fact that the topology of the web behind the channel is known to prevent spam. We can ensure that it is reasonably robust by automatically exchanging data with anyone who is on the channel that we are directly connected to. Obviously there are limits on how far this can scale, but it is not required to scale indefinitely. This I suppose could be called keyless unkeyed pub/sub without recovery. Note that it's entirely possible to implement this at the client level if we provide the means to send messages to adjacent peers. If it works well then we can upgrade it to a first class service; if it doesn't we don't have to. The advantage of keyed pub/sub with recovery (traditional pub/sub), of course, is that you can talk to _anonymous_ people, without having to get a recommendation through the web of trust. You can talk to channels which your friends aren't on. That will be implemented in 0.8. On Fri, Jun 30, 2006 at 08:42:08PM +0100, Matthew Toseland wrote: > On Fri, Jun 30, 2006 at 08:33:52PM +0100, Michael Rogers wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Matthew Toseland wrote: > > > > >> * Hosting chatrooms for selected peers > > > > > > What exactly are we talking about here? > > > > I wasn't thinking about channels spanning multiple nodes, but it might > > be useful to have more than one channel within a node (you might not > > want to invite everyone to every chat). > > Well, the problem is that the metaphor virtually requires it to span > multiple nodes. > > My peers are not always the same as yours. If you invite me and then I > invite Ian, to whom you are not connected, that makes it a relayed channel. > However, they are usually similar, because of the triangles property. > > But as soon as the number of people on the channel increases past 2, we > have to deal with such issues. > > We can make the network manually bridged - i.e. I invite you, and people > behind you can only talk to me for as long as the connection between me > and you is up - but this connection *will* be lost at some point, and > the inability to recover from this will be seen as a bug. > > So we are back to full pub/sub streams. > > Or a very restricted function where only the designated server can > invite people to the chat, and then only if they are directly connected. > > Or we require that everyone in a chat is directly connected to everyone > else in the same chat. > > How do multi-person chats work on typical IMs? -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060630/d0109a08/attachment.pgp>
