On 5 August 2013 15:33, Michael Rogers <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/08/13 14:20, Melvin Carvalho wrote: > > If you examine the goals carefully, I think you will find that they > > need not contradict each other. > > > > I've just said it should be *possible* to login without > > compromising privacy. e.g. if I have use gmail for email, I should > > be able to log in without letting google know, or having to change > > my email account. > > Ah, sorry, I didn't read carefully enough. However, I still think it's > a mistake to say that the system must in principle be able to support > any login method, even if that method violates other goals, such as > privacy. If privacy is one of our overall goals then things that harm > privacy should indeed be "forbidden by design". > Yes, I agree. I didnt say _any_ login method. I said in principle open to more than one. If we could even find 2-3 that would bring projects together that would help scalability. Turning my two points on their head, let's consider the opposite POV. 1. Projects that make it _impossible_ to protect your privacy, e.g. without having to change your email address, are not a good fit, for socialnet 3.0. 2. Projects that make it _impossible_ (even in principle) to login with anything other than single identity style (whatever that is) will lead to balkanization and local minimums, so are not a good fit for socialnet 3.0. I think this is setting the bar quite low, while still allowing excellent projects to be strong any any one area, be it, security, or scalability, or usability. > > > > This is complementary to having a free (as in freedom) identity > > style. There's two extremes of thinking in identity. "one > > identifier to rule them all' -- this hasnt worked and has divided > > efforts. The other is "allow everything". Neither are ideal, we > > need more of a polyglot approach, where we have a roadmap of things > > that are supported (each with a privacy profile) and try and grow > > them with libraries and patches. Consider as an example that > > github allows login via username/password, oauth, ssh, or the git > > protocol. > > I have no objection to a polyglot approach with a roadmap for > supporting multiple login methods (or protocols, or client platforms, > etc), as long as it's understood that some things may never appear on > the roadmap because they can't be reconciled with other goals. > > Cheers, > Michael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJR/6meAAoJEBEET9GfxSfMgQMIAJ0Jz81e725Frw/57Ksc94du > HLTdYid1KqgfyYudgPvinZEOJ0CYxh2fXeoN0MEtOcYsatdz+dK/vpvLsocdRtLo > 5+xgT2YygV+pSQ3eZHQfyajeiAQd2vRFQfDb/cil1NeQr/bBU1I1hP2lvs3uLNpT > eZ2NnZq5pt9aGgXas4KzTReocikSoQE5RhPj7Ru6UjH7yfTDf+ihXlqae8T9JmdA > 740b+zR2v/bL+exPiLuco3ZA2pBqQOGj/P9bVJOd/OTQj4gD8H7XvNkxHM+28ER6 > deo4y/yhOT2q5ye69JDl8ldfAIpvKGVE0cJw9Q6fYl2g7237ONHncApmROT3IIg= > =Z3YG > -----END PGP SIGNATURE----- >
