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 15:20:33 +0200




On 5 August 2013 14:50, Michael Rogers <address@hidden> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/08/13 13:23, Melvin Carvalho wrote:
>> 9) Multiple identity - you should be able to maintain multiple
>> identities
>
> I was hoping to propose 2 aspects on this:
>
> 9.1 _Privacy
>
> _ It should be possible to log in to socialnet 3.0 without
> compromising a user's privacy.  For example, if I have a gmail
> address, there should be an option to log in without informing
> google.
>
> 9.2 _Identity Freedom
>
> _ No style of identity should be forbidden by design.   If a
> project says 'we only will accept GPG keys' or 'we only will accept
> email' or 'we only will accept http profiles' or 'we only will
> accept xmpp' or 'we only take psyc URIs' -- then you are going to
> get balkanization.  You have to be prepared to allow freedom rather
> than to censor.  It's appreciated that not everything can be
> programmed at first, but at least major ecosystems should be aimed
> to be supported.
>
>
> Is there anyone that cannot live with these two goals?

Hi Melvin,

There are situations where the two goals would contradict each other -
for example, logging into a system with a Facebook account is
incompatible with maintaining one's privacy.

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. 

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.

If we agree in principle we should offer at least some privacy as an option, and allow some freedom in identity, we can can make a short list of projects to hack on, and build out the technical libraries to make it work...
 

Perhaps we should combine goal 9.2 (identity freedom) with goal 10
(protocol agnostic) to create a new goal 10: interoperability? As I've
already written on the wiki, I think it's premature to specify that
particular protocols (or client platforms, or login methods) should be
supported. Those are implementation details. We should focus at this
stage on goals that are relevant to users rather than implementers.

On the wiki I've marked several other places where I think we're
focussing prematurely on implementation details.

Cheers,
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJR/5+cAAoJEBEET9GfxSfMKG4H/0e8ida9veCllb8JOMIqyFRr
iYvLeom9nw3j8pkQdraIyz2cqvt36SPgfCVSD4yQ5IedIeFqtKZ1FCj53A0Ih0n9
AJr7JOmeIpEloNqJi9LWrg2avjcnlFuPHGKgkLToxPQtMfHya5wFRtCS7BHdPnI6
JjOrBKg8Oh/ddpI/rZSQqGg/I5x6ssjZp6KJQhE9AwvL0bdL6ucBV6X94NsNZyyf
76JtTbH8iqKA/G36J9PcJGBjKkkSva3JuHZuarAVlmj9zUkCrf3bedkGAa+87Sdr
zQptmeKGeHCft1uGt2ViM0hIgBzfXROiCLDTO0gL7/bgJs0e+U2Q7/CKLhQW2vs=
=1J4G
-----END PGP SIGNATURE-----


reply via email to

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