Peer 2 Peer Open Source Encrypted Text, Voice & Video Communications

[Xenland]

I'm posting up 1 BTC to the winner of this bid for the "Dummy GUI client" please contact me for full documentation and to claim the winner of the bid, basically the dummy client must work on Linux and I must have some way to test it out on Ubuntu so it shouldn't be hard to adapt if its just plain C code.
http://ciyam.org/open/?cmd=view&data=20130124093030696000&ident=M100V131&chksum=f6584b1d

[Xenland]

Major Updates
The command identupdate is fully functional for minimal functionality requirements. it will save the incoming clients publickey/identity if its a unknown identity, if it is a non-new identity it will return with an "success" response code.


Next step is to allow communication between users.

[Xenland]

Minor Update
Relay Message | relaymsg
Command is now fully functional to the minimum requirements. The message and receipts sha256 is saved to the local servers database until it is picked up by the client (or in the future if the message expires it is deleted to save space it is a clients duty to save already received messages)

[Xenland]

Minor Update
Receive Message | receivemsgq
users can now request their messages

[Xenland]

First version published online of the P2PCrypt Client v0.0.2
Does just about nothing lol. Enjoy!

On a serious note the minimal functionality should be there by Sunday this week.

https://github.com/Xenland/P2PCrypt-Client

[Xenland]

Client version 0.0.3 has been published (well the "pre" version still doing testing) right now one can "Generate Identity" and "Load Identity" through RSA 2048 minimum keybit strength.
https://github.com/Xenland/P2PCrypt-Client

[Xenland]

The client code can ping a list of peers to notify each peer that the client wants to be marked as "reachable" through the network which updates a timestamp of the peer last seen.

Ive also had successful send and recieve messages i just need to make the GUI client facliltate an interface for text communication.

The semi final stage of development pre alpha will be implementing gstreamer for audio/video encrypted communications and implementing safe guards against man in the middle attacks.

Also for those that are curious id like to get a profesional software audit team that has a good track record to improve the security of the code once everything is finalized. That step is a few years down the road but those whom are curious that's the plan.

[Xenland]

The P2P Client version 0.0.4 has been published to the github these updates consists of removing all the warnings I previously ignored to increase development testing time. Also I've updated the networking functions. Now that everything is set into place I can more quickly develop the networking integration for sending/receiving text messages and then eventually audio/video communications.

UPDATES:
I accidentally uploaded the client to the "server" code that has been fixed. I doubt this effected anyone that it happened so quickly.

[Xenland]

For those that want more "visuals" like I need'em to think about security, here is some more flowcharts

[marcus_of_augustus]

http://www.gnutls.org/

Here's a library you might find useful.

[Xenland]

http://www.gnutls.org/

Here's a library you might find useful.

Whoa noce that helps alot actually.

[Xenland]

GUI Client Screenshots (Client is still under construction and has ALOT more work to be did hehe)
NOTES: Generate identity isn't displayed as it generates so quickly it almost looks like nothing happens so I have not built anything for the generation page although generation of a RSA keypair does happen successfully.

Boot up screen


"Load Identity" screen


"Connected to network screen" (This will show the contacts/messages, settings, etc tabs)

[Xenland]

@ Xenland

If you think locking this thread is the end of the stolen logo idea story than I suggest you to think twice. I have already PMed theymos and will PM other
mods here, let's see what they think about the case.

Thanks for the heads up. I'm sorry I don't like your logo and that message wasn't intended for just you, it was intended for every artist that sent in the same logo(practically) and when I back out they all think I'm stealing their idea and threaten me, we can't have a community that advocates "vicious circles". I don't want that in my bitcoin reality where they feel "obligated" to pay because they are being intimidated by others. You can be rest assured your intimidation isn't helping your case.  As a believer in a voluntary society(me), I would never steal anyone work so its hard for me to take anyone accusing me of "stealing" seriously.

 I encourage you to "report me" if that is how you feel, but I don't see the benefit of anything your doing except wasting both our time. So I shall ignore you from here on out unless you have a reputable lawyer you would like me to get in touch with. Good day to you sir.

[Xenland]

Before somehow another mishap begins I shall post what is produced so far for the logo as temporary until the P2P Crypt organization can afford a $300-$500 quality logo as my expectations were too high for the budget.





here is the "abstract symbol"

[Xenland]

v0.0.7_pre10 of the client has been uploaded.
Receiving of messages is possible but displaying and saving them is the current task at hand.

After receiving works, sending them will be much easier to implement.

[Xenland]

I've been waiting for my client to break at the "SQLite3" areas dealing with "multi-threading, and now it has and this problem so I'm converging the code to support multi-threading in SQL queries. This should make the pre-alpha testing alot less pain for for debugging, sit tight pre-alpha testing is on its way.

[Xenland]

I've converged all the old code in to a rewritten client to better accommodate the future commits/features to come, and here are the screen shots of the new pre-alpha test release most of it is similar the last two are different menu screens I believe.


GENERATION SCREENS



LOAD SCREENS

[Xenland]

I'm trying to think of a way to turn a sha256 output into a consistent string compression scheme but based on what I know about compression I think 50% is the string limit and that’s if the table look up is non-characters. I thought it would be cool to some how turn a sha256 output into something like B3 H1 U8 Z8 I0 T1 Q5 W2 but string compression as I know it can only get down to 64 characters. If anyone know better than me about string compressions that could facilitate something like this that would be awesome. Instead of copying and pasting a sha256(64 characters) string we could copy and paste a 14 character string instead.

[justusranvier]

I'm trying to think of a way to turn a sha256 output into a consistent string compression scheme

http://en.wikipedia.org/wiki/PGP_word_list

[Xenland]

I'm trying to think of a way to turn a sha256 output into a consistent string compression scheme

http://en.wikipedia.org/wiki/PGP_word_list

Nice, yeah someone else suggested the same thing as well just recently.
As for updates that happened last night, "identity handles" will be computed like the following md5(sha256(publickey)) and then the md5 will be divided into 8 groups of 4 letters and each group will be assigned a word. By my calculations that means I need a dictionary word list of the size of 58,000 to assign to each possible combination group. This will cut down the total output of words down to 8 words instead of 15+. I'd also like to get different language word lists as well to make it a Multi-lingual but that will be set into the far future for now.

Since the identity handles are only for saving visual screen space and for copy and pasting into the contacts list to "auto-retrieve" the recipients public key from the network if any md5 collisions were to happen it the only negative results would be the client saves "both" public keys of each parties colliding, and that’s about it. --In case someone wanted to point out that md5 is insecure anyways.