Here is an interesting analysis of some things which may be relevent. The correspondence about the bug report starts at the bottom of the page.

http://sourceforge.net/tracker/index...67&atid=104467

This doesn't really support anyone's views in particular, but illustrates that some of the technical issues are complex.

Nos

You did not get my point. The Bearshares are clustered together, but the bearshare cluster as a whole is still perfectly connected to the gnutella sphere. that means every XoloX client can connect to a Gnucleus or LimeWire client that is connected to Bearshare. Therefore, search packets of one of them do reach the other, and indeed, Bearshare and XoloX clients CAN download from each other.

What you are doing is a completely other thing. You do not block Bearshare. If you only did that, i wouldn't have said anything. You guys are creating a totally different network, thereby blocking every gnutella user who is not willing to join your ideological crusade. by blocking one or two clients, like vinnie does, the network as a whole stays perfectly connected. how many clients do you think you are blocking? counting all the discontinued and experimental ones, and every noncommercial client that is not opensource, i guess it will be about ten different clients. for what reason? once again, i can't see anyone abusing the network. i do suspect vinnie of doing so, but i have no final proof for that, and even if he did, he has never gone as far as splitting completely off gnutella.

they create clustered subspheres, right. but they still stay connected. and there is no proof at all that they take files away from other vendors and clients. actually, using gnucleus, i happened to download from bearshare at multiple times.

please, nos, do not tell me what i should be happy for.

OK, apart from those bearshares that are too many hops from the edge of the bearshare cloud. But I take your point.
Well, there are too different things going on in that opensourcep2p gnucleus client.

I haven't seen it, but I understand that one option is to stay on gnutella and just block on an ID basis, eg user can choose just bearshare, or as Anonnn urges on the web page, block all commercial vendors, or whatever they like. I believe the user types in the string.

The other option is use the other 'network' or 'opensource' which should be enough to block any non-configured client, but in practice I don't think this is proven. So in addition the gnucleus client blocks all the known commercial clietns based on vendor id.

I think that option 1 is a side-effect of the lack of certainty about the effectiveness of the strategy of changing the connect string header. And since it needed to be implemented to block fully on the opensource network, the 'extra benefit' is that it can be employed on the gnutella network as well with no extra programming effort. So he let the user decide.

So now you are arguing against the second network - the second network doesn't block anyone from using the original gnutella network. It leaves the original gnutella network intact, save for the loss of users, who maybe would leave anyway. It is arguable.

Well, in one case, the gnutella network, it is up to the user, could be any number. I think probably only BS, MRPH, LW at the most, mainly just BS.

On the new opensourcep2p network, at the moment, probably right. I doubt that there are that many users on that network anyway. [wildly speculative mode]Interestingly the <A HREF="http://www.limewire.com/index.jsp/size">graph at limewire.com</A> does show a drop around the 20th March when Anonnn launched the idea, of around 50k users .. but I think this must be coisncidence - gnutellaforums didn't get 50k readers that day. There is already a decline evident preceding that date, I'd say about 40k users over half a week immediately before his announcement. This is followed by the sharp drop of another ~50k at 20th March, and it has been more or less stable since then.[/wildly speculative mode]

