[lukeschlather]

Can we create a trusted identity service that doesn't rely on centralized highly-trusted nodes? It seems necessary to me that the government or other large associations (/corporations) are the only entities with the resources necessary to secure and maintain decent authentication services. I can't say I'm fond of the idea of maintaining a personal auth server so I can participate in society (and I'm one of our privileged class who can actually contemplate doing such a thing.)

[eternalban]

I couldn't design my way around a centralized bootstrap node, but after that, it can be decentralized. And it has to be highly trusted, so the vision for the ur-node was a bunch of servers in Switzerland inside a vault, run by a public non-profit; subject to random audits; and funded by the IP royalties of the projected patent. (But thank God we can now rely on the good graces of concerned geeks such as Sergey Brin who have millions to spare. (Right Sergey?))

Yes, there is need for user agents running on the user's devices. Your chrome browser transparently maintains a https connection to mother ship (last I checked). I don't think that part of it is really an issue.

[sounds]

About that centralized bootstrap node:

i2p, tor, and dht all rely on some sort of centralized node for bootstrapping. e.g. a fresh install, or when the client has been disconnected from the internet for years.

Would it work to use multiple orthogonal bootstrap methods? i.e. try in a random order any of the following until the client can join the swarm:

• DNS records, http pages, etc. (a straightforward approach like i2p, tor, and dht do)

• "user content," i.e. comments on news sites, blogs, image sharing sites, pastebin, github, etc. that contain the information, hidden using steganography or encryption. A simple google search should not find this user content - the bootstrap method would need to crawl a large number of pages looking for the "signal in the noise," which would make it difficult to find and eliminate all the places the data was hidden.

• "data broadcast," i.e. the bootstrap client listens on random TCP or UDP ports within a certain range. Active swarm peers do "port knocking" in this port range, subdividing the IPv4 space among them so that they visit every IP address within about 24 hours. The range is chosen so as not to incriminate the peers doing the knocking. The waiting bootstrap node will eventually be reached, and the active peer can then transmit the needed data. (IPv4 address blacklists are a must, i.e. do not "port knock" in government address ranges or other sensitive targets.)

By attempting all the methods at random, any that get shut down can be detected and the status updates pushed out to all clients.