Community Open Src Protocol - Add Your Input & Help The Community

[GhostShip]

Folks as you all know we need to work on a new protocol to allow for both larger file sizes and the newer sized IP addressing methods that have already made their appearance in the real world , the new protocol will need in the first instance to replace the existing primary networking protocol and we need to ensure its safe to use in any open src client .

This can be achieved by mixing up our current knowledge along with newer mechanism's and enhanced cryptographic security, for this reason I will be creating a series of tutorials to allow folks to see what we need but crucially not deliver up any of the network protocols that can be used for mischeif, the idea is we look at what we have already and see if we can create analogues that are not exactly the same but undertake similar functions, packet names/numbers, data fields & field ordering, new packets and improved mechanisms. you decide, discussion can follow and we can build up a firm set of protocols to use going forward.

Of late I cant say I have seen a lot of involvement from the community so I will work on this aspect of the new network protocol alone if necessary however I value the ideas and knowledge of many of you and believe strongly that you can assist in this project.

Currently the OurMx client is built on replicating the functions of WinMx in both the primary and secondary sphere's and for this reason it cannot be entirely open sourced at this time however selected areas could be made available for those developers looking to either use the code in their own projects or more hopefully to help improve the code and assist in making OurMx more roadworthy for the long haul, whilst my focus is primarily to ensure OurMx is completed the protocol project will look at the protocol only and the fruits of the protocol project will hopefully be for the community developers to take forward when they upgrade their offerings.

Thats my talking done folks, join in, watch, discuss, or simply learn more of what we need at this time, I will deliver more materials in response to specific questions and also do my best to document any concepts or ideas the community comes up with to assist in helping ensure we acheive the best protocol for the future, lets all put our hands to this 

For those of you whom know little about the basics of the network heres a basic primer and I will add to this rapidly to ensure a fuller overview of what we need is comprehended by all of you, I will try to avoid specifc packet numbers etc and stick to how the packets are used and what fields are required as well as maybe throw in some other data on how other networks acheive the same thing, all good stuff I hope 

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

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

[GhostShip]

This is a wikipedia page that addresses some of the application protocol problems we will face and explains the IP6 addressing format

https://en.wikipedia.org/wiki/IPv6

I think a thorough study of this topic is key to the job in hand so lets all get on the job so we can all be sure of whats required, none of us is perfect so we cant assume everyone else comprehends the data here fully, redundancy in terms of our mind power and community agreement is critical to a successful project.

[GhostShip]

Whilst we all have our thinking caps on we need to explore other aspects of the protocol such as file hashing, larger file size data fields and anything else connected to those operations.

What mechanism are we all looking at to transfer our files in the future ?

Do we use a Magnet mechanism and if so how will we operate it in terms of required data ?

Do we leave the secondary layer as is for continued winmx compatibility for at least the time being ?

Do we look at DHT based networking models ?

Do we look at UDP only primary network operation ?

Do we build a whole new security model for the primary network or expand on fixing the broken one by cryptographical means ?

There are many questions and many answers here folks so what about hearing from some of you, what are your questions for the rest of us and what direction do you feel offers the best way ahead and importantly tell us why.

[GhostShip]

Theres been a lot of reads of this topic but still no one seems to want to step out and offer their ideas to assist the community, i'm not sure why that is but whilst I can probably write up a new protocol pretty fast it wont be the well thought out one we could have if your all able to pick holes in any ideas and mechanisms that are put forward or suggested.

I personally am looking to see ideas suggested here that delivers concepts I'm not aware of and folks would like to see included to protect their security

As I have stated I am not the sole repository of the communities knowledge and I'm pretty disappointed in the lack of engagement, now how about we get to work ?

Heres a small idea i had yesterday regarding the flood broadcasting nature of the current architecture, why not slice that idea up somewhat to make the network less bandwith intensive by trying to limit the searches in response to the results, sounds common sense eh ?

The letters are ones I made up so I hope your not confused by them appearing like magic, the concept of using differing packets for each operation does lend itself to increasing the security of the network as the packets travel can be compared against its data unlike when a single packet is used across the whole network with few areas of data to test against..

[Will]

I was thinking about this a while back and was looking into hashing algorithms to replace the existing one, these are 2 that I thought could be useful if we ever decided to updrade the protocol

https://github.com/cmuratori/meow_hash
https://github.com/Cyan4973/xxHash

I was more concerned about them being fast reather than cryptographic btw.

[GhostShip]

I'm on them, cheers Will 

[Update] it seems github is another of those browser nazi sites that wont allow me to check out the code , never ever have such problems with sourceforge 

[Will]

I think using UDT (https://en.wikipedia.org/wiki/UDP-based_Data_Transfer_Protocol) going forward could be a good idea.

We could completely upgrade the primary protocol without effecting how secondary clients work so nothing breaks right away and tools can eventually be updated.

I had some notes about working with IPv6 but can't seem to find them but I think it had something about teredo tunneling (https://en.wikipedia.org/wiki/Teredo_tunneling)

[GhostShip]

Whilst we are looking at this topic another form of hashing we require is to secure the protocol against replay attacks and this can be facilitated by hashing a time/date component into the packet so that they cannot be simply replayed or modified without detection.

[GhostShip]

I like the idea of in the first instance fixing the primary protocol as this allows us to keep the existing winmx base by allowing secondary connectivity, whilst upgrading the broken areas of the wider network.

[GhostShip]

I had an off forum conversation with Will earlier folks and we have laid out a plan to start the groundwork and see what we end up with, this is a good move ahead but we both feel strongly that you too have something to offer so whilst we are laying down the floor theres plenty of room for furniture and a few walls 

Seriously though input is both welcome and sought after as we need to hit the right mix of security vs speed  and this is new territory for all of us and a good time to jump back in to building the future.