Author Topic: New Client (Read 119039 times)

Pri · « **Reply #260 on:** June 22, 2015, 07:22:52 pm »

If we used DHT or a DHT-like custom thing we'd essentially be turning every node in the network into a peer cache and primary user combined. There would be some overhead there. We'd still need to build in some hashing system on top to slow down request abusers and we'd likely still need an authority of some type to bootstrap new connections that have never joined the network previously. Like a root DNS system in the world wide web to get other addresses from.

I think probably a combination approach, a central bootstrap as a hidden service or services. Combined with DHT for maintaining the network and then some kind of computational hashing system like SCRYPT. I mean the main thing we need to stop is people being able to just flood the network with junk requests that use up bandwidth and resources. So whatever we do it will require some kind of flood control, handshakes for UDP transfers of information (or just go TCP and get it for free) and some CPU heavy hashing system to slow down request forgers.

GhostShip · « **Reply #261 on:** June 22, 2015, 07:30:45 pm »

In an ideal world the problem of relying on the caches for things would be a no brainer but we have both the legal and the other issues to contend with, say wmw set up such a scheme the mafia might claim that without us facilitating connections between clients who may have infringing files there would be no infringing activity, which in their fantasy world means no network, the further issue is one of who gets to run the caches etc we have seen battle after battle over such matters and whilst I like to think a fair and reasonable job has been done in selecting the trusted theres always someone who's going to claim bad will or malicious blocking of an individual, how do we work past that barrier when it requires more trust than many of the users are willing to hand over to anyone ?

Pri · « **Reply #262 on:** June 22, 2015, 07:37:28 pm »

