consensus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU/consensus] [SocialSwarm-D] 9. Multiple identity (was: Socialnet


From: Melvin Carvalho
Subject: Re: [GNU/consensus] [SocialSwarm-D] 9. Multiple identity (was: Socialnet_3.0 Meeting 24/25.8.2013)
Date: Mon, 5 Aug 2013 17:59:16 +0200




On 5 August 2013 15:33, Michael Rogers <address@hidden> 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-----


reply via email to

[Prev in Thread] Current Thread [Next in Thread]