That's not even remotely like a DHT.

1. maybe add the option to start as a system service on windows systems?
2. dont clear the number of hits and uploads upon refresh or when restarted. give the option to clear them.
3. Optional setting to show the minimum bitrate on search results, like default it to 128 or something, but dont have the option turned on by default.
4. i noticed while watching uploads on the monitor tab that sometime the progress bar goes well over 100%, like to ~220%and the time goes into the negitives. im using limewire 4.4.3.1 ... bug?
5. in the search window, expand the little X (close) button to width of the bar.
6. this maybe a long term request: but maybe the ability to preview a file by streaming it. i dunno if this is such a good request., but im just throwing in some ideas into the pool.
7. after playing/previewing an mp3 file with the limewire player, it doesnt go back to saying "LimeWire Media Player"
8. While changing between some themes, usually from windows theme, to another, then back to the windows theme, not all of the theme is changed back to the windows theme. does limewire not correctly reload it? limewire 4.4.3.1
9. When the status quality says "TurboCharged" the 'g' is slightly cut off.

But the way it works suffices to build a buddy-system on it.

When you ask for a download you get all who also download teh file. Here, you simply have the buddies buddies addresses. You don't need to know anything about them,, but that teh buddy says "hello" to them, as soon as he/she comes online. If you now come online, you first say hello to all of your buddies, and when you don't reach one, you ask the buddies of that buddy do give you the new address. If they don't have it, there is none. Else they will give you the buddies address.

If you want to send a message to your buddy, but the bugger isn't online, you smply send it to all the buddies of the buddy, and as soon as your buddy comes back and says hello to them, they pass it on.

With public-key encryption, the messages could only be read by the buddy to whom they were sent. They could be verified via signatures.

Difference from the download-mesh: In the download mesh you have alt-locs for files, which you give to otehrs when they ask. Here you have alt-locs for the address, which you use yourself.

As soon as you connect with a buddy, you send your whole buddylist over there (IPs suffice for that), and when it changes, you send them an updated buddylist.

Sure, that wouldn't scale, but it doesn't have to (except if you have 5000 buddies).

Buddy-discovery, if none of your buddies is online anymore goes via buddy-files over Gnutella. All your buddies and you yourself have your buddy-file, so there should be enough sources for it.

__________________

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

No, because you cannot do any look-ups. With the download mesh you more or less accidentally stumble across more sources. One source that you tried downloading from tells you, who else might have a certain file. It is not possible, simply to request all possible sources for a file and that's what you need, if you wanted to use the download mesh for looking up the IP for a certain ID/nickname

@trap_jaw: Now I have to admit, I don't understand the problem.

If you mean, that we can't use teh download-mesh as it is now, to completely do the task, you are surely right.
But it already does most of the things you need to form these smaller chat-nets.

I don't think we should use the same database (the DownlaodMesh), but a very similar mechanic.

You don't need all alt-locs, because the ID-file should already contain the most recent addresses of the buddies of the host (it ontacts all its buddies).
Now that I think of it again, 2 contacts are necessary:
1: Check and contact all buddies and download their most recent ID-file-with-buddylist (which they should just have changed, since your IP most probably changed).
1.1: Find those buddies whoose IPs changed
1.1.1: Look into the ID-files-with-buddylist of your buddies. Maybe they have it already (very probable, since you often have similar buddies as your buddies).
1.1.2: Contact their buddies to ask for the new IP
1.1.3: If those buddies have the same IP in their database as you, you tell them "can't contact" (we have the same facility in teh download-mesh) and ask the next one, till you checked all. If you don't find a new address, you go on to the next buddy, you couldn't reach via the IP.
1.2: Update your ID-file-with-buddylist
2: tell all your buddies to get the new ID-file.

Or do we have some other misunderstanding?

__________________

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

arne_bab, I understand what you are hinting at, but this will not work. Just suppose you connect to Gnutella yet all your buddies are disconnected and their IPs have changed. You will never find any of them again. Doing a broadcast search for them is totally out of the question and so is having the user manually enter the IPs.

