Alex Bennee wrote: > I mean where do you get them from before adding them to the GTKG repo? > Are you recycling data from another project or are we generating the > list within the GTKG project?
Offenders are added as they are discovered. Except for some initial set years ago, none of the data is provided by or taken from any third-party. > > > Are there any distributed/central block list repos that would be worth > > > implementing for GTKG? > > So unless you want to use LimeWire's block list, fully distributed updates > > would not work to well. > Surely there should be a platform agnostic block list that is used by > all servants? In theory, yes. In practice, no. As long as others don't provide a clear explanation why they are blocking some specific range. I trust anyone else's judgement if I have no idea how they are working, whether they understand the protocol in-depth, whether they know what can be spoofed and what cannot, how much related experience they have, how carefully they verify each case and what they consider abuse anyway. This isn't rocket-science and everyone makes mistakes but I'm not going to blindly follow someone else here. So using anyone else's list is no option at all. As a user, you have, of course, the right and the freedom to use whatever block list you like. > I assume there must be some kind of key signing involved to prevent > pollution of the block list by 3rd parties. Sure, you have to use cryptographic signatures, otherwise you can't distribute them peer to peer. That also means only people who have one of trusted keys are able to publish updates. > One option was PeerGuardian (I only mention it having seen it fly by > in my news feed today). I was pondering if there where any open block > list projects. I don't see PeerGuardian respectively BlueTack as an option at all. In my opinion, they are just paranoid, self-pleasing cowboys. They are like people whose only tool is their hammer. > > An alternative would be using a UDP crawler to search for gtk-gnutella peers > > and send them update notifications. gtk-gnutella peers could also try to > > remember other gtk-gnutella peers with high uptimes and query these for > > updates > > if they haven't received any in several weeks. > Seems a little heavy handed. I think it's preferable things pull when > they see rather than seeking out everything that is out of data. I'm not sure what you mean. I wasn't saying the peers themselves should crawl. A dedicated crawler, just like GhostWhiteCrab, would do that and everytime it comes across some gtk-gnutella peer, it delivers the newest update notification. The point is that there's no gtk-gnutella network. The only common network is Gnutella but gtk-gnutella is rare, so you seldomly come across another, especially as they don't crawl. So the crawler would be a complement to this. Other options include some kind of DHT or a secondary "network" of gtk-gnutella peers whereas this network is not an alternate to Gnutella and has no intented clustering as implication. It is simply a kind of news (notification) channel. In other words, it's a completely separate application. Maybe you think "but why can't we just use Gnutella". Well, that's because Gnutella does not lend itself to this kind of application. > Would it be possible to add an extension to reply packets to let it > the client know what version was the latest one of the blocklist? Piggy-backing such information is just a hack and may overall be far more inefficient and ineffective compared to what I outlined above. There may be peers a lot of peers which never see reply packets (I assume you mean query hits) because they are mere content providers and otherwise passive and again due to the rareness of gtk-gnutella, you might seldomly see results from it. It's not like every gtk-gnutella peer shares anything at all. -- Christian ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
