FEATURES WE NEED FOR A GOOD FORUMS OR DISTRIBUTED SEARCH SYSTEM: 1. Context-specific, globally readable, scarce announcement keys that does not depend on hashcash or CAPTCHAs, and that works on opennet. 2. PSKs. 3. TUKs. Maybe; useful to speed up stuff. We certainly need it for distributed search.
Any useful forums system will only have a limited number of contributors at any one time. This is less true of distributed search, but lets assume that divides up by topic as well, possibly using the same groups as the forums. IMHO in terms of user experience and the tradeoff between spam and censorship, for Freenet purposes, what we need is: - Announcement of a new identity is costly enough that DoS attacks are hard. - DoS attacks are quenched automatically. - Trolls can be ignored individually. Hence, for forums: - Scarce SSKs are used for announcement of a new identity, within a specific context. - Each identity creates a PSK group. - We initially watch the PSK group of every identity. - Non-full but non-empty PSK groups offer us membership, so that we join 3 or so groups. - We choose a minimal subset of the PSK groups that covers all identities. - When an identity starts a DoS attack, we exclude him from our PSK, and distribute new keys. - If the owner of a PSK group doesn't do this, we drop out from that group. For distributed search: - PSK group: A group of a number of index owners, maintained similarly to a forum. - A limited number of keys are inserted under the PSK, using a hash prefix rule, to TUKs. The hash rule, and therefore the number, is determined by how long it takes to insert them and the expected time between revocations (= moving to a new PSK). - The keys contain: -- The current list of contributors and their indexes (with signatures from the "owner"). -- A Bloom filter, within the hash prefix, for each of the indexes. - To search for a keyword: -- Fetch the Bloom filter for the specific hash prefix you are interested in. -- Check the Bloom filters. -- Fetch any matches from their individual indexes. - The individual indexes are TUKs owned solely by the individuals, are inserted directly under the keywords, and are normally short files, but can be trees if there is a lot of data. They are multiply inserted just as anything else, and under the top level are splitfiles. - One identity is likely to be a member of several PSK groups for redundancy and trust. They will join, expel malicious members, and leave automatically. They will however maintain only one index each. The tools we need: 1. Scarce SSKs. (There are severe problems with CAPTCHAs, hashcash and bitcoin as announcement mechanisms; we need something else) Scarce SSKs are simply slow fire and forget inserts with a per-link limit on how many can be handled per unit time. We reject incoming requests which violate the rules, otherwise we queue them. We prefer our own inserts. Even if we actively DoS, our peers will only let a few of our inserts through. The limiting factor is our connections. On darknet, this is fairly serious. On opennet, connections are easier to get, but at least somewhat costly to maintain. So we simply require that a connection has been up for at least, say, 30 minutes, before we will accept a Scarce SSK announcement on it. This means newbies can't post immediately, but is likely okay. Some sort of once-per-IP-address token from announcement might be a possible enhancement to allow immediately relaying (and sending) SSSKs. 2. PSKs These have been discussed elsewhere. The key feature here is simply that we can post to a sequence of keys if our pubkey is signed by the owner. 3. TUKs These are network-level USKs: - They have a sequence number. - They are implemented as PSKs, where the verification rule can access the sequence number. - When requested, we automatically subscribe for a limited time, as with ULPRs for regular keys. - The request will normally continue until the HTL runs out, rather than returning the first match. - However there is a time-based quenching mechanism as with ULPRs/RecentlyFailed. - They are inserted to multiple locations for redundancy and protection against malicious nodes. They are automatically healed by the client. - They may be revocable, by inserting sequence number of MAXINT. This may require unusual conditions.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
