support for bit-torrents/bitprints/multiple networks or whatever
 

Bad idea, right? But as long as other clients are doing this and these are catchwords that attract new users, gnutella should force the issue by adding support for the plugins that allow it. Let the other devs come to the GDF and complain, and maybe the truth and fair treatment will get more respect.

I can guess that the evolution will be like the automatic queries. If something DOES work (like a merge between torrents and magnets perhaps?), all the better.

If other networks can plunder gnutella with their 100:1 leeching, why not give gnutella users the "do unto others BETTER than they do unto you" opportunity.

LW probably has already developed ways to add the plugins like giFT already developed, and shoild at least be allowed to "keep up" with the competition.

eh? :p

No. People on P2P forums are beginning to realize that multinetworks program sucks and usually have poor implementations of all the networks. Let LW continue to show leadership by not going crazy about a fool trend began by poisoned and shareaza. Let them not waste work on other half baked implementations and get real work done on gnutella. Other might try to catch up on the new gnutella technologies implemented in LW, but users will notice the difference even if some are not (there is a % of stupidity everywhere, it can't be avoided, look at morpheus supporters that come here). I'm personnally admiring innovators, not followers and imitators (original is often the best).

:cool:

Don't forget KCEasy, and recently, Kiwi. I hope you're right about others realizing how harmul multiple networks can be, though the discussion about LW 4 on Slyck --despite juggalo and Greg Bildson's efforts--shows that there is a long way to go.

I hope filesharing is not at the same level of evolution as railroads: companies eventually agreed on track guage, but even today I suspect some areas still set their tracks so only their cars and locomotives can run :(

Do you think there's a fair way to set the entry level for developers to access gnutella? If so, I'd ask for a feature request to "block Vendor." Right now I keep checking if a connected vendor supports Browse Host or has a >0 QRP. If not (repeatedly),and the messages I/O is high, I start itching to "block Vendor."

. . . and if Dave doesn't start correcting his users whoi probably think he came up with the "What's New" and other devs, I'd start blocking ACQX too. :mad:

Note that BitTorrent is not by itself a P2P network with search capability. You can't search in BitTorrent, you can just download from swarmed BitTorrent locations provided that you have a

BitTorrent URL and that the initial BitTorrent source indicated in that URL is permanently accessible (on a true web server).

BitTorrent is then a very useful system to help a website reduce its output bandwidth, by letting its downloaders becoming assisting mirrors for the web content.

BitTorrent will be fantastic for contents that you can search in a central server that hosts tens of thousands of files, that are heavily replicated (I see a good application of BitTorrent for the distribution of free software, on websites like freshmeat.org or OSDN/SourceForge, if they can't upgrade to support more transfers at efficient transfer rates: it may become critical in some near future for these central servers to work with more and more broadband users that want to download at megabits/s speed).

BitTorrent would be also fantastic for distributing streaming contents via HTTP (for example free radios on the web), without paying lots of money to very expensive CDNs (Content Delivery Networks).

In the future, if there are good central servers with lots of contents where we could search for BitTorrent contents, it could be a good addition to LimeWire to add a component connecting to these servers (if they accept the workload for these searches). But for now, it's premature (unless we just integrate in LimeWire the BitTorrent client where you import an BitTorrent URL found on the web.

The immediate need is not BitTorrent but a wider support of Magnets on web sites (Magnets are concurrent to BitTorrent, but can perform more things, as a Magnet can also be made to search in Gnutella).

Ya P2P is filled with profitors and opportunists people. Dave of acquisition is one of them. I laught loud when I read the thread 109.2 that acquisition is a one man work. LOL :D ! At least in market share Dave is very low compared to morpheus and shareaza. There will be natural selection and those apps are bound to extinction sooner or later (a lot of chances are that they'll die before LW). BTW I'm a reader of slyck forums as well and saw that thread. I can say that opinions about gnutella and lw are much better now than they were last year.

LimeWire already fully supports bitprints since long for downloads, it now also supports THEX tree data for recovering files with corrupted sections (notably during swarmed downloads, a good point to defeat hackers trying to break the contents of some popular files with fake/bogous data inserted randomly within swarmed downloads)...
Now with THEX trees, TigerTree Root hashes, and SHA1 content hashes, swarmed transfers are secured: you are sure to get a clean copy from popular downloads with many sources!

Interesting. I tried some 'magnets' from here http://www.leeware.com/magnet.html (as discussed here ), and thought they didn't work because of some incompatibility. Would be nice if they did work.

Which reminds me--I meant to request that I could create magnets from a multiple file selection in the library.

In response to your earlier post about torrents, are there good reasons to not allow torrents to be used through LW? I recall the earliest posts in the mailing lists were about sharing bandwidth, much as you described with torrents. If this would take away dev time, I could see the argument against, but if they are easily 'ported' /integrated with the magnets--then they seem like a reasonable request.

I think dave is quite right in Acquisition being an one man project, but he always forgets words like "interface", for it is an one man INTERFACE project. I assume he is not overly happy to have me asking when he will integrate the new features of the LimeWire core into Acquisition time and again, but that is how it goes: Truth comes back through people. :)

Only thing really bugging me about it is, that he didn't GPL the interface-code, for GPLing it would have improved most OSX p2p-interfaces, I assume (while he'd necessarily have to stay ahead of the curve, but could use improvements by others...). Somehow I don't overly like pipelining.

The bad thing about Acquisition, despite it is a good interface, is that its version numbers do not reflect the internal LimeWire core version number.

If it said "Acquisition 109.2 (LimeWire 3.9.2)" it would be more clear. I don't know exactly which options of the Limewire core it supports. And I have no time to check its sources (is it open-sourced, as required by the LimeWire GPL licence?)

I could say the same thing about "AcqLite" and "AquaLime", or for "FreeWire" (no more interest for it, users can get clean and free LimeWire Basic, and get real support for it with the original), that should offer a way to get the sources for EACH of their published version.

Acquisition has its core open sourced, but not the interface (something bout pipelining making it unnecessary to open the interface-code)

One bad move is, that it doesn't specify in the Venor-message, that it is Acquisition. The current version announces itself as "LimeWire/4.0.2".

I understand now why I haven't seen newer acqx nodes. Dave IS AN ***. I told him 50% of acqx users were leechers and few of them were running UPs (things verified by me and Stief) and now we can't even verify the behaviour of acqx (because Dave changes settings in the LW core). Now Dave merits to be slammed, what an idiot!!!

Acqx su*cks!

I already asked him, if it was a bug. The answer was, that it is intentional. He didn't react to further questions about this.

But You'll have to excuse me for quite liking Acquisition, as it still quite beats LimeWires usability. A LimeWire lite with only the most necessary features (or a Konfabulator-widget for which I posted the request in the LW-OSX-Board: http://www.gnutellaforums.com/showth...threadid=25614 ) would be likely to make me switch back. Problem is: I want a good working, sleek app, and Acq is that. I can for example "stream" mp3s over Gnutella with it via the preview-function (using iTunes) (as long as I get enough speed) with a single click.
At the moment I mostly use LimeWire to create magnet-links.

PS: I only found it out by chance as I tested, if Phex is able to connect to Acquisition through my dyndns-account (works) and just saw the LimeWire vendor-message, but at my dyndns-account and with my custom Acquisition port.

You shouldn't bother with ACQX and Dave's interpretation of the GPL. It makes you only feel anger and you risk to die of heart attack. It's only a matter of time until LimeWire's UI will catch up and will hopefully outrun ACQX in some way. Just lay back and enjoy the upcoming novelties and possibilities. An important decision was made last week but I cannot tell you more yet, sorry. :cool:

BTW. Arne, Dave contacted me last week and he said he'll include the missing classes in the next release of the "Acquisition-Core"

Now you got me excited :)

Even the small changes I saw in the UI (new splash-screen for example) showed my, that I can expect LimeWire to get far more usable.

Good to see, that you are now far enough with the network-code, that you can actually work on the interface again. 3kB/s network overhead for an ultrapeer sure is great!

Rodger: I do not care a lot about Dave, it is just that some support him blindingly and spread some propaganda. He is like a few other dozen P2P "devs" that abuse gnutella and LW. I'm so happy LW clusters themselves and limit the dommage by not allowing many foreign vendors slots!

There is a lot of knowledge to spread around to kill misinformation, and still many myths to kill ;)

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.

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...

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é :(

TrustyFiles legal status
 

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.

Re: TrustyFiles legal status
 

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

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.

Authenticated RSS/torrent as a trusted show-season-episode delivery mechanism
 

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: http://www.gnutellaforums.com/showthread.php?t=62814
- Forum: https://www.gnutellaforums.com/polar-skulk/

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.