Can something be done to prevent ShareAza hosts sharing 'Rubbish' files on Gnutella network?
 

As unhappy as I am to point this out, I think it needs to be said so hopefully something is eventually done about it.

The most likely hosts to share rubbish on the Gnutella (G1) network are ShareAza hosts. By rubbish files I am referring to files such as such as info, VOB, m3u & torrent files.

Investigating spam via Gnucleus even with a decent blacklist still shows files that are of no use to anybody who downloads such files.

The gnutella network needs good files to be shared (the more the better), but surely there is a method to prevent certain types of files to be shared on a network not suited to them. Easily done IMHO (filter files added to G1 shares), but question is whether the Shareaza devs are willing? :D

These are just users sharing their torrent download folders with scene releases and complete albums. Would you really prefer they didn't?

Just add .nfo .vob .m3u .m3u8 .torrent etc. to keyword filter.

I realise this but presumably ShareAza can separate shares per network? I haven't used the program in several years so am not aware. Torrent files are irrelevant to the Gnutella (G1) network. And are probably irrelevant to all networks except the torrent sharing world.

Over a year ago I had a disagreement with BigJx with the WireShare project about the word torrent being filtered (& some other words. My suggestion was a separate filter for torrents (not a difficult task & easily designed to remove replication of content.) But then, using WireShare's Lime basic torrent technology possibly equates to using Newtella, Toadnode or Xolox on the gnutella network; far out of date. Unlike the gnutella network, torrent technology has advanced every year.)

Has Shareaza updated G1 since http://www.gnutellaforums.com/sharea...tml#post148291? To my knowledge, no. Please enlighten us if this is not the case.

Well I for one sure wouldn't mind these .nfo files, you see as trash. They contain info about ripping method i.e. I would very much prefer an .mp3 file converted using LAME from a .wav ripped using EAC rather that WMP.

Same way as an .m3u would list exact file names used on the CD to .mp3 release.

So there are two of you listed file types, that actually have a purpose.

Scene and torrents are two very different things. Scene rules specifically list how a release should look and should always be kept intact. You can share whatever your heart desires using torrents.

So asking that Shareaza blocks the listed file types from being shared on G1 is pretty much the same as saying scene is unwanted i.e. alienate every scene fanboy. Would make the scene happy I'm sure.

Or would you prefer there is no Shareaza at all on G1?

I read both your OP and reply several times and may have completely misunderstood. Or read things into what you wrote, that weren't the intention.

I totally agree such files can work well with Torrents. It can also work with the DC network 'if' the host's directory structure is set up properly. Otherwise it becomes a finding a needle in a haystack scenario. :D I recall seeing both good & bad (messy/totally unorganised) directory structures back in the days I used DC.

Such files are not necessarily appropriate for G1, G2 or some other networks. With these particular networks there is no structure to bind the files together.

Also, the files need to be named appropriately. Finding a random m3u, info, etc. files are meaningless. There needs to be a method of linking what files belong to them. From what I could see with the ShareAza shared files I found with Gnucleus the other day, this was not the case.

Also, VOB files have a tendency to have a generic name & numbering which is also meaningless as to what content they actually contain unless they have been custom named. Tag descriptions made within the program are artificially pseudo (unless ID3 or file-tagged such as images potentially can be but rarely are) and not transferable across the G1 network. They simply help to describe what the files are in search results. More often than not, they are usually not described in detail for the G1 network.

Thus, the topic mentioned files I was seeing with Gnucleus were mostly meaningless.

What I meant is that the naming scheme can actually make it easier to find the naming scheme of specific files. Also if the .nfo is share, odds are that the .mp3's are as well.

i.e. an .nfo is named 00_artist_name_-_album_name-year.nfo

then it would be 01_artist_name_-_song_name.mp3 etc.