Waiting for network reply for 97% of files queued

[GhostShip]

Of course its possible to undertake such editing however then that introduces another problem, distribution.

Once the files been modified the original author can proceed with legal action if he chooses and there are no resources available to settle any such claim so if that avenue was taken it would lead to the usage of a "rogue" copy passed around the community illicitly with the danger that presents in terms of being able to ensure folks are not being misled into introducing backdoors or malware into their machines.

For the reasons stated above I would suggest no one takes such activity seriously, I understand the frustration but we have to accept our limitations whilst still using the original client.

[White Stripes]

ok, so then another dll injection... modify the client on startup like the community patch does....

[Pri]

Theres a raft of material on the net for whatever direction you might want to go in in terms of protocols and conceptual material, I do strongly suggest you steer clear of a client-server only model as there could be potential issues if your userbase decides to involve themselves in sharing copyrighted material.

Other cool mechanisms are "block selection" instead of actual file transfers, three layer networks to support servers as super-super peers, amd of course neighbour peer traffic routing to ensure an actual fileholder is never exposed, theres plenty to investigate thats out there in the open just waiting to be combined into a serious platform.

In any client I would make my intention would be for it to be decentralised as much as possible. There would not be a network for instance. Instead there would be a server browser. You could point the client to a local file or a website which lists "rooms" and then you connect into those rooms. Some may require passwords to enter from the room operator. The rooms themselves would act like a server, everyone inside the room can see everyone else inside the room, browse them, search for files etc - Just like DC++.

So there would be no network to take down. Only individual rooms. But you could host a room behind a VPN acting as a reverse proxy as it can run on any port number, providing some protection. As for the chat itself I'm thinking highly customisable, colour codes, clickable links, protocol for "xyz is typing", in-line media (for example when someone posts an image into chat it would show it in-chat if the user wants it like that).

I would probably make the chat use a WebUI view so that messages are rendered using a XHTML type window. Raw messages sent between users won't be HTML, they'll just be normal basic text but the client will "beautify it" and this will allow CSS files to be used by client side users to customise how their chat looks visually. This is an idea I did not come up with, it's from Textual, an IRC client which already does this and is quite robust in its implementation.

A lot to think about, I have a lot of projects and work where I code full time so need to decide what I'm doing and when but I have a lot of ideas. I would be aiming for full cross-platform compatibility with Windows, MacOS and Linux from the get go but not by utilising any lousy frameworks, I don't want to use C# or Java etc - Something more native and that is preformative.

[Will]

Theres a raft of material on the net for whatever direction you might want to go in in terms of protocols and conceptual material, I do strongly suggest you steer clear of a client-server only model as there could be potential issues if your userbase decides to involve themselves in sharing copyrighted material.

Other cool mechanisms are "block selection" instead of actual file transfers, three layer networks to support servers as super-super peers, amd of course neighbour peer traffic routing to ensure an actual fileholder is never exposed, theres plenty to investigate thats out there in the open just waiting to be combined into a serious platform.

In any client I would make my intention would be for it to be decentralised as much as possible. There would not be a network for instance. Instead there would be a server browser. You could point the client to a local file or a website which lists "rooms" and then you connect into those rooms. Some may require passwords to enter from the room operator. The rooms themselves would act like a server, everyone inside the room can see everyone else inside the room, browse them, search for files etc - Just like DC++.

So there would be no network to take down. Only individual rooms. But you could host a room behind a VPN acting as a reverse proxy as it can run on any port number, providing some protection. As for the chat itself I'm thinking highly customisable, colour codes, clickable links, protocol for "xyz is typing", in-line media (for example when someone posts an image into chat it would show it in-chat if the user wants it like that).

I would probably make the chat use a WebUI view so that messages are rendered using a XHTML type window. Raw messages sent between users won't be HTML, they'll just be normal basic text but the client will "beautify it" and this will allow CSS files to be used by client side users to customise how their chat looks visually. This is an idea I did not come up with, it's from Textual, an IRC client which already does this and is quite robust in its implementation.

A lot to think about, I have a lot of projects and work where I code full time so need to decide what I'm doing and when but I have a lot of ideas. I would be aiming for full cross-platform compatibility with Windows, MacOS and Linux from the get go but not by utilising any lousy frameworks, I don't want to use C# or Java etc - Something more native and that is preformative.

I've seen early builds of a piece of software similar to what you describe, it appears to be built using vue-electron and has most of the chat functionality (including the typing) already implemented. There's basic file search functionality, you can choose which color "theme" to use and it even has light/dark modes.  There's clearly some work that still to be done but it looks quite promising at the moment from what I've seen.

[White Stripes]

.....well.... what is this new software of which you speak?

[Will]

It's a peice of software described previously that's being worked on by someone for a little fun and experience. I'm sure they will release more information when they feel ready to, but for now I think it's being kept private as it's a personal project.

[wonderer]

@white stripes, with strong I meant strong in population, not many of of the networks have a steady  base like WinMx.

[GhostShip]

I was just reading through this old topic and it struck me that I had made an error in one of my responses to a question, the problem answer involved maximum file number modification, an additional reason for not having a simply unlimited number of files exposed is that the current protocol will not support it, we have to remember that the program was written with 32 bit machines and architecture in mind and thus the protocol has field sizes that reflect this.

I am sure we could edit up a lot of things but without being able to access all of the currently fielded clients we would simply be making a problem, this is one of the reasons I have always suggested a fresh build client and therefore no such issues to contend with.

My apologies for not making this aspect as clear as it could have been folks.

[White Stripes]

the program was written with 32 bit machines and architecture in mind

technically 32bit doesnt mean anything... moreso it was written with slow machines in mind...

[GhostShip]

Lets just be thankful it was written  :