C'est vrai--Let's keep the knowledge flowing . . . and keep crediting those who contribute real benefits to gnutella users.

Dave: You harm yourself and your users by taking more than your share of the credit. Roger, Sam, Gregorio, Phillipe, Jens-Uwe and many others I am only dimly aware of deserve credit. You know best who to credit, so let your users know too. You corrected those who bashed gnutella, so do the same for those who bash LW.

(Arne, I know you try: do you get much credit for your contributions?)

If ACQX is really using the 4.0.2 core, we'll see how many people complain about too many connections as an UP.

Politics--bleagh! (RAZA is taking another hit in the GDF this morning--hope Phiippe's java optimization gets more attention).

Back to the topic: so--multinetworks (bad), which leads to clustering/ "Good Leaf" definition.

Should we ask for "Block Vendor" with the ability to identify false Vendor messages?

Currently LW clusters naturally, but bans itself from taking all the slots, right? LW will not allow *itself* to use all leaf slots--two will be reserved for non-LW leafs, but as many as 15 *could* be connected if I understood Sam correctly here http://groups.yahoo.com/group/the_gdf/message/19704
I agree--this is a very generous policy.

The definition of a *good* leaf is less clear to me
trap_jaw wrote a "greedy client" patch, which I gather has been adapted and works quite well. Is this enough?

I'm inclined to think the slow process of the GDF and the proven cooperation of LW to encourage other developers is sufficient.

Ask for "Block Vendor", or just let it be?

(@stief: I got some, and for GnuFU I got quite many positive reactions (and when I don't get them, I can at least look at the visitor count, which just topped 3000).

The translation of Acquisition was rather hard work, which was hard to do when we first had to convince Dave to make if fraggin possible.)

I think it would be better to do the blocking dynamically than just specific vendors, but it would be nice, if specific version-numbers could be blocked, so that especially greedy or buggy versions could be taken out of the net, while the client can still get back to adopting good practice.

__________________

-> put this banner into your own signature! <-
--
Erst im Spiel lebt der Mensch.
Nur ludantaj homoj vivas.
GnuFU.net - Gnutella For Users
Draketo.de - Shortstories, Poems, Music and strange Ideas.

Among these, only Sam is working for Limewire. All others are generous contributors. Sam was a contributor too last year before he joined the Limewire crew working in New York.

Our common policy however is to keep being generous with other servents, under some limitations to protect LimeWire users from excessive abuses, in the hope that LimeWire users will still benefit of a good interconnection with other servents that also have interesting contents (BearShare notably and GTKG, Swapper.Net or MLDonkey or MyNapster, but also GnucDNA-based servents and even Shareaza for which we still offer a mutual access even if we control their greedy behavior and limit the access due to lack of support).

Extreme measures are taken on really malicious and leaching servents (Xolox for example) that abuse all other good or average servents without offering any assistance to maintain the network or to discuss the interoperability issues within the GDF. Some other servents are also abusing the GPL, such as Poco in China (abusing the gIFT's GPL; well gIFT is not even a good implementation of Gnutella and its poorly coded and we need to maintain it under control, without rejecting it completely).

For LimeWire open-source abusers, there was the case of FreeWire and AtomWire. But they are nearly extinct due to their bad stability and absence of maintenance or support, unlike AcqLite and Acquisition which are very active.

I still don't know what is "Kiwi" which has started since a few weeks to come regularly. I have no opinion on its quality.

I would like to have opinions of LimeWire users about what they get from remote TrustyFiles servents, which are now very active. I hope this newer servent is correctly maintained. The next months will learn that to us, or simply LimeWire 4 will beat it...

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Philippe, Trustyfiles (also abusing the GPL of giFT for fasttrack support) and Kiwi alpha are GnucDNA clients meaning they harm Gnutella as well.

Désolé

__________________
Liens d'intérêt /Links of interest:
Gnutellaforums en français /The House's rules you have to respect / First search the forum, then create a thread / Free software alternatives! - Logiciels alternatifs gratuits!/

Please note that much of the network code in TrustyFiles 2.2 was rewritten for better performance and stability. The code is now 100% internally developed and does not use giFT or gnucDNA.

Marc Freedman
RazorPop, developer of TrustyFiles

@razorpop: That's good to know for one thing and very sad on the other hand, because you don't give it back to the community that way.

Always remember you wouldn't have been able to start up without the community and open-source. Allow others to do the same.

It is like the old truck driver, who teaches a youngster how the biz goes, because there also was an old truckdriver for him once, who taught him how to survive out there.

__________________

-> put this banner into your own signature! <-
--
Erst im Spiel lebt der Mensch.
Nur ludantaj homoj vivas.
GnuFU.net - Gnutella For Users
Draketo.de - Shortstories, Poems, Music and strange Ideas.

Well, some of the people who are/were a little more involved with the GiFT project (e.g. J. Ashton) already stated on Slyck that they could prove this is a lie - and I tend to believe them.
That aside there were announcements from Razorpop - while they were working on TrustyFiles 2.2 - that it would be open-source like the GPL required it to be. A few weeks later they release their client and state the code in this version is all theirs they just rewrote a couple of thousand lines of code. - Really, you don't cough up a Gnutella implementation just like that.

I wish someone from the FSF or so would offer some money to sue those Razorpop people because ripping of OS technology is not a respectable business modell and people should be warned not to use TrustyFiles. You can have the same features from people who don't steal other people's work (like BearShare, LimeWire or even Shareaza).

Marc and Razorpop are a*shol*s. Really. You do not respect GPL and LGPL and then you are making unstainable big lies... Marc, there was a thread at slyck.com when TFS 2 went live, you participated and left once we asked you legal questions about the legitimicy of TFS. You said you knew nothing, as it was some kind of employee that was writing TFS. This is bullshit, I'm sure by your forums at razorpop that you are the programmer. I know you use gift and gnucdna, I just don't know what you did rip as opensource software for bittorrent support (gift?).

PS: for those who don't understand what the fuss is all about: AVOID trustyfiles!

Ciao

__________________
Liens d'intérêt /Links of interest:
Gnutellaforums en français /The House's rules you have to respect / First search the forum, then create a thread / Free software alternatives! - Logiciels alternatifs gratuits!/

Regarding the original topic of the thread:

There will be bittorrent support in LimeWire. It will not happen in LimeWire 4.2 but possibly in 4.4.

Some LimeWire versions with early (but nontheless already working) bittorrent support already exist.

On a slightly differnt track

The objective is to set up a torrent based publishing mechanism where the audience can be sure the source is trusted while removing the need for the RSS feed or a tracker to be hosted on a public server.

The question is which bits don't exist yet and how could they be achieved?
1. It starts off with the generation of a strong PGP key that is held by, the publisher (or moderator);
2. Next an "authenticated" RSS "feed" is generated as a container for torrents related to the show;
3. The first episode of the show is added as a torrent to the RSS feed;
4. The feed is published over a gnutella style of hosting/propagation so people can go to “the search engine” and do a search of "the show name" (this means that once published into the network the host would not need to exist any more). This takes the role of the tracker and makes the definition of the torrent un-shut-down-able;
5. The search would return the list of season/episodes for the authenticated feed and automatically start downloading the listed torrents;
6. As new shows are developed they are converted into a torrent file and the "authenticated" RSS "feed" is updated with a new version number in the title and uploaded to the network;
7. The client would “become aware” of the new episode through the "authenticated" RSS "feed" and automatically download the torrent to the targeted directory. This would allow the new episodes to just appear in the directory for the show;
8. If necessary the publisher should have the facility to delete and replace an episode. This would allow an early version of an episode to be replaced with a better quality version;
9. If at the end of the show’s run the "authenticated" RSS "feed" available on the network would contain all the torrents for the show and when added to the client the torrents would be downloaded in the correct sequence.

The above steps should be automatic i.e. aside from coming up with a unique show name and the content of the show itself all the published should have to do is direct the client at a watched directory where new content is placed for publishing.

An option would be useful to allow for restricted publishing of the "authenticated" RSS "feed" by switching the public/private key pair. In this way the key could be shared with a family member to allow sharing in a restricted format.

An additional component would be the synergy of operating this in combination with an IP masking tool.

This sounds useful, but why would you want to use torrents?

A magnet-link with a working first source and/or an ip-cache libe the one at freebase works quite well.

For a first model of trusted lists, you don't need cryptography, but simply a web-address which gives you the security, that the owner of the website is the publisher (which lacks a web of trust, but works as first step).

And when you're at that, you can just use the decentral content distribution of Phex: http://wiki.phex.org/Decentral_Content_Distribution

It downloads new files with every start of the program (because downloading more often didn't seem necessary, yet).

For download it uses magnet-links and Gnutella.

You can try it out by downloading one of the Polar-Skulk programs (modified Phex'):

http://www.phex.org/wiki/index.php/D...s_into_the_Den

Besides: We need people who search for free files and publish them decentrally via Phex.
What you need is a flatrate, a dyndns-host and a 24/7 Phex.

More infos:
- FAQ: Welcome to the Polar Skulk (Infos & FAQ)
- Forum: http://www.gnutellaforums.com/forumdisplay.php?f=119

What you need to do as of yet to publish a show is:

- Sharing only your shows.
- Putting the new show into your share along with the others.
- Click "export" in the Phex Libraray and choose "include your IP".
- upload the exported file to your server.

When you're uploading for the first time, you also need to inform us, that you're publishing the files and that you'd like to have them included in the Decentral Content Subscription.

If you instead want to create your own feed of content, you need to tell your visitors to add the URL of your uploaded magma-list to their Phex' (this needs fairly copetent users as of now, but if you ask in our forum, if that could be made easier, our main dev might add an easier way to subscribe to a new feed. It's been discussed for some time, but there never seemed to be enough need of easy adding of feeds to include it _now_ - instead of other features).

All the possibilities of doing this are there (except direct FTP-access via Phex, but that shouldn't be too hard either), it just isn't polished, yet.

__________________

-> put this banner into your own signature! <-
--
Erst im Spiel lebt der Mensch.
Nur ludantaj homoj vivas.
GnuFU.net - Gnutella For Users
Draketo.de - Shortstories, Poems, Music and strange Ideas.