Quote from: paybitcoin on January 17, 2013, 08:21:50 AM

So there would be a component that would operate like a PGP/GPG keyserver, but with additional validation over other channels like what the the CACert Web of Trust CA is doing.

correct

Quote from: paybitcoin on January 17, 2013, 08:21:50 AM

Very true, you just have to make sure the validation process has air-tight security - for example, if someone posted a public key for Josh on this site (with some cleanup to make it look legitimate of course) is that enough trust? Obviously not. Systems like CACert require a face-to-face meeting with trusted community assurers and checks of government ID to finish the signing process for the Web of Trust cert. It depends on what level of trust you want to place in the system.

Your question fails to provide what kind of relation ship I have with josh in the example, so Im 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.

Quote from: paybitcoin on January 17, 2013, 08:21:50 AM

This would be difficult to protect against, what's to stop me from feeding a node bad data continuously with a coordinated attack from multiple new accounts, slowly increasing the percentage of bad data it relays to take it offline? How does the node itself verify the trust of the original party when it is deciding whether to pass the data along? Also, how do you know you are talking the real person's identity, and not someone that has created an account claiming to be that person?

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)

Quote from: paybitcoin on January 17, 2013, 08:21:50 AM

This I have to object to, SSL works well, is extensively tested, and highly trusted. HTTP can be stateful without any encryption at all. User authentication/captchas is a separate issue, and in that area it is true that the web of trust would provide an additional authentication option (possibly taking the place of SSL client side certificates.)

Also, how does your system compare to something like Retroshare?

I know the end goal you want to get to for the trust side, since having a working system of decentralized trust is a 'holy grail' for online systems, and a lot of research has been done in this area as it contains a lot of hard CS problems. The wiki article on Web of trust is a good resource, and there are many papers (search for 'trust management problem' or 'decentralized identity'.)

Even just a face-to-face-public-key-sharing (or via Bitcoin public keys...) crypto app would be very useful in its own right, however. In any case, I am looking forward to seeing where you take the project!

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.