@ everyone, this is why there is a dynamic-dns request. it will take care of this situation of losing track of current ips.

ok, ill try to explain how this could work. it works similar to no-ip.com's system, basically you have register a nickname/username with the system, and set a password, once this happens, the system will give you a subdomain address like bf6r45js90tyjvr.limewire.net/com or something. (i personally would use the .net for it, or buy another domain or something.)

then when the user wants to login, he needs to use his user/pass he used during registration, then it will update the system to his new ip address. then all a contact/buddy needs to do is keep his dynamic-dns name. nothing else will be needed for this kind of system. this kind of system of authentication does not need to be a distributed form because it is not at all running on the gnutella network. BUT the dns-system and its servers should ONLY be used for the authentication part and IP updates. everything else like chat sessions should be direct connections.

basically its just like the no-ip.com free service.

More Requests:

1. The Limewire Library needs the ability to sort different media types. Different media types could be saved to different folders.

Example:
1a. Documents to one folder
1b. Programs to another
1c. Images to another
1d. Playable media to again another folder, and even create sub folders for different extensions. (video content to one subfolder of playable media and audio content to another subfolder)
etc...
Also, this kind of feature would also help out not just the user the files are stored on, but making content easier to find when limewire developers introduce the browse host with searching through folder.

2. The player has a few playback bugs. Sometimes it play an audio file for like 5 secs, then just stop outputting the audio, but it looks as if its still playing.

3. The player wont play a file you click on in the library if you are currently playing the playlist. But it seems it qeues it for the next file to play.

4. A kinda akward feature, but could drastically reduce the number of bad files on the network.... This feature im proposing has client users rate the host users files. If alot of people (lets just say like 10 people) rate a file fake, a message could be shown to the user that the file is bad. Also, the hosting servent keeps track of all these ratings for its own shared files. Then when a client user search's (or browses) the servent host, it will send the ratings everyone else gave it. Is feature already going to be coming, and if so, is it like anything that i just described?

5. The mp3 player scrolling message of whats playing should be smooth scrolling. And it should scroll the meta data if its available, otherwise show the filename, maybe have optional parametors of what meta data to show, and have the option to always scroll filename.

another request, the ability to keep low bandwidth downloaders from taking up all the upload slots.

This ones already avaible: LimeWire just adds more upload slots, if you have free bandwidth avaible.

__________________

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

__________________

Does anyone actually understand what the benifits of these features would be? Do you realise how awesomely big the network would grow if such a feature was presented the right and legal way to the users? This kind of feature would make the network surge with new content and availablility. This kind of feature could possibley shoot the network straight to the top and stay their untill other apps help out (like bearshare and other gnet apps etc) making limewire #1.

Now.. a way to present these types of features would first need limewire to play media content such as CDs. This is needed so that limewire is optionaly set as the default media player, if this were to happen, more people would use limewire as their media player. Doing this could enable limewire to detect media content that is inserted and quickly retrieve the artist info for that CD. The user can also be presented with a CD -> mp3 encoder (or whatever format) and then be asked to share this content. Presented this in a very legal and cautious way of course by telling the user about the legal side of things. I just dont understand what the problem in creating such a thing hasnt been already implemented. Since if something very much like this were to happen, it would boost the network so much. I would DEFINATELY spend more amounts of time running limewire and sharing my content. Making an all-in-one app and possibly making limewire a center for media content sharing and playing would make people more interested in it since they (the user) doesnt have to spend much time finding media players, rippers, burners, etc.

I would love to go on about this forever because this indeed would be the greatest thing for limewire and the gnutella network.

and noone seems to want to reply?

The Bitzi lookup already is included (right click a file to test), and does much of what you want. iTunes is supported, and also does much of what you want.

These are all great features, but personally I wouldn't want LW to try to be a media center. It would take so many more people to develop and maintain, and those other groups are doing a good job.