[P2pim-devel] What to do next

[James H. <hol...@ke...>]

With one real release done it's time to figure out what to do next. These are 
the things that I want to get done before calling it 1.0.

Protocol Security-
This should obviously be an ongoing project, but before we go 1.0 I want to go 
through and see if there's any glaring security problems in the protocol 
itself. There was already the problem with the FAKE command. I want to catch 
anything else like this as soon as possible.

File Transfers-
I still have no idea how to do this easily, unless transferring a File object 
does actually transfer the file. What I think we can do now is set up how to 
start the transfer. The way I thought of it before was that the UI can call 
the sendFile method in Control. Control would add the file to a list, and 
send a send request to the other client. It would return a number to the UI 
that it keeps track of. When the other client accepts the transfer, they send 
back that number. That number could be used to identify which file it wants 
for both the UI and Control. The question is how to do the actual transfer.

Multiple groups-
There's lots of ways to do groups. We can give each group a different group 
IP, and a person would enter the IP to join it. It could be invitational, 
where a person in the group sends an invitation that includes the information 
the person needs, whether it's an IP or port number. We could broadcast group 
messages like we do now and add a second header that identifies a group. 
Control could filter out group messages that the Client shouldn't care about. 
What other options are there?

Advanced options-
I have a few ideas for "advanced options". First, the user need to be able to 
specify the multicast IP used. Right now the first private IP is hard coded. 
Without any filtering on users, the list could get large pretty quickly. Port 
options would be handy too, just in case.

Handling of username conflicts and users who don't disconnect gracefully-
I think that each user should have an identifier besides the username. We can 
generate a random number the first time the program is run, and then on 
subsequent logins send that number. This way other clients could tell whether 
or not the person trying to reuse a name is the person who had the name 
before. If/When we add security this could easily be switched to a public 
key. Of course it would be very easy to fake your identity with this system, 
but if we continue with the assumption that administration is handled outside 
the program that's no big deal.

User profiles-
I could implement this using code that I had put it but never finished. I was 
planning on having clients let each other know when they seemed to be missing 
people from the list. This would improve the reliability of program. Also, on 
login, a user could put himself along with his profile on the "missing" list. 
This way they can reliably transfer what could be a large amount of 
information, instead of tacking it onto HELO; and hoping none of it gets 
lost.

I think the username conflict issue is the most important. I want to get that 
done right away. User profiles will probably require a protocol change too so 
i'll get that done at the same time.

Any comments?