Author Topic: New Client (Read 120849 times)

GhostShip · « **Reply #220 on:** June 21, 2015, 07:35:05 pm »

You don't seem to be listening do you Pri, let me spell this out simply so theres no confusion, you have sat back and made your server based solutions that centralise their activity and thus deliver control to you, I saw for myself last week in our chat room you discussing matters with a guy who was on a REN blocklist and you took him off it , is this the future your building in your RENMX empire ?

Centralisation in the short term has enabled you to keep your room safe and alive so nothings been said about the matters simply because folks can choose whether they want to join the REN gang or not but when it affects folks who have nothing to do with REN activities whats the solution if you yourself are not about to put matters right ?

You have benefitted directly from having a large room base with access to a third party server for its members that's your business but for me its not the way I see for the communities future as I wish to see a return to decentralised activity and I have headed my efforts towards such a future, I am aware of my limitations and the fact that I wont be alive forever to dish out reasonable and fair advice and thus open src is the way ahead to ensure that as long as someone cares to update the network it will always be one step ahead of its attackers, if you really want to reach the github stage then lets get discussing how we are to move past the current spate of weak protocol based attacks, if you could focus on that rather than this fixation with github then we may in the near future make amicable progress but hating on me and making personal attacks wont gain you any traction in fact its likely to lead to further issues as if I lose interest in this network I know of many others who will give up on it, why ? We have tried to keep this site and our efforts community based and folks have looked to us in times of need to pull rabbits out of the hat and in nearly all cases after some time we have delivered, this is done through gritted teeth and the hard work of many not by magic, decisions are never taken lightly and nor should they be, if we lose a focal point of the community we lose the folks focus and then we lose the folks, your wish to get your hands on OurMx is to be welcomed by myself but after the incident some years ago a question of trust issue has arisen that I cant overlook as it was never resolved to my satisfaction this then is why you and I are not on the best of terms it's not because I'm delusional or mad or just an old git its based on an actual event and thus logical trains of thought are in play here, following on from this logical train of thought it stands to reason we all need to discuss matters to reach a solution that benefits or satisfies us all as a community, when the time is right or we have an agreed solution to ensure OurMx is not a threat to the network everyone and his dad can have a portion of the cake but it really is foolhardy to be demanding at this time instead of discussing and negotiating to rebuild trust and good will as without such we are doomed to splinter into groups of no consequence.

Pri · « **Reply #221 on:** June 21, 2015, 07:52:43 pm »

Quote from: GhostShip on June 21, 2015, 07:35:05 pm

You don't seem to be listening do you Pri, let me spell this out simply so theres no confusion, you have sat back and made your server based solutions that centralise their activity and thus deliver control to you, I saw for myself last week in our chat room you discussing matters with a guy who was on a REN blocklist and you took him off it , is this the future your building in your RENMX empire ?

I host chat rooms from my server that also runs my Proxy Blocker API. The user you speak of is called Jerry and one of the hosts of the rooms I operate asked for him to be banned. I added his IP address to the firewall on the server not realising he was hosting rooms and using the Proxy Blocker service.

Now understand, it did not block his access to WinMX or anything like that, it just stopped him from being able to query the Proxy API. And when he informed me of my error I immediately removed his IP from the firewall and apologized to him. He is now able to use the Proxy Blocker API.

What I don't do however is put users IP's in the Proxy Blocker so that they get banned from all of WinMX like you did with Joshes IP. You opened the door to this discussion so don't start complaining I'm bringing this up.

Quote from: GhostShip on June 21, 2015, 07:35:05 pm

Centralisation in the short term has enabled you to keep your room safe and alive so nothings been said about the matters simply because folks can choose whether they want to join the REN gang or not but when it affects folks who have nothing to do with REN activities whats the solution if you yourself are not about to put matters right ?

The client tools I make available, both a website php script and a metis plugins are open source. And the code is in no way obfuscated. People are free to modify the clients to point to any API they want. There are alternatives out there so people can use my same code to get proxy protection from other services. And there are people on WinMX who have also made their own API's that work with my client software.

When I finally go from this community people will be able to continue to use what I've made and modify them to work with other services. Some of which already exist.

