I need your input

[AYB]

Here's a question for you guys concerning the development of my p2p app.

Should it

(a) be a hybrid client able to connect to eDonkey, Fasttrak, Gnutella, Opennap, Direct Connect and any other proprietory network (through the use of plugins network support is simply a case of someone writing a DLL or such like to translate the network protocol into some kind of generic protocol and back again)

(b) a client based on our own network with features like anonymity, partial file sharing, encryption, boolean searches and speed being key

(c) a combination of the two, with our network search results possibly highlighted in a different color to indicate they come from a source with "added" features

Here's a few arguments for and against each option to get the ball rolling:

A hybrid client instantly attracts people who already use the relevant networks. It offers more search results (many more depending on how many networks you connect to simultaneously). It can add features to a network which doesnt have them in the official client. However it can't make use of features which are exclusive to a single network (or multiple networks, but not ALL networks). Depending on how many networks we code support for, its a lot of work.

Coding our own network allows us free reign in the features we want to include. The major disadvantage is how to get the client used. What prevents it from being just one in a multitude of other p2p clients?

Not really sure what can be said about a combination of the two, but its double the work I guess.

[Mowzer]

Go the independent route, and focus on it, making your network the best it can be.

Yes it is hard to attract a user base, but if your program is good, it ultimately will.

Look at the fasttrack network. Orignally it was an allright place, it too had to work at gathering a user base which it ultimately did.

You also might want to give some thought to the community aspect of your network. Our own napsterites local drunk Harby posted about community and content, which I personally dismissed.

Doing some reading latley I have re thought about the community aspect towards any p2p app. I think its a good notion that can be expanded on.

Saying that I think p2p app communites could be implemented in better ways. Forums and chat, been there done that. Let the imagination flow and I am sure you could come up with an innovation.

The equation is simple, in order to get a solid user base you need a strong community aspect. There is a reason napster included chat features when it set the p2p benchmark years back.

I would like to see a hookin from a p2p app that gives a sort of community of my close friends from all around the globe, but expands the concept of connected computers into a connected p2p media community, with the ability for each person to set filters of the content they see and also search and download from the entire network, injecting new contnent into your own little p2p network.

It also needs to be tied into a users desktop so file share transactions are seamless, much like it is to move a file from one folder to another.

Kinda a linking of my media folder with my "trusted" friends folder.

If I am at my girlfriends house, I want to listen to my music, I can grab it easy just as if I was on my own computer. At the same time I see a movie a friend just downloaded that I might want to watch too. A p2p media folder. I see the movie and when I doubble click to watch it the download would start and I could watch it. I could search for music at my pc, and since my girl and I have same taste in music she could see what I have downloaded, and grab it aswell. It would all have to be seamless though so it doesnt look like I have to open a seperate p2p app, and download music or movies and then look for them in some other folder.

Media files I dont want to share I could hide with a simple right click. My media is my friends media and theres is mine, diffrent filters would allow me to choose what I want to see and dont. (no need to look at buddies pop music.) That would be a tight intergration of a little private community of my friends, and of course if I meet new people on the network, it would expand my whole friends circle of media.

