Then you had better also design it not to use IP or TCP or any other Internet Standard.
Not all of them are centralized . . . also, note focus on "MOST centralized".
In other words, the goal you've stated is not going to work, if you are diligent and consistent in pursuing it.
Absolute security (to use an analogy) can impair utility. This doesn't mean we don't try to address the most egregious offenders.
Failing to address ALL aspects of insecurity (especially by dint of not having addressed them *yet*) does not imply a failure to address the most significant aspects.
As for 'centralized', perhaps you might like to review the design and operation of the DNS in a bit deeper detail.
I'm familiar with it. I know it's distributed; I don't see that as relevant.
Exactly. Designing one new thing to rely on another, unspecified new thing doesn't work. There's plenty of experience with this problem.
I'm sure that a PHP plugin which lets arbitrary sockets connect with Tor, without having a separate Tor daemon running, would *not* rely on OpenID - it would just be awfully *useful* for it :)
Rewriting the Tor source code to be (minimally) functional in a server-side scripting language, instead of as a compiled binary - oh yes, I'm sure that *my* project wouldn't have the problem you describe. But it's not this specific example which is standing as the sole use-case, is it? There's the possibility of *any* extension being developed in the future:
Please take a look at: <http://bbiw.net/ietf/ietf-stds.html#StdWay30>
Beautifully expressed, thank you for articulating *everything that I have been trying to tell you* :)
-Shade _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
