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

Discussion:

[GNU/consensus] [SocialSwarm-D] 9. Multiple identity (was: Socialnet_3.0 Meeting 24/25.8.2013)

Michael Rogers

2013-08-05 12:50:36 UTC

9) Multiple identity - you should be able to maintain multiple
identities

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.

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

Melvin Carvalho

2013-08-05 13:20:33 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

9) Multiple identity - you should be able to maintain multiple
identities

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-----

Michael Rogers

2013-08-05 13:33:18 UTC

Permalink

Post by Melvin Carvalho
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".

Post by Melvin Carvalho
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.

Melvin Carvalho

2013-08-05 15:59:16 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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-----