In app design the best UI is no UI. Local content and p2p content would seem merged, when looking in my connected (insert your app's name here) media folder.

A model like this would need to be trust heavy, no corp bugging it up with adware or spyware. Also attention would need to be paid to viruses, and certain files would need to be restricted, like outlook.dbx files or other system files.

[ssj4_android]

Both. Maybe just the open source networks and your own network. Like gnutella, direct connect (using dc++ source code), opennap, and OpenFT.

[TankGirl]

Ethen's comments were very good. I also recommend focusing on your own network solution and features - you will have limited developer resources anyway and getting your unique ideas to work well is more important to the long-term success of your client than the possible initial advantage of a hybrid system. P2P communities are nowadays able to move quickly to new clients, and if your client has some really cool features it will be easy enough for you to get people to hear about it. It will also be easier for you to address and fix scalability problems if the user base grows steadily instead of explosive growth.

- tg

[AYB]

Thanx for the comments so far guys. I particularly like ethen's idea of seamless integration with the standard windows GUI.

Just wanted to add a cpl of things: writing our own network complicates the legal side of things. It means the RIAA (or whoever) can go after our network itself. If we relied on other networks with a hybrid client we have some kind of legal immunity. We wouldn't actually be providing the underlying network. Having said this the network would probably be open spec, which may (or may not) help matters.

ssj4_android: As far as doing both, restricting the number of networks doesn't really save us much time. The hardest part is coding the generic protocol, once the system is in place it is relatively easy to add new networks.

[napho]

New programs have a chance to grow now if they take advantage of other networks going down, build a strong community through chat within the program, and forums. Also they build anticipation of a new version. Blubster is an example of this; last week they had 6000 online, now it's double. When their new version comes out next week they could be at quadruple where they were last week.
Also the French P2P Taxee has an interface that looks like a hard drive.

[Wanker]

I think it will likely fail in either way.

Connecting to many networks has a problem that networks are different and if you implement a common protocol for all the networks you are using only subset of their possibilities thus using original client yields always better results. Second problem is that you are not able to keep up with development of all the networks. Protocols are changing, new and better features are rolled out all the time and so on. You'll need development resources of all the networks you are supporting COMBINED plus resources that go to reverse engineering and understanding closed-source protocols

Making your own network will fail because there are already too many networks thus it is very hard to attract critical mass of sharers that is needed for network to take off. These days it is not enough to make a program that is better because most of the current networks are already quite advanced and problem is not network technology or client program but rather availability of resources, most importantly upload bandwidth. And problem is getting worse constantly. Main source of the problem is current broadband scheme where download speed is 4 or more times faster than upload. That means that in the future networks are not competing with technology so much, but rather with available upload bandwidth. In the future technology doesn't matter so much but rather business aspects such as making deals with cable companies to pre-install P2P program to all clients and so on.

It is possible to make better P2P network than current ones, but it won't be 2 times better, but maybe 10% better and this margin is shrinking constantly. In few months it might be 5% already. And in my oppinion it is not enough to attract users to switch over, considering that initially there will be no content

Of course all above is only my oppinion and might be utterly wrong
If you are still going ahead with development, good luck to you

[Stoepsel]

Originally posted by napho

Also the French P2P Taxee has an interface that looks like a hard drive.
http://www.napsterites.net/undergrou...&postid=138186

Funny. My hard drive looks a bit more like this:





Stoepsel

[AYB]

Wanker: thanx for the support

As far as the interface, I consider that an important aspect as most p2p clients are as ugly as sin. Ours will definately be skinnable.

[twinspan]

well as for content on a single proprietary network of your own... you know you've got a queue of hardcore sharers right here waiting to try it out.

maybe make sure another p2p app can be run at the same time, so that if people can't find something they want on "AYBster" ( ), they can connect to and d/l from another, while still sharing content on your new network.

so i guess that would mean... efficient RAM usage by your app (so that two or more could run at the same time)... er... bandwidth throttle so folks wouldn't feel their downloads in one app are being hampered by uploads in yours... um... not creating port conflict between your app and the most important other networks (FT, ed2k, gnutella)

well i dunno really how it would need to be done, but the ability (and people perceiving the ability) to run another p2p app alongside yours could help it thru that difficult transitional period.

my vote is for fully-featured & focused network of your own... and to consider moving to Sealand to escape the lawsuits.

[SA_Dave]

Personally, I think it's more important for an app to be cross-platform & backwards compatable. The more people can use it initially, without straining their resources, the better for the network. It might be nice to have cross-network/protocol connectivity, but if you base it on proprietary networks like FastTrack, there's a big risk that they could suddenly alter the protocol or even worse be shut down completely. There's no doubt that this will attract spyware refugees from other clients, and perhaps even generate a lot of interest quickly. There are downsides to this though as TankGirl stated :

Originally posted by TankGirl
It will also be easier for you to address and fix scalability problems if the user base grows steadily instead of explosive growth.

I definitely agree with her on that point. It would be best to develop your own network first & perhaps later add more protocols. Gnutella & other open-source protocols seem like the only safe bet here.

Originally posted by Ethen
In app design the best UI is no UI. Local content and p2p content would seem merged, when looking in my connected (insert your app's name here) media folder.

This is an excellent point of course! The reason I liked AG so much (and why I believe it was so successful) was the simplicity. All you needed was a browser and the satellite. You didn't need to make use of the community features, but if you did all you needed was a browser and the satellite. (I think you see where I'm going with this ) You didn't need skins etc. but if you wanted it, there were more than 5 independant ui's & about 200 skins. It didn't hurt that the app had such a small memory footprint either & was cross-platform (there were even RISC OS versions!)

Another thing that many p2p's neglect is removable media. AG got this right : zip drives, CD-r & unmapped network drives were all shareable. napho might know of other examples, but my experience with FT & DC is that sharing (although strictly enforced in DC) is difficult if you don't administer the network yourself or aren't aware of how to get around these limitations. I'm sure that much more content would be shared if people were allowed to do so in their circumstances (eg. someone who doesn't know how to or doesn't have permission to alter network settings, yet does have access to many shared folders.) This goes hand-in-hand with Ethen's statements.

Originally posted by napho
Also they build anticipation of a new version. Blubster is an example of this; last week they had 6000 online, now it's double. When their new version comes out next week they could be at quadruple where they were last week.

This is a double-edged sword. Too much anticipation without the features can be a bad thing, although I'm sure this won't be a problem. I'm sure forums etc. which already discuss the AYB phenomenon would be a good place to start.

This is a little off-topic as far as networks go, but I'd like to see a p2p with an easy & expert mode toggle. Although, to use expert mode you must pass a little test first. I discussed this in this thread by Teclis.

[SA_Dave]

Another disadvantage of using established networks : fakes, viruses, trojans, poorly named files etc. The more I think about it, the more I understand why there are so many independant networks! Although, these problems will continue as people migrate between networks/clients.

[AYB]

Good stuff SA_Dave

The original design was a hybrid client, and simple/expert mode was very much part of this. We wanted new or less advanced users to simply be able to type something into a box and transparently it would search a number of p2p networks. At the same time managing all those connections could suck bandwith if not properly configured so we planned to include all manner of tweaks in expert mode, if so desired.

Even if we go for our own network I still have no desire to alienate either advanced, or less advanced users. For those that want the simplicity of simply typing terms into a box without having to worry about any/everything else, that will be possible. For those who want to tweak to their hearts content, that will be provided for.

[Mowzer]

The hardest will ultimately be your UI, and programs usabillity.

A UI interface can make or break an app. I was once learned the best advice is no UI is the best UI.

If parts of your app can be automate behind the secenes from the users do it. Kinda like with the old vcr example. People always hated using a confusing UI to set the clock on them, now the vcr's can auto set time based on time encoding from some tv stations.

A good resource is... http://www.uiweb.com/

[Scyth]

Originally posted by Ethen
If parts of your app can be automate behind the secenes from the users do it. Kinda like with the old vcr example. People always hated using a confusing UI to set the clock on them, now the vcr's can auto set time based on time encoding from some tv stations.

...until Jan 1st, 2000, upon which the auto-time setting feature of my JVC died.