Quote from: GhostShip on June 21, 2015, 07:35:05 pm

You have benefitted directly from having a large room base with access to a third party server for its members that's your business but for me its not the way I see for the communities future as I wish to see a return to decentralised activity and I have headed my efforts towards such a future,

When I started the room was quite tiny. Only when it got to a moderate size did I start writing things for all of WinMX. Everything I've put out has been free and open with very liberal licenses. I don't consider my approach a centralised one.

It would be centralised if I was releasing stuff closed source and had them all hard coded to use my servers. That's just not the case. If anyone else wants to step up and release tools to "take control" away from me then be my guest, the more choice the community has the better for everybody.

Quote from: GhostShip on June 21, 2015, 07:35:05 pm

I am aware of my limitations and the fact that I wont be alive forever to dish out reasonable and fair advice and thus open src is the way ahead to ensure that as long as someone cares to update the network it will always be one step ahead of its attackers, if you really want to reach the github stage then lets get discussing how we are to move past the current spate of weak protocol based attacks, if you could focus on that rather than this fixation with github then we may in the near future make amicable progress but hating on me and making personal attacks wont gain you any traction in fact its likely to lead to further issues as if I lose interest in this network I know of many others who will give up on it, why ? We have tried to keep this site and our efforts community based and folks have looked to us in times of need to pull rabbits out of the hat and in nearly all cases after some time we have delivered, this is done through gritted teeth and the hard work of many not by magic, decisions are never taken lightly and nor should they be, if we lose a focal point of the community we lose the folks focus and then we lose the folks, your wish to get your hands on OurMx is to be welcomed by myself but after the incident some years ago a question of trust issue has arisen that I cant overlook as it was never resolved to my satisfaction this then is why you and I are not on the best of terms it's not because I'm delusional or mad or just an old git its based on an actual event and thus logical trains of thought are in play here, following on from this logical train of thought it stands to reason we all need to discuss matters to reach a solution that benefits or satisfies us all as a community, when the time is right or we have an agreed solution to ensure OurMx is not a threat to the network everyone and his dad can have a portion of the cake but it really is foolhardy to be demanding at this time instead of discussing and negotiating to rebuild trust and good will as without such we are doomed to splinter into groups of no consequence.

I don't think we could ever work together, I think you're too afraid that I will just steal what you've made so far and release a RenMX client with it as a base. All I can say about that is I have zero interest in having a RenMX branded client. I don't need that kinda ego boost. All I want is a client we can update ourselves. That is why RCS is being made. We started off modifying WCS but realised we would have to remake the whole thing because it doesn't have any kind of virtual room support, it's not events driven etc and these were features we need to mitigate attacks.

If OurMX is based off old technology like MFC then that issue we had with WCS may be true with OurMX as-well and in which case it's probably not even worth pursuing. I'm now thinking perhaps we make a new OurMX on Github and get everyone on board to start over from scratch in a modern language and structure.

White Stripes · « **Reply #222 on:** June 21, 2015, 07:54:02 pm »

Quote

your server based solutions

noone would be able to find their rooms if the server wasnt listing them.... ....just pointing that out....

GhostShip · « **Reply #223 on:** June 21, 2015, 08:03:58 pm »

Quite so Stripes but we have all heard the malicious rumours that go around that suggest the attacks are designed to ensure this exact situation, I have even had to defend Josh myself whilst wondering just why his server scans the network a lot more frequently that necessary to facilitate a simple room list, we will never know why that is unfortunately.

Talking about Josh, Josh admitted himself that he was aware the early attacks where being carried out by KM and he only came to search me out when KM got nasty and started spoofing Joshs IP in the attacks and for this reason to ensure we could rule Josh firmly out of such attacks I asked for his IP to be added to the blocklist and I spoke to him directly to let him know what had happened and lo and behold this then paints the story in another more fair and even handed light.

Pri · « **Reply #224 on:** June 21, 2015, 08:06:38 pm »

That always happens, you make a solution to something on here and everyone says it's the solution provider behind the attacks. Like a firefighter who goes around starting their own fires.

We have zero interest in it. I would prefer the attacks ceased so we could find new users who load the channel list. Right now we don't get any new people just regulars and old timers who have come back after years away. It's a really sad situation and we're increasingly desperate for a solution.

