New client suggestions...

[WhiteLightningX]

Hello fellow MX'ers! 

I appreciate all the work being done on the new client, as I'm sure we all do!

1A. I would like to submit the idea of a different way to searching and transferring with others. I was wondering if we could implement a way of sharing anonymously? For instance, say we have Pri1 connecting to Pri2 and each have a secondary connected to them. I know that normally the 2 secondaries would then connect to each other and start the transfer.

Is there anyway we could get the 2 secondaries separated so that neither, perhaps not even each others' primary knows their ip? Say, for instance, we could have an additional option or setting to allow for you to be an intermediary between 2 people transferring. Say sec1 and sec2 want a transfer, then int1 and int2 could be the intermediaries. Then we could transport the file from sec1 to int1, then from int1 to int2, from int2 to sec2. And instead of using actual ip's to connect to, have only usernames of the people farther away than 1 "hop" from your location. Using this method, sec1 could see int1's ip, int1 could see only sec1 and int2's ips, int2 could only see int1 and sec2's ip, and sec2 could only see int2. But the username would allow for a connection beyond the first "hop." Adding to this, i think it would be safe with at least 3 users between the 2 transferring. So it could be sec1<-->int3<-->int1<-->int2<-->sec2. I'd prefer not to use the primaries that the secondaries are connected to for obvious reasons like bandwidth, unless that primary could handle it.

Granted, it would be horrible on transfer speeds. Maybe not so bad if some people had idle connections that were dedicated like primaries or could allocate traffic for that portion of the network. However, there would be some rather decent privacy. The only other issue I can see is it would allow anonymity to someone trying to exploit this. Perhaps we could make it a completely separate available network much like how winmx could connect to wpn and opennap? That way if it was possibly exploited with fake files etc etc like before, it wouldn't damper the new network? Just tossing ideas around.

 I think I remember seeing another p2p program implementing something like this before but I can't remember the name...

1B. If this could somehow possibly make it into the production, I'm sure this could be quite easy regardless. I'm guessing it's probably pretty easy to get a primary's ip address. I'm going to guess again and say that maybe it's a little harder to get a secondary's without downloading from them. (I'm not completely sure how the network works, I'm going on blind speculation and deduction here) Is there anyway to hide a primary who is sharing a file? Like for instance if someone was downloading off of me, could we make it appear that I was acting as an intermediary, instead of a primary sharing a file? maybe make it appear that my username is a secondary connected to me who is sharing the file through me, rather than me sharing it myself? Heck, I might as well add in the idea of having the ability to have a fake username for the fake secondary, or even multiple, multiples of usernames that could correspond to different shared directories or files on my pc. 

I'm speaking from a security viewpoint here, being a slightly paranoid individual anyway.  lol
I know it could open up a whole can of worms regarding people trying to attack the network, but hey it could be a useful addon.

2. Could we add in a way be a more "beastly" primary?  What I mean is, a way to use all of our bandwidth to help with network traffic if we are not using our pc or we are asleep? or a way to have it "trigger" if all ul/dl are finished? This could be tied in with the whole intermediary thing again.

3. I think we should have a scheduler! much like in utorrent, where I can decide upload/download speed caps for different hours of the day, that way it doesn't bother my families netflix usage or web surfing... This would be awesome.

4. A way to switch into primary mode if your transfers are finished?

5. I don't know if this one is stupid or N/A etc, but is there a way we can have the new client search for other primaries without connecting to the peer cache? And a way to not ever appear in the the peer cache? like a flag setting that would tell other primaries to not list us on the peer cache, but allow connections and transfers to and fro via "word of mouth?" Much like magnet links that torrent programs use? (I'm not a huge fan of torrents, it can be a pain when you just want that "one" file! )

[WhiteLightningX]

