Project description

From The Okopipi Wiki

Jump to: navigation, search

Note to reporters: The information contained on this wiki page is not official documentation.

alcnac4tg Translations: en | da | de | es | fr | he | it | nl | no | pl | pt | ro | ru | th | zh


This is a general overview of the Okopipi project. For more details, see the Detailed Project Description

Contents

Project Purpose

The purpose of Okopipi is to reduce the amount of spam received by users. This is not a spam filter, although it may be used in conjunction with one. Okopipi's goal is to stop spam from being sent to users.

While Okopipi will differ from bluefrog in many ways, knowing how bluefrog actually worked can give you a good start. Unfortunately, there is a lot of misinformation about how bluefrog works out there, so be skeptical about what you read. A good overview of bluefrog was written by Marcus Ranum.

Network Design

Note to reporters: The information contained on this wiki page is not official documentation.

Users must send spam reports to Okopipi, where spam will be analyzed and reported. Since the network by which users send data to Okopipi is vital, the following network design has been proposed.

--Spydermann 17:10, 26 May 2006 (PDT) Correction: The use of the term "supernode" is discouraged due to confusion with Super Nodes from other network implementations. I propose the term "Handler" instead of "Super".

Topology

Note to reporters: The information contained on this wiki page is not official documentation.


The currently proposed topology is based on a de Bruijn Graph model proposed by Loguinov et al. in the 2003 paper entitled "Graph-Theoretic Analysis of Structured Peer-to-Peer systems: Routing Distances and Resilience". For load balancing we will use the k-Choices algorithm proposed in 2004 by Ledlie and Seltzer.

There are currently two proposals for the Network:

Flat Model and Hierarchical Model.

Flat Model

The flat model was the second model proposed, but it's much simpler than the first model and could serve as a base for it, so it's presented first. More features could be added later.

Image:Frognet2b.gif

Note: The diagram above for the Okopipi network (blue lines) does not really show a de Bruijn Graph, it was simplified for aesthetic purposes.

The flat model is based on a file sharing network, where the authorized content is signed with the administrators' public keys. Clients would start submitting opt-out requests against a spammer's site as soon as they see that an authorized opt-out script is available.

It's very simple to maintain, as there are no authority roles or reputation to handle. The disadvantages is that there is no way to ban a user from logging into the network, so spammers could infiltrate and slow down the network with excessive bandwidth.

Also, all administration details like designating users to sign scripts, will have to be done through external means (chat rooms, e-mail, etc.)

Hierarchical Model

Image:Frognet1.gif

Note: The diagram above for the Okopipi network (blue lines) does not really show a de Bruijn Graph, it was simplified for aesthetic purposes.

The hierarchical model was the first one proposed, but due to its complexity it's scheduled for version 2 of the Okopipi Network. It builds on top of the flat model by adding administration features. These would include moderation tasks and private messages between administrators. It also contemplates having usernames and forming private groups. It has the advantage that administrators can designate users with specific functions like signing scripts or validating websites. These designated users could ban nodes if they perceive suspicious activity. On the other hand, it requires a more complex security and anonymity layer to prevent infiltration by spammers who have already signed up.

High Level Design

Servers

Note to reporters: The information contained on this wiki page is not official documentation.


Note: This part needs clean-up. The team still needs to have a meeting on architecture to agree on the final design used for the network. The main server(s) will not be known to the outside world. Only the Okopipi administrators will know their locations -- making a DOS attack very difficult.

--Nano 18:18, 26 May 2006 (PDT) Exactly! Glad someone else agrees. I think this may be what Spy is trying to say, though. He just highlights the nodes that are being controlled by people with a special admin key.

Clients

Note to reporters: The information contained on this wiki page is not official documentation.

Clients are Okopipi users. Clients submit spam reports to Okopipi, where the spam is analyzed and reported.

Handlers

Note to reporters: The information contained on this wiki page is not official documentation.

Handlers provide the link between the clients and servers.

  • Handlers are servers that act as routers whose bandwidth has been donated by various people in the community. Our goal is to have hundreds -- maybe even thousands of handlers. Handlers consist of dedicated servers, websites donating their extra bandwidth, and small businesses.
  • Each Okopipi only knows about a couple of handlers, ensuring that a spammer will not be able to take down the entire system. When an Okopipi user submits a spam report, their client randomly selects one of the handlers they know about to submit the report to.
  • Each handler knows about a couple of other handlers, so the spam reports keep on getting forwarded from handler to handler.
  • Eventually, the spam reports reach handlers which are owned and operated by Okopipi administrators. These are the "administrator nodes". During periodic intervals, the main Okopipi server(s) open secure connections to the administrator nodes to download the spam reports.

This system was proposed so that a DOS attack will be very difficult. At most, a spammer will be able to take down a bunch of handlers, because each client only knows about a handful of handlers -- when there are hundreds (maybe even thousands) of other handlers serving other clients. We hope that spammers won't be able to take down the main servers, because no one will know about them.

Further details, ideas, and concerns

Personal tools