Pri · « **Reply #225 on:** June 21, 2015, 08:10:20 pm »

Also the reason that it asks for rooms more often than usual (below 30 minutes) is because when you send out a request for rooms you only get 5-10 back. You have to do it lots of times to get a full list of all the channels. That's just common sense.

Once the roomlist has rooms it only pings them with a single packet once every 30 minutes to make sure they're still turned on.

GhostShip · « **Reply #226 on:** June 21, 2015, 08:12:13 pm »

I share your disappointment Pri make no mistake I have been hit firmly in the N*ts by these attacks but what choice do we have to move ahead when the networks main client is crippled and the main protocols we all rely on are compromised, you know the answers to these questions, perhaps a new third party client will the best idea but it will still need an improved primary protocol and at this time that's what I'm standing in the wind over.

If we can reach an open specification of sorts like they did with napster we can all build whatever we like and rest easy that its all going to work together, thats my initial goal at this time.

Pri · « **Reply #227 on:** June 21, 2015, 08:24:42 pm »

I think you should spend the rest of your time at this point moving the primary parts of the client out into a library that can be bundled with the source code and then open it. I honestly believe that's the best course of action you can take to get the client finished.

In the near future we will need to have a discussion about an open protocol / protocol extensions with all the programmers together. That's going to be a tough conversation, I feel a bit bitter about some of the things that have been said here today so I'll leave the thread now for others to discuss that with you.

hollow87 · « **Reply #228 on:** June 21, 2015, 09:19:12 pm »

I agree with Pri about getting the primary code separated from the rest of the code as that would be the basis of the requirement before you can start designing the new protocol.

I also agree attacking the problem of making a new primary protocol foolhardy will be bad in the end again.

So let me ask the good questions then, what are the requirements of the new protocol design?

Backwards compatibility?
How decentralized does it need to be?
Security?
Encryption what kind?
How about anonymity?
Again backwards compatibility? (Very important as it forms the basis of the other discussions)

It would be a long and lengthy discussion and which could end up pointless if you cant get the protocols separated properly.

GhostShip · « **Reply #229 on:** June 21, 2015, 09:58:16 pm »

For the time being I suggest we leave the secondary client protocols as they are this allows for backwards compatibility with all known clients, for the file transfers we need to add an encryptive shell to protect folks privacy and disrupt some methods of throttling based on detection of the GET command.

Now to the meat and bones of the problem, our primary network : We have double handshaking between clients initially and that's great but the weakness appears in the subsequent primary peer to peer management, a method has to be employed to prevent spoof or replay traffic from being deployed on this level of the network, if we can figure out either an improved usage of the current protocol or add a new feature or more possibly a new cryptographic mechanism to address this goal we have regained the network back, its that simple. whats not simple is how we achieve this in concept and code, that is the area of problem and thus the key area to address primarily.

On the second battle front I would also like to look at methods to prevent room spamming such as an automated captcha system so bots are not able to gain access trivially to annoy folks, this can doubtless be a reworked pm packet with a message or something of a more novel approach for our chat network a small image file transfer appearing in a dlg box to ensure it cant be automatically bypassed, this i believe will address the problem and can be made seamless to normal chat based operations.

We all agree a backup chat listing server is a great method to bypass underhanded attacks on this community so perhaps we can have more of these or an update to the caches generated so the list can be gathered from there if somehow the an attacker is able to find a new exploit to hit on the chat list, the aim however is to face the problems head on in the first instance and mitigate the attacks in the second.

These are the areas I am looking at and would welcome some input on.

White Stripes · « **Reply #230 on:** June 21, 2015, 10:34:10 pm »

Quote

I suggest we leave the secondary client protocols as they are this allows for backwards compatibility with all known clients, for the file transfers we need to add an encryptive shell to protect folks privacy and disrupt some methods of throttling based on detection of the GET command.

thats technically contradictory you cant have backwards compatibility to secondaries and change the file transfer method....
...and the file transfer does need some serious changes and verification.... i dunno if its me but ive been through 2 isps with winmx and i cannot get a file over 50mb to transfer completely unharmed.... videos get stuck with 'file mismatch' or actually transfer but have glitches.... audio files esp albumwrapped (over 50mb again) mp3s make the most horrid noises.... can download it again but i get a chance to either get it right or get an error in a different spot....