One solution we could do is at first we use peer caches that we operate, and then after a few weeks when the community has 1,000 users (and we'd integrate the peer cache technology in to their clients) we could switch our peer caches off and instead distribute a file with the client which contains a snapshot of the network.

This way we can bootstrap new users getting in and we can periodically update the file that is distributed with the new client. Only one of the IP's in that file would need to work to get someone on the network though for security we'd probably set it much higher so they would need to connect to a few and check if the nodes match on each etc

GhostShip · « **Reply #263 on:** June 22, 2015, 07:43:43 pm »

Hmm this idea is very similar to a feature we had decided to add at some stage to ourmx ,local peer caching to allow for connectivity in the event of some attack on the caches, such a localised cache could be added to periodically up to a set quantity by peer rating and then IP rotation, all sounds good to me.

White Stripes · « **Reply #264 on:** June 22, 2015, 08:12:13 pm »

Quote

it will be on "github"carrying the REN badge,

gah... the 'ren' tag is for mxmoni .. thats all its for.... pri is playing with the two (last i looked there were two) minecraft servers hes running... 'renegades' is a room he inherited and scripted a bunch of toys and games for to keep things lively.... it could be served just as well on IRC...

and your github issues are getting old...

GhostShip · « **Reply #265 on:** June 22, 2015, 08:29:49 pm »

They are not particularly my issues though are they Stripes, I don't choose to have anything to do with github, I have made that plain and others seem to be taking issue with that choice.

Perhaps you may wish to start a Github arena for all of the remaining winmx communities open-src materials its up to you, I have other matters to attend to however so I am exercising my choice currently not to do so, that's not always going to be the case but it is for the time being, these discussions being undertaken here will move us all in the right direction I believe and as one happy band, we don't have to act the same or even be the best of friends but I hope we all share the dream of a continuing network of friendship.

White Stripes · « **Reply #266 on:** June 22, 2015, 08:33:30 pm »

ok.. calming down and reading -all- the recent posts.. we have some good ideas........ but i have the million dollar question of 'who is going to program this?' .. and better yet 'when?' .....

hollow87 · « **Reply #267 on:** June 22, 2015, 08:34:22 pm »

Agreed, again but without central authority/authorities issue of where trust is placed is back...so an idea maybe is trust is determined by X amount of existing nodes on network before your imputed into the routing table making that trust hard to get similar to mining a bitcoin maybe? so that is is very computational heavy making it pretty unfeasible for a bad node to poison the routing tables

hollow87 · « **Reply #268 on:** June 22, 2015, 08:38:52 pm »

And who is going to write this...first step i think would be to separate the code base so the insecure primary protocol cant be abused more and then after that point determine the correct path forward. github or not open source or not, need to get a proper separation of code in there so adapters can be made for the parts that need them and the hardwork of actually implementing these ideas begin.

So basically need a list of developers who know the language OurMX is in last I remember its C++/MFC

I know C++ can't say I know MFC but I've used ATL before.

GhostShip · « **Reply #269 on:** June 22, 2015, 09:16:33 pm »

The list of those whom know the language is pretty much a who's who of the community of old, Myself, Will, Zenar, Zhen Xlogic, Richy (partial knowledge), Sharky, KM, Bender, I'm sure theres more out there.

Do we have a critical mass of coders in any other language ? It might be possible using the knowledge gained in constructing OurMx to simply create an other language analogue as we already know what classes we need what routines are where,what they do and their basic parameters, given enough coders and access to the OurMx src as a reference that too could be an option, I have stated before that part of the Project was to generate a client template and this is still possible if we have enough coders of moderate ability able to transcribe the MFC C++ routines to winAPI based versions.

I created this some time ago to deal with just this scenario

https://www.winmxworld.com/tutorials/secondary_client_creation.html

hollow87 · « **Reply #270 on:** June 22, 2015, 09:24:16 pm »

Josh, Adrian, Sean, and myself know C# / .Net ( Don't know if Sean knows C# or just VB.net but they are essentially the same) Zenar did .net as well don't recall any of his programs being C++/MFC I know ZCS was .Net

GhostShip · « **Reply #271 on:** June 22, 2015, 09:26:44 pm »

Zenar programs in multiple languges

Did any of you investigate the remains of MoonMx by sir moon ?

httpss://archive.winmxworld.com/MoonMX/beta/

hollow87 · « **Reply #272 on:** June 22, 2015, 09:34:00 pm »

I have not, iirc that was based on WinZO again .net

Seems like the more complete open source programs are RoboMX, WinZO, MoonMX

But, recreating what was done in OurMX again does seem counter productive for the OurMX program

GhostShip · « **Reply #273 on:** June 22, 2015, 09:41:28 pm »

I agree but i have taken whats been said on board also regarding the MFC roadblock to both new programming talent and deployment of non-ms platforms, whilst MFC is usually supported its via the usage of wine and not natively, if its possible to use C++ as the core language or if the Mono platform is working at last things can move on rapidly and leave greater scope for the future, OurMx has a lot of good stuff under the hood but at essence its a simple switched windows application and delivers the normal views we have come to know over the years using the simplicity afforded by the VS dlg creator.

As long as we know what we want and where I dont even see us having to do much in the way of planning.

White Stripes · « **Reply #274 on:** June 22, 2015, 10:23:14 pm »

since the current generation only seems to know .NET (pity) heres a useful link; http://www.mono-project.com/docs/gui/

hollow87 · « **Reply #275 on:** June 22, 2015, 10:42:45 pm »

Yes most of win forms can be used with out issue as long there is no p/invoke code being used (calling native api)

White Stripes · « **Reply #276 on:** June 24, 2015, 11:09:53 pm »

well this train of thought stopped abruptly... but if one cant see the tracks it makes sense why....

hollow87 · « **Reply #277 on:** June 24, 2015, 11:41:58 pm »

Well what I got from it is we have a few .NET open source printers and a few .NET developers and to put the 2 together

White Stripes · « **Reply #278 on:** June 25, 2015, 02:47:05 am »

i figured a plan would have been discussed.... perhaps not here but somewhere on this forum.... course it could be in an area i cant see..

GhostShip · « **Reply #279 on:** June 25, 2015, 06:23:33 am »

Your half right Stripes, Hollow and Pri are most likely doing the same as myself in looking at whats been said and looking at how things for each of us specifically can be moved forward, I have been looking at the base problem preventing open srcing OurMx as that seems to be part and parcel of fixing up the network in the fastest way with minimal changes, a completely new network design will take some time to flesh out in both theory and practice so it made sense logically to look at the broken parts only and fix those, that's what I have been looking at and discussing with the rest of the OurMx team over the last few days, we are positive we can achieve more in this way than rebuilding the whole network from scratch, also we decided to refocus our efforts towards a more streamlined way of bug fixing and bringing beta 2 to the table. Plans have been made and will no doubt bear fruit across the next few weeks.

It would be nice if we can hear any firm plans of Hollow and Pri as I'm sure some interested folks (myself amongst them) would like to hear which direction they are looking at and of course if its possible to assist them without sabotaging our own efforts we will be happy to do so