> PROPOSED SOLUTION: > 0. ULPRs. (Node) > Ultra-Lightweight Persistent Requests are the basis of all that follows. > Essentially this is a means to limit the load caused by polling clients > such as Frost, to get messages to the clients faster, and to make messages > which have been lost by being in the wrong place findable if they are > popular. > > Issues: If this is deployed without the below, it will only make spam > easier, because the messages will be propagated even faster. > > 1. True Web of Trust. (Frost) > Frost must publish the list of users marked manually by users. So if you > trust a particular user, you automatically have (a slightly reduced) trust > in the users that he trusts. If you then mark somebody as not trustworthy, > Frost will ask you if you want to reevaluate the people who trust him, and > indicate how many/which people you have marked as bad are trusted by those > posters. > > Benefits: For oldies, faster propagation of trust in newbies etc. For > newbies, if we ship an initial list of likely to be trustworthy posters, > much faster assimilation; they can have a fairly usable Frost, minus spam. > But we still need some experienced people to watch the boards for posts > from newbies. > With a WoT, if you accept to read the new-comers, you accept to read the spam. So in the end, you risk to end with no-one reading anymore the posts from the newbies.
> 2. Outbox Polling. (Frost) > Frost, or some similar app, can poll outboxes of specific users rather than > watching a global KSK queue. These might be global for that user (encrypted > for specific boards), which might work well with ULPRs, or they might be > per user per board. > > Prerequisites: ULPRs! This will generate a lot of traffic otherwise, but > with ULPRs it should be feasible. > Hm, stupid question : What are ULPRs ? > Benefits: For oldies, Frost will work efficiently and is completely immune > to Message of Death attacks and similar KSK queue DoS'es. Note that we > still need a means for newbies to introduce themselves, initially this > would be a KSK queue. > Issues: Currently threaded view with CHECK disabled works relatively well. > It doesn't require explicit trust settings. Maybe we should have automatic > marginal trust when you reply to an untrusted post, unless you tell Frost > not to? > > 3. Thinkcash/Hashcash introductions. (Frost) > Each poster can publish hashcash/thinkcash puzzles. The puzzle when solved > yields a key, which enables a newbie to send a message to the poster. This > message will be seen regardless of trust settings, and the poster will be > given an initial marginal trust (OBSERVE??). After that, if nobody marks > the newbie poster as bad, he can post freely, and his messages will be seen > by the people who trust the original poster. > Hm, and the hashcash should be sized to take how many time ? Because if it takes less than 10 minutes, spamming is possible (some messages each 10 minutes can be really annonying), and if it takes more than 10 minutes, I'm note sure that most of the users will wait for the end of the process. > IMPLEMENTATION > > I may implement ULPRs after opennet is ready. The rest will have to be > implemented by Frost devs etc. Hm, can I suggest a fourth idea ? 4) Blacklists : - Let the user put the messages they don't like / the spams / troll's identities in a blacklist. - Let them upload on Freenet their blacklist. - Let the other people filter the messages with this blacklist (and possibly some others to make the filtering as good as possible) Of cource their software will have to refresh the list(s) as often as possible. I think that 'SubscribeUSK'[1] in FCP can help. Benefits : Less annoying for the users, easier to explain to the users, and compatible with the current Frost boards. Issues : Between the spam sending and the blacklist update, there may be a while (but as I said, SubscribeUSK[1] and many blacklists can probably help to reduce this delay). Another possibility would be a whitelist mechanism: Some people decide for the others what they can see (Like IRL in sum ;). But it would be as annoying as the solutions 1 to 3 for the users (probably even more). -- [1]: http://wiki.freenetproject.org/FCP2p0SubscribeUSK
pgpRx1GhlkBoM.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