(sorry guys, here's part 2)

6. Traffic encryption, I'm sure this has already been raised though..

7. Random port hopping via upnp when the program is started. I've had friends who were being throttled, and by changing ports it would work again at normal speed.

8. Decentralized comments and ratings on a given file that you are downloading. (I know, I'm pulling stuff from torrent clients again, but hey, they have some good stuff)

I think It would be awesome to have 2 network systems side by side though.

Like you could have a complete network with primaries and secondaries who could operate in similar fashion to the old network where there is direct downloading, and a lower network that is more decentralized but allows users to remain hidden with multiple fake usernames and intermediaries for transfers etc. Just my thoughts. 

Here is a picture below, pri and sec's are obvious. green's have flagged themselves as intermediaries. On the upper network, things behave just like before. On the lower network, people can stay hidden behind intermediaries and with fake usernames. The orange line being a lower network search, the red line being a transfer through intermediaries, and the pink square being a file needed. Blue lines indicate people on both networks, the single fat pink line being a primary connecting as a secondary on the lower network.

Beyond the first "hop," only a username is attached to the search request, adding the each primary's ID as it goes along. Duplicate search request that manage to find their way back to primary that just received the request could ignore it if no new connections have been made to them. When the file is found, request returns to the sender via the attached ID's. I'm sure you all can find an easy way to determine intermediaries, I doubt that part would be much different from what I just described.

But I would rather see this as a separate network one could connect to, but allow both to operate side by side, even being connected to both at the same time. Obviously this would create duplicates if the same person was on the regular network, and listed the same file under a different username on the lower network, so I would rather have them separate but be able to connect to both of them. Maybe allow secondaries the option to connect to both networks and keep primaries as either upper or lower, so it doesn't burn up needless traffic?

I know I know, enough with my writing already... but perhaps even the primaries could connect to both networks, given that that they can only be a primary on one network and not the other, and if it is connected to both simultaneously, it cannot act as an intermediary.

I realize this is a lot to take in, but bear with me. I think it deserves some attention. Give it some thought. If a new client is going to be made, why not make it the best client possible? We can wait as long as it needs to create the new client, heck we've stuck around this long. Let's show them how strong our user base really is. 

[GhostShip]

Theres some good concepts in your posts WhiteLightningX, some are new, some have been looked at already, and some are not really viable for the network type we are building but all are welcome and will be discussed by the developers, the transfer traffic routing idea is one I was researching myself for much the same reasons as yourself 

Many thanks for such a great set of ideas, we have the basic client base at this time and are looking to add some "nuclear hardening" against any attempts at future attacks so now is the best time to make your voices heard too folks if you know of some trick or technique that will deliver safety and security for the networks users, we have lots of space on the forum here for you to go into as much detail as you wish so please share your knowledge for the benefit of us all and the client developers will do their best to implement the best of the best, once again cheers for your cool input WhiteLightningX 

[Kal]

One idea might be a backup peer database that mx keeps updated.
I expect your still using peer caches, a possible attack target. NewMx could accumulate recently seen (the last 200, 500, whatever) connectable primaries in a small dat file. The peer caches go offline and peoples mx's could still connect to the network without trouble. Make the dat sharable and if the caches go offline for some time it could serve as a means for new users to connect, they just plop in a friends peer.dat file.
...perhaps even a option at install and a button in Settings to never connect to peer caches, to prepare for the possibility that sell-out ISP's or oppressive governments might use those IPs to easily identify whos using mx.

If that connecting architecture had been in place before the original peer cache loss there would have been no panic, and no loss of vast numbers of users.

[GhostShip]

This is an idea thats come to notice a few times and being such an obvioulsy useful idea it will likely end up in the new client.
Having a cache to deliver initial nodes for further discovery is a twin edged sword for the network but as an extra option I cant see any issue with this suggestion and the benefit of reduced cache bandwidth will be enjoyed by all of the current cache operator group, so do indeed look forward to it appearing at some stage.

[WhiteLightningX]

Also, could we add in a way to search within a folder while browsing someone? I cannot stand the fact that I try to download something from a friend who, lets say for the sake of the argument has over 5000 files, that the specific folder where the file I want is kept doesn't even show up on the browse list. So not only can I not find the file I just received from them through the search functions via browse, I can't find any related files in that same folder.. 

So basically I'm asking:
Can we remove the file cap limits of 5000 and 2000?
Can we remove the 2gb cap?
Can we add the ability to search within a specific folder under "browse?"
Can we add the ability to search for specific search terms on a given user under "browse?"
Can we add the ability to search for a specific file format that we can click through the menu without clicking "any file" then adding "~"? (like mp3 ogg etc)
   ---And a way to add new extensions just like before, but have them show up in this list? 

Can we add the ability to have multi-point opennap downloads from our side?
   ---And a way to collapse these by default in the search window?

Can we add a way to manually connect to another primary by typing in a primaries ip? Say i have 2 internet connections, mine and a friend, and they only wanted to connect to me for whatever reason, they could punch in my ip/port number and jump onboard? Relating to earlier, it would also be nice to be able to do this for intermediaries as well.

BTW, is how do primaries decide how many other primaries it can connect to? and secondaries it can hold? It'd be nice if we had a way to allow for more connections if our internet speed is capable. Like say we could click a button that launched an automatic script that ran a speed test, then adjusted accordingly, or just be able to click a default option. If it was manual, lol, we know people who would use it just to make some grief...heck even I would just for meanness if I was a few years younger


Ooooh! Oooh! (lol sorry) Can we add in a way to collapse that #*^&@$#*@#$*% "file types shared" thing in the library? You know the file types boxes that show up under any particular directory when you click expand, that has the green checkmarks or red x's? I share a particularly lot of different file types, which leads to a list of shared types LONGER than the entire library window....

[WhiteLightningX]

Um on another note...since we are sailing in this direction...do we have a new for this new client? We should start a thread and allow people to request names to be put on a poll!

[Bluey_412]

WinMX sounds like a good name...

[WhiteLightningX]

Lol...or we could call it that I guess..

[Bluey_412]

Opening up the Browse limit:
Under the current scheme of things, a 5,000 file browse takes some time to list, how long do you wanna wait for a 20,000 file browse to open?

Most have asked for lifting of the 2gb cap, its purely a technical limit, related to the size of a number (16 or 32 bit, I forget) used to track the number of bytes in a file, it's not merely an arbitrary limit. A bit like the limited number of IP's available caused by 16-bit addressing

Browsing within folders etc: this is diametrically opposite to what has been asked about in relation to Anonymous browsing or even a 'No Browse' option

It is worth remembering too, that one of the original concept for WinMX was (still is) that it is meant to be a 'running in the background' program, that only used 10% of horsepower/bandwidth so that users can also get on with other activity without impacting on the resources available for said 'other activity' (Work?)

You cant run Torrents etc at work, but WinMX can quietly run even on a work PC, as long as the sysadmin hasnt got such a tight network that you can only use MS Office and internet to 3 websites (Yes, there are many such places)

[silicon_toad2000]

The searching within folders is somewhat in line with a few other suggestions of being able to filter browse results

[WhiteLightningX]

Awesome silicon.

In reply to bluey,

Yes, I know the browsing function takes a while to list all the entries, but why does it take forever? It's a loading a list. It's not like it's some humungous file...

Oh, ok. I remember the whole IP4 vs IP6 thing.

It's not diametrically opposed, it can easily be done via the methods described in the first post. But yes, a "No Browse" option would be nice too. Didn't even think of that.

And yes, while it is great to have winmx idle in the background and not really bother you, a large percentage of people have access to more robust pc's and internet connections. I myself run winmx, even when my settings are maxed(not necessarily thread priority) and the internet connection isn't capped while connect to say 15 opennap networks + 10 primaries + another 10 secondaries, my usage only goes to around 15-20%(and that's only on one core..), with around 8% of my internet connection being used. And my pc was built back in 05. And it was cheaply built at that. And I live in the woods, tens of miles from a local town. So it's not like my internet is "top-o-line" or anything, just a typical crappy cable connection that goes out in the winter time.

I'm not asking to remove the original functions, just add in some new stuffs. Winmx is an old program. A good one, built to run with the hardware back in the day using limited resources and slow connections, but it's a new day, with new hardware and new connections. Much, much faster hardware and connections. I think we should keep the same principles, but step it up a tad. If some of use can utilize it, why not let us? If you have a slower connection or hardware, no problem. If you want to use up your faster connection for the time being, just change your settings.

I'm part of the younger generation, I used winmx before I was even a teenager, and I can tell you that from growing up in a digital web based age, that there is a HUGE percentage of people with connections and hardware that blows mine away. Heck, I live in a hick town and graduated with a high school pop. of around 1000, and there were hundreds of us who had connections and hardware that could easily do what mine does now. That was a few years back.

[achilles]

WhiteLightningX, you have some good ideals, and I like your suggestions. Your ideals are very similar to those that have been discussed in the past. I like the ideal of anonymity, and I believe something similar to what you have suggested could be integrated into the network at some point in the future when we have more resources to facilitate the great amount of work, and expertise it would require to develop such a technically advance network. If the client is built with flexibility in mind for the future then I don't see why this could not be accomplished when we have the resources.

I like the ideal of having the ability to browse users folders. That's a great way of being able to filter browsing results. I suggest that a while back, and forgot about it all together. There is currently a l5000 file browsing limit for browsing a primary, and 3000 for secondaries. I think that functionality could be added now or added in a new build shortly after the client is released. There's so many additional features, and functionality that can be rolled out in builds after the client is released. I think the key is designing the client with flexibility in mind. The ability to not allow other users to browse ones library is already being integrated into the new client so we are seeing additional functionality added. I believe the client should allow users to browse your files by default, and give the option for users to tick a box to not allow other users to browse their files.

Also Bluey brought up a very important point. I believe one of the things that has made WinMx so successful is the fact that how light it is on the system. You can run it in the background, and continue doing other activities without it interfering with your work. You can continue to surf the web, and run multiple applications with very little slow down. You can leave it running for weeks, and even months without having to reboot your machine. That's a huge plus for the network because if users have to shut down WinMx to carry on with their task then their bandwidth, and files are no longer available to the network. Most of the other clients force users with lower bandwidth, and less powerful machines to shut the client down to continue with their activities. This was not a problem with WinMx. Also it's simplicity allowed just about anyone to use it. One could be a very inexperienced user, and still understand how to operate the client. 

[Kal]

Most have asked for lifting of the 2gb cap, its purely a technical limit, related to the size of a number (16 or 32 bit, I forget) used to track the number of bytes in a file, it's not merely an arbitrary limit.

I understand that larger individual files may be technically incompatible with the existing backbone of mx but, still, that 2 GB cap can be passed without altering the original network.
- NewMX is told to share a 3 GB file 'Funtime.avi'
- it shows it as shared to the sharer
- the logic of the program splits it at one byte shy of 2 GB, treating the two portions of the file as two distinct logical entities (but not altering the file)
- to the nextwork it shows 'Funtime.avi.prt1' and 'Funtime.avi.prt2' OldMX and NewMX can both see those.
- a browsing NewMX gets a browse and sees those .prt* files and is like 'oh, I'll show the human that as one file in browse'
- the human is like 'oh, Funtime.avi ' and downloads
- downloaders NewMx either A) downloads the two .prt* files in order one at a time into a single file or, to exploit multi-sources better, B) creates a 3 BG container file and plops the first file component in its spot and the second file component in the second spot, sort of like a torrent download.

For OldMX people, they could still download the file components that they see in browse as 'Funtime.avi.prt1' and 'Funtime.avi.prt2' and then use a handy little joiner app made by someone to join them into 1 file, like HJSplit does.

Simple in theory.

[Kal]

ah, no edit button

To be kind to people sticking with OldMX I guess the file sub-component naming should be more like Funtime.prt1.avi so people not upgrading can still see them in the proper filetype searches.

[GhostShip]

With its ability to be used as an attack tool by unscrupulous programmers/developers I would suggest we not support the older clients for any real length of time as to do so defeats the point of rebuilding the client in many respects.

[achilles]

I don't believe we should be encouraging anyone to continue using the old client once the new client is functional, and has been thoroughly tested. As a matter of fact the old client will not be able to communicate with the new network at all. At least not on the file sharing side of things. I''m not sure about the chat function. The few people remaining on the network will need to switch to the new client. Maintaining compatibility with a client that has very little functionality would be a complete waste of time. Thousands of hours of coding to maintain compatibility with a severely flawed protocol would make the attackers very happy lol 

[silicon_toad2000]

Hi guys,

sorry I split this thread from the umm discussion that was threatening to derail the topic.
Please keep suggestions constructive and keep them coming.
We would be doing the community a great disservice to allow this input thread to be polluted with other topics.

[Zénar]

Hi all, I've seen most of the posts in this topic and I like some of the ideas, except it would takes too much times to do. If you want a completely decentralized network, it is normal that there will be a way to put fake entries over the network and flood it (if the network encryption is known of course). I think the solution would be using a more centralized network so it would be possible to have more controls over it. I thought about a network that would have 3 different parts and it would be faster and easier to build than a multilayer networks (Primary, secondary, etc.).
1- Channel listing server
2- Chat server
3- Client

Channel listing server
The channel listing server stores a list of all channels that are hosted by the chat server application. When a client connect to it, the listing server would send the list of every channels back to the client. This application should be downloadable so many people may be able to host their own listing server. For the connection between the listing servers, it can be used to share the list of channels...

Chat server
The chat server have two features, to let the people to chat and to browse files. When a client connects to the chat server, it sends its file list to the chat server so when an another client request a file, the chat server would reply with a file list. There will be better chance to find the file you search if you are inside many channels...

Client
Well, I think you know what the client will do... chat and search files I guess.

With this configuration, people will be able to ban flooders, it will use far less bandwidth than the WPN and it's easier to build. There is an image to show you what I've explained...

KISS (Keep It Short and Simple)
We should start simple and the application would evolve over-time.

What do you think?

[Bluehaze]

Thank you Zenar! I like your network building idea. It will do what we are wanting. As you said, it is simpler. I am 100% in favor! 

Also, let me say thank you to the coders who have been working for so long on a client, and to all of those who have contributed their ideas.