Maybe the decline of 40k users in half a week would have continued had Anonnn not made his interesting announcement? Who can say?
[QUOTE] for what reason?
<snip snip snip>[/QUOTE
Reasons covered earlier in debate and on <A HREF="http://opensourcep2p.sourceforge.net/">website</A>.
Yes, I can download from BS using non-BS clients, it's good. On the other hand, some clients have such little success now (read '0.4') that I don't bother using them. And that was a sudden change. I think perhaps driven as much by limewire as BS the date corresponds more with the introduction of ultrapeers AFAICT. I don't really know.

So I don't know, it seems to me a good many of the older clients are blocked from the gnutella network. I think if the opensourcep2p idea isn't killed quickly that people will alter a lot of the older clients to use that network - after all the older and simpler the client is the easier it would be to change. Maybe more clients will work successfully on the opensource network than work successfully on the gnutella network.

OK, I didn't mean you specifically, I meant the gnutella community in general should at least take some comfort from the fact that we want to keep improving the (opensource) gnutella clients and protocol, even though we don't want to connect to the existing commercial clients any more.

Nos

Here is a link to another thread, this one about Black Holes

http://www.gnutellaforums.com/showth...?threadid=9192

Nos

more arguments for an existing GDF lobbying

- GDF was/is long hidden from public, mentioned on no vendor homepage, still not listed in groups listing
- a documentation of protocol was not available long time, still chaotic
- support of new developers does not exist, of course GDF members have a working client already
- dissing against Xolox was unfair or tolerated, communication was not tried/wanted by GDF
- clustering takes users/files away from other (independent) vendors, superpeer clustering is a self created bottleneck
- clustering and blocking was tolerated for GDF member Bearshare, now also for Limewire
- proprietary messages and undocumented extensions from Bearshare are tolerated
- spyware/sumware in Bearshare and Limewire are tolerated
- public statistics from LW's crawler are inacurate, mode changes without notice, no statistics for everyone
- Bearshare and Limewire saying they have the best Gnutella client and being "the establishment"

Afisk, could you give an example please?

We closed already two or three threads... we cannot close all!

I think the best way is to point out where the other is not right and discuss it!!!

@ all

BUT WITHOUT FLOODING PLEASE!

Morgwen

Gnaaaaaarrn! Did you at least read my posts about how ultrapeers and clustering work? no, of course not. Ultrapeer is not a fiendish plot to take over the world, and Ultrapeer clustering is completely sensible! You don't present any proof of how clustering takes away users or files from other vendors. That's a very nice conspiration theory, but just repeating the old prejudices, rumours and lies over and over doesn't make them real.

And what has the GDF to do with spyware in Limewire and bearshare? If you don't want it, don't use it! Many people accept spyware if they get better search features - see KaZaA. it is not a matter of the gdf to block them. if the users don't want the spyware, they can use another client!

the GDF is far from perfect. but on this level we cannot discuss about it. we won't achieve anything if the same unproven accusations are posted again and again and again.

afisk, nice PR. abaris you can't even imagine that your clustering, sensible, complicated ultrapeer idea has a selfcreated need for clustering and different concepts would not have to cluster away from other clients (from files!). At the end more of your GDF clients will have to cluster together to create a huge network. At the end you create a two-class Gnutella (GDF cluster vs independent developer); other devloper might decide to use different superpeer concept and cluster away from you too because you did hurt them. Spyware, you like them and tolerate it - have fun with your greedy partners. Inoccent users need more information against your scumare. Vinnie's strange ideas - you make him one of your best friends, enjoy the dislike. Oh and the accusations against Xolox again. Sorry they were never proofen. I doubt even Phex was that unhealthy. I feel the GDF is too much into politics and too less about facts and fairness.

GDF looks like lobbying for me, selfish, self-overrated and sloooow. Bearshare & Limewire are best friends to protect their commercial interests, salted with PR.

Different clients will come (maybe Xolox). We will hear a lot of bitching and inefficient GDF will need another 6 months to make small steps fordward, until they move equal, beautiful tinker. (I'm only sorry about Limewire, they seems to have some nice people, but choosen a greedy aliance with Vinnie)

Let's end wasting time here, Gnutella development needs to be splitted!

GDF lost my interest.

I wonder why nobody from the GDF tried to inform the Xolox developers about this? If this is/was such a big problem send them a mail and tell them what you have discovered! Now they can investigate it too, and change it if necessary!

Also funny is that the only source for this is Vinnie and we all know what he thinks about Xolox! Did you investigate it too? I wonder why no one of the other developers said something about this or did I miss something? In private the developers said its no problem! I am no coder I don´t know what to believe but I know if NOBODY besides Vinnie confirm this, I am not going to belive it!

About the protocol documnetation, I wonder when 5 or more FULL time coders have no time to do it who have it??? But you don´t need to do it alone, there are other solutions hire moderators, like you have done it already with Mike Green, who can do the documentation! If Mike cannot manage the work alone ask one or two more coders - the GDF is FULL of them!

Btw what do you think about a new protocol?

Morgwen