xenland / p2pcrypt-server Goto Github PK

The client should boot up a screen that asks the user to "generate" or "load/unlock" an identity.

The client user panel is the window that is displayed when a user has connected to the network(in the future this will change to when the user has typed in their identities password).

When the user has connected to the network the "User Panel" will pop up. This user panel will be divided in 3 parts(vertically). The far left side will feature "icons" stacked on top of each other vertically. The icons will be triggers to completely change the user panel. This left side is imaginatively small (about 64 pixels wide at the most -- height is dependant on the size of the window).

Depending on which user panel icon the user has triggered the middle and right screen will change accordingly but the general rule would be is the middle screen will show "lists" of things and the right side will show "settings/config" options. So if we are looking at the "Messaging" icon , then the middle screen would show "lists of contacts", "add/remove/edit/label contacts", and the right screen would show "Start a text/audio/video conversation with this contact."

The "whosonline" command will return the list of clients and nodes online.

"identupdate" command will allow clients and nodes to tell other clients and/or nodes they are "online", "going offline", "other:????".

If its set to other; the client can request what "other" status message it is (away, sleeping, pooping, go away,etc)

A box that allows the user to type in the intended recipients sha256 address to send the message (The user should already have the recipients public key stored locally).

The client should have a button on the main window a "Generate Identity" button for generating an RSA identity

When sending encrypted messages the message packet should be like the following:
JSON
{"timestamp_sent":"", "message":"message here"}

Encrypt JSON with publickey and sign it with private key

Submit message packet with signature to "nodes".

Await confirmation.

--Finished.

Just a note: GTK/GNOME don't like it when we don't cast our objects errors like the ones listed below show what we mean.

warning: passing argument 2 of ‘gtk_box_pack_start’ from incompatible pointer type

The code could be fixed like the following...

gtk_box_pack_start(GTK_BOX(powerstatus_container), GTK_WIDGET(powerswitch_radio_container), TRUE, TRUE, 1);

The original code was the following...

gtk_box_pack_start(GTK_BOX(powerstatus_container), powerswitch_radio_container, TRUE, TRUE, 1);

Did you notice how the GTK_WIDGET() was present? that is the kind of warning messages we need to remove for the final release

The server crashes with segmentation fault if the string the client sends is invalid, this is from the "JSON C" library. The solution is to find a JSON validator, and validate the JSON before allowing the JSON C library to parse/read it at all.

The dummy client should boot up a "card" like the ratio of a widescreen tv (or more relatble to the new Skype login boot up page)

This is when the real functions of the system are implemented and thus this should part of the project should begin when everything else is working flawlessly.

Receive message packet from server.

Decrypt packet and check/verify signature

Decode JSON into objects that can be parsed.

Save the encrypted message data (not the plain text) into the database.

--Finished.

When a client connects to a p2p node for the first time the client needs to exchange their public key to the p2pnode. So the first thing a client should send upon first contact is like the following....

{"cmd":"identupdate", "client_pubkey":"public_key_here"}

The p2p node can then submit their pubkey/identity and the client will auto save the public key along with the receiving incoming ip address, if the client already has the identity saved the client will disregard the incoming key. (In the future we must ask the user what to do as long as it is set in intermediate mode or higher)

The p2p servers should transmit and receive in JSON name/value pairs as commands.

Not to be a total dick, but if this project ever gets close to complete, the integrity of the code will be fairly important. Perhaps it should be written in a language that does not lend itself so easily to vulnerabilities.

The client should have the ability to manually add a public key of their contacts