No one yet? Disappointing, but my chin is way up still.

Also like i said before its recommended to submit rough drafts and move on to the last stage of elimitnation(otherwise if you are free to do so, make the finished logo)

Twas a fun project to work on indeed.

I loved that site, it was the only thing (at the time) that kept me connected to Bitcoin (even though withdrawals were disabled and I couldn't cash out).

I could remake that site in about week fully completed with a great theme for a few BTC, Who wants to throw in to the fund?

UPDATES:

The GUI is finished
The only thing left for the GUI is to integrate signals, and events for the purpose of integrating the server (networking) it self to be linked into the button events

The server can accept UDP connections for "small commands"
However the the networking is all "dummy" functions with fake responses at this point, so no command does "anything" quite yet

The server in the future will open up TCP connections for file transfers, and other things that need to guaranteed to make it there

Also what might be smarter for everyone is for those who would like to participate submit "rough drafts" of what you want the final to look like, and I'll choose the winner to build the final and the winner will get paid.

lol no worries mate

Submit as many as you want

Hello to you whom is interested!

I am developing an application that was originally intended for me and a friend to utilize to gain back our privacy against whom ever is listening. Under my personal opinion I don't pay for my ISP to spy on me and mine-data and sell that compiled information at their benefit only(This goes for other nodes that eavesdrop across the internet that is beyond my control as well). I figured others might need the same privacy rights as well, so I'm attempting to develop a desktop application that can establish a secure connection and help you communicate with your friends, family or business partners through by any media, text, audio, video its like Skype but with true peer to peer support (a portable embedded electronic solution is being developed for the release in the future).

So I ask you that I need a Logo that is great for the Peer to Peer Encryption project (AKA P2P Crypt). I would hope the logo to be adaptable to an extent as I'd like to use the Logo for both the desktop application, the website and if it is good enough the "portable embedded electronic solution"

3 BTC is up for grabs
for the best logo presented to me, I hope to see a great one in a month and end the bounty there but will go on as long as it has to.

Bounty has been posted to the following link: http://ciyam.org/open/?cmd=view&data=20130124024531247000&ident=M100V131&chksum=e47c82ee

Some Updates: I've published the updates of what I have so far as being stable into the github repository. That being the server can now receive connections, generate and save an identity locally into the sqllite3 DB, the GUI is just about finished: I just need to add two buttons and a "console,log panel text output" and the GUI is finished.

The next step is to finish the GUI and get the server to accept JSON RPC commands.

whoa, that does sound revolutionary indeed, And yes I get exactly what you are saying now.
I'll have to ponder on that idea, and do some research on name-coins source code (or perhaps even hire someone to do the name-coin integration), I like it though its basically everything i described but in this case instead of cost in hash power for clients, it costs in namecoins and the namecoin verification nodes(miners) are paid to keep "key integrity"

perhaps namecoin does something that I'm not aware of as far as man in the middle attacks but im pretty sure that if i gave you my name coin address, an attacker(lets say a moderator in this example) could replace my namecoin address/id on the post, I don't understand how namecoin is solving this MITM issue (or perhaps I'm looking at the namecoin solution different then what is being presented)

Very good input,
Yes we are having the app default to AES/DES/Blowfish for streaming capabilities. the MITM attack can happen regardless of the identity generation method used. so to solve the MITM attack we use the web of trust to evade that issue; however I see your point now that I've thought it through Public key ids should be reduced down like Bitcoin/Namecoin strings for easy copy and pasting and for easy to remember as well.

Thanks for the heads up; in that case, I'll stay the course and learn from other projects and integrate the best functions into this project.
I think I'll incorporate hashcash for all p2p crypt messages to reduce spam, and if you want to spam the network it'll cost you hashing power + electricity

Oh one difference between retroshare and this project is that retro share doesn’t have a "streaming" option, I'd imagine that p2p crypt nodes are only used for "key server and relaying data".

 so on a side node:
if a receiving user isn't online all nodes will be advised to save data for a optimal amount of time(nodes can refuse to relay data, but the more a node is "known" that it refuses to relay most  data received then other nodes will be label that this node is a "leech" in their local DB rating systems. Meaning it is still advisable that this node could be trusted for relaying and communicating with, they just might be asshats about their bandwidth and shouldn't rely on them as well as other nodes limit the bandwidth for the leech as well.

correct

Your question fails to provide what kind of relation ship I have with josh in the example, so I’m not sure what kind of trust we are talking about. The website-trust is for "login/sessions" and even in the future for social networks to "request data" that can been auto-filled after unlocking the requested information with a password, anything beyond that i don't understand your question.

let me clear up that you used Account and identity interchangeably but separately, if you create a new account/identity you can still load up your list of "Trusted nodes" and "untrusted nodes" but to the network you are an untrusted node/client because you are new all nodes should be advised "NOT" to trust you until you build some trust.  You can build trust by relaying data and other nodes will verify your data against other nodes thus its impossible to know (Just like Bitcoin) who trusts who. UPdate/Edit: Also makes it expensive to get anything on the network when there is super complex webs of trust/attacks going on why if half the network was being attacked that would make it difficult for more attackers to join in because its unknowable how far your "failed" data will traverse through the p2p nodes considering that nobody will ever know the "true" levels of trust everyone has applied to every other client/node.

I'd imagine in my system that you would have to take 3 months to a year to get the whole system to FULL trust a new online identity and your trust could be broken back down to 0 (or even in the negatives) in a day if you start to relaying bad data. (In the future someone could build an add-on or module or even into the protocol that alerts other "Trusted" nodes that this X node is relaying alternative data and could be bad, but i just wont know if this is possible with so many false positives that could be attributed.)

This is with out the "bitcoin" type system integrated... In the future not only will it be (CPU) costly to create the message I'd imagine the user could have to generate hashcash/bitcoin target digest output before the message is accepted by the p2p nodes for relaying (CPU Costly to send message, Easy/quick to verify and Relay messages)



Thanks for the retroshare link(and the other resources as well cheers!), that GUI looks exactly how I envisioned, Perhaps I could build on top of it and contribute to the project (didn't get a chance to see the license). Looks like a great application to fool with and thank  you for your great questions, I hope I provided some interesting answers as well.

More side nodes:
I realise this idea isn't new by any means but I think it will be the first to make it into run-time.

Also I'm going to declare the p2pnode server as X11/MIT license in the next commit on github. The client however will have free and pricing options

I'm looking for someone to help me develop the GUI in C and GTK2.0 I nessecary I can pay some Bitcoins if its worth it. Code should be easily flexible so I can hook actions into the pages and buttons. Contact me for more details.


https://docs.google.com/drawings/d/1NsXZZYmtuigO4SfOZAbMY2BE9Czupf06VOn1El15d7M/edit

Get Received By Address only works if you have the private key in your Bitcoin client. The BDK is aimed at making Bitcoin client easier to communicate with and to intuitively apply math with out worries of precision or rounding issues.

How ever if your using the Blockchain.info api in php you would want to use the "json_decode()" function and then you can use the php array that is returned with the BDK library.

No problem-o.

Good question; I'd imagine the p2p nodes are basically super nodes and clients only relay small bits of data .
If the client trusts the source of the private key, it doesn’t matter how the data is sent or received as. (Example, if I trade keys face-to-face it won't matter how the data gets there or received). The issue is that people from china can't all practically swap keys face-to-face, and not everyone is a "Crypto-wizard" to know how to evade "Man in the middle attacks during key exchange over an electronic interface". This is when the "P2P node trust" system comes in to play, basically two people exchange keys on the non p2p network (perhaps a facebook message or IRC). Once to people have their public keys they now can ask the p2p nodes to validate the key by asking for and validating various information transparently for the user.

Why do i think this is awsome?
As of right now for a "layman" to accomplish this they have to be educated that they need more than one channel of communication to prove that there was not a man in the middle attack during the trading of public keys, so this solution makes the whole experience transparent becuase unless you meet face to face for publickey exchange your most likely going to exchange public keys through gmail, hotmail, IRC or facebook and unless a "layman" is educated to "resend the same key on a different email address or chat channel and "match the public key letter by letter", then they are vulnerable to man in the middle attacks".


Other notes....
New clients can build trust by helping relay small chunks of data;
the actual trust is gained by other nodes if your data seems to match up with nodes that those recieving nodes trust, the more your information matches the more your trusted over time, however if your client is relaying 100% or even 20% false data all nodes are advised to deny data from that client or node (A better solution would be to lower the priority of processing from your node as an attack could be happening and "triggered block occurred")

This p2p crypt app could also provides other opportunities
*Like perhaps even be the leader of SSL certificate authority systems in the far off future: I ponder that if everyone online has everyone else’s key who is currently online along with a rating of "trust" that node is then perhaps we won't need to have CA's at all because there is no more risk of man in the middle attacks (which is why there is CAs certificate list is in browsers).

*SSL and non SSL enabled websites could rely on the p2p crypt trusted web to initiate a secure login session, cookies and other methods to turn HTTP into a "State full" protocol literally is 2+ decade old technology and computers getting faster while captcha methods failing; The sessions are under constant attack and its time to move on.
HTTP could be used to serve webpages while P2P crypt could allow websites to initiate a "secure session" regardless of an SSL connection. this could allow safe login sessions that are harder to attack on.


Just some ideas to "mull over" guys Obviously we going to see how the system works up over time but this is the ultimate picture i think.

Essentialy its the same setup as a CA but this is different in that there is no stigma in "authority" just "secure communication" associated with the project. The other differences is that its more real time than "pay, generate, distribute".

I plan to use RSA Keypairs for the identities. Communication could be transparently chosen/negotiated in the back end or a config file. If a communication method can't be agreed upon the application should use a default that every app could "default" too in that event. Most likely AES or blowfish perhaps.