.rar and .zip are currently the only formats that make it through since they will give a CRC error if they break... prompting to try the download again..... its horribly annoying...

only thing backwards compatible should be chat and even then since we apparently now have a server on github (w00t!) a change in the way channels are listed is drastically needed.... everything else could be completely new just as long as it brings the old group over to the new.... which all thats needed is to bring the old chat into the new core...

GhostShip · « **Reply #231 on:** June 21, 2015, 10:44:59 pm »

I dont see such a contradiction, older clients will still be able to connect to the network at a secondary level but newer ones will use the newer file transfer system, those wishing to use older clients wont have 100% filesharing compatibility but thats not the aim is it, the aim is a general upgrade while supporting connectivity for the masses whilst such work is undertaken.

Seems all too simple and plain to me.

White Stripes · « **Reply #232 on:** June 21, 2015, 10:50:22 pm »

at some point the legacy closed source stuff is going to need to be shed from the network....

GhostShip · « **Reply #233 on:** June 21, 2015, 10:56:09 pm »

Indeed, but the idea is to do so whilst minimising any disruption and to keep those parts of the system that are both hallmarks of the WPN and are safe to hold on to.

White Stripes · « **Reply #234 on:** June 21, 2015, 11:05:38 pm »

*runs winmx .... watches as its capable of nothing on its own* --- those parts are going to be very few...

GhostShip · « **Reply #235 on:** June 21, 2015, 11:13:37 pm »

Are you making some kind of erroneous observation here Stripes ?

Once the false traffic is removed from the network many of the issues you complain of are non-existent , it feels as if your preparing the ground for others to suggest we all move to gnutella or some such other network , thats not on my agenda just so your aware.

White Stripes · « **Reply #236 on:** June 21, 2015, 11:26:12 pm »

sure it works if its not attacked... so does windows 95.. surfs the net just fine... microsoft has the source to win95 tho and its been reincarnated many times.... the source of winmx is not there to be fixed against attacks, updated to use unicode... etc....

the east apparently focuses on files... im guessing with a site that trades in hashes... the west on chat... a 'half and half' client... part winmx part gnutella or even a whole new protocol would be the transition... keep the chat you keep the ppl.. the rest can basically be tossed out the window and replaced with something already open source and proven to work...

its been 4 years!! its time to do -something- instead of just sitting on an alpha build clone... trust has long been thrown out the window and using winmx is an absolute pain.... its really time to shit or get off the pot...

and honestly? the best way to use winmx is to remove or rename the patch file so it doesnt connect to the wpn... still get the chat from josh/pris site (whoever owns/runs winmxunlimited) and share over opennap... it really does work better like that...... problem is opennap is drying up...

and the 3000/5000 file limit browse? i would need 4 clients running side by side to share what i have in my library on the wpn...

GhostShip · « **Reply #237 on:** June 21, 2015, 11:36:48 pm »

I cannot afford to be distracted from the core topic so trivially Stripes I am here soley to discuss the way ahead and how we are going to reach that place, I know its been hard on all of the users but its also been a weight on my own shoulders of tremendous proportions, thus for now I choose not to become embroiled in doom and gloom but I do understand why you have reached this stage its a place many have hit way earlier than yourself.

There will be plenty of time for recriminations when we fail trying rather than giving up before our human resources are fully expended.

White Stripes · « **Reply #238 on:** June 21, 2015, 11:47:25 pm »

ok.. way ahead? split the primary out of the alpha client and put the rest on github so others can fix its many ui glitches and other hiccups... after that re-glue the primary in... ...you have spoken about doing such before this thread so... throw us a bone here... ...hopefully soon...

GhostShip · « **Reply #239 on:** June 22, 2015, 12:22:01 am »

It seems I am standing alone in thinking ahead, we will still be in the same boat even with a secondary client something we had back in 2011, the only difference is that some will be able to make a secondary client besides the developers of it, what we need it a new architectural model for primary, why must so much effort be put into fighting about github and zero effort into resolving the real problem that afflicts us.

* GhostShip walks off in bewilderment