unknown
1970-01-01 00:00:00 UTC
<div class=3D"im"><br>
><br>
> I agree although Linus was also an exceptional mind, coder and<br>
> community leader. =A0He had a pure focus, ie to port the UNIX kernel<b=
r>
> to GNU as free software.<br>
><br>
> In the social web we cant assume that we'll be blessed with someon=
e<br>
> as brilliant as Linus, and there is mixed focus, so working<br>
> together becomes important, which is one area where standards can<br>
> maybe help. =A0I say *maybe* because a standard that is restrictive<br=
> may sometimes be counter productive.<br>
><br>
</div>*** Yes! We don't need a leader, we need leadership. And consensu=
al<br>
leadership. Based on ethical values, and clearly defined objectives.<br>
<br>
The more I look at it, the more I think we should go for the simplest<br>
possible thing, and leave convenience out of it, because convenience<br>
is a vector for surveillance and control.<br>
<br>
Ironically, Mozilla made a "Prism" project some time ago that wou=
ld<br>
allow to run a feature-stripped firefox to reduce risks, and make the<br>
web app look more like a native OS app. A concept that Ubuntu recycled<br>
pretty well, so much that it became itself a vector for<br>
commodification of the user into a consumer.<br></blockquote><div><br></div=
=A0 They are in the church of "your email is your identity" -- le=
t's be clear this is an unnecessary restriction with will not scale.=A0=
Other projects (not mentioning any names) *cough cough* are also in this r=
eligious sect.=A0 <br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
><br>
>> Before we can start to speak about standards, we need to have a<br=
>> consensus of those interested in a post-faceboogle social web<br>
>> about its structure and capabilities. You may call this worthy of<=
br>
>> a standard in itself, but very basic properties have to be agreed<=
br>
>> upon before serious efforts<br>
should be<br>
>> invested into realizing it.<br>
><br>
</div>*** Oh, I think we're on the path to reaching a GNU consensus on =
free<br>
social software :)<br>
<div class=3D"im"><br>
><br>
> Together with Elijah of the LEAP project we came up with this list<br>
> of priorities:<br>
><br>
> 1) Client side encryption<br>
><br>
</div>*** +1, but only if it's end-to-end, otherwise, see (8).<br>
<div class=3D"im"><br>
><br>
> +1 Certainly should be an option, or a default, but key management<br>
> is hard and a topic in itself, it takes time. =A0I would say a goal<br=
> to build towards.<br>
><br>
</div>*** We tend to always repeat the same: public communication does not<=
br>
need to be encrypted, so it's a use case that should easily be agreed<b=
r>
upon. Yet, everything that is not explicitly public is, in my opinion,<br>
to be private: that means, in the current context, strongly encrypted.<br><=
/blockquote><div><br></div><div>Great point.=A0 We've not even solved t=
he public version yet.=A0 When we do I suspect the encrypted version will b=
e easy, just some shared keys and AES or another symmetric cypher, asymmetr=
ic PKI, or hybrid, or security by obscurity.=A0 I'm not a huge believe =
in advertising which crypto algorithms are being used to the whole world, t=
hat all the relevant parties know should be enough.<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
> 2) Social graph obfuscation<br>
><br>
*** +1<br>
<div class=3D"im"><br>
><br>
> 3) Self determined data storage<br>
><br>
</div>*** +1. I've been looking into OwnCloud 5 and Git-Annex lately.<b=
r>
<br>
><br>
> 4) Scalability<br>
><br>
*** +1<br>
<div class=3D"im"><br>
><br>
> 5) Integration of old friends on legacy networks (which would<br>
> compromise 1 and 2 for those, of course).<br>
><br>
><br>
> +1 =A0Some projects are underway to build this kind of 'driver'=
;<br>
><br>
</div>*** Are you talking about Friendica (probably the largest surface of<=
br>
contact with legacy networks), GNU Social (AKA StatusNet+Free Social),<br>
others?<br></blockquote><div><br></div><div>Freindica is one sure.=A0 <br><=
/div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
><br>
> 6) High availability - you should be able to access your data when<br>
> you want it.<br>
><br>
</div>*** Including OFFLINE! I'm not sure whether that is covered by th=
e<br>
more server-sideish "HA".<br>
<div class=3D"im"><br>
><br>
> 7) Device portability - you should be able to access your data<br>
> from multiple devices at the same time<br>
><br>
</div>*** +1, and with various ACLs: I can't trust my phone as much as =
my<br>
laptop for example. And certainly not a random computer in a random<br>
cybercafe. [1]<br>
<div class=3D"im"><br>
><br>
> 8) Client choice - you should be able to use a mobile, desktop, or<br>
> html5 app client (once webcrypto is deployed in browsers).<br>
><br>
</div>*** Honestly, I'm not sure that is a sane decision. Not until the=
re<br>
are some things fixed:<br>
<br>
=A0 - 1 TLS certification authorities (utterly broken and mostly<br>
untrustable)<br>
=A0 - 2 TLS perfect forward secrecy implementation everywhere (servers,<br>
browsers) including protection against TLS-downgrade attacks. That's<br=
mostly a matter of proper configuration though.<br>
=A0 - 3 Javascript protection: Libre JS to ensure the code run on the<br>
page is genuine and not malicious<br>
=A0 - 4 proper protection against XSS, CSRF, and other MITM<br>
<br>
3 and 4 are way out of reach at the moment. HTML5 is bringing new<br>
attack vectors, and the development of the Web is going towards more<br>
usage of centralized resources (+1, Like, Login with X, analytics,<br>
etc.) without mentioning javascript-less CSS-based or DOM-based XSS,<br>
plugin-based infection, and mobile phone network insecurity as a whole.<br>=
</blockquote><div><br></div><div>I dont believe in trying to create perfect=
security, security should be "good enough" then you start the ar=
ms race between attackers and defenders.=A0 Facebook didnt even start with =
https remember and go to 100 million users.=A0 In any other project I'd=
be a security fundamentalist, but for a social project, users count, this =
often seems to be underestimated...<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
To me (8) is the convenience door open to keeping the spyware operate<br>
as is. We should aim instead for much more ambitious things: secure<br>
hardware, end-to-end encrypted connections (see (1)).<br>
<div class=3D"im"><br>
><br>
> 9) Multiple identity - you should be able to maintain multiple<br>
> identities, and choose to link them or not.<br>
><br>
</div>*** +0 Again I see that as a convenience door open to spooks. True<br=
unlinked identities are to remain... unlinked. Maintaining multiple<br>
identities on a single device for example, is hard to protect in case<br>
it is compromised...<br></blockquote><div><br></div><div>The user should be=
in control of their identity.=A0 They should be allowed to have their iden=
tity the way they want it, so long as it doesnt impinge on any other user.<=
br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
><br>
> These are sometimes called 'nyms' (short for pseudonyms) ... y=
es<br>
> it's important to think in terms of multiple identities, most<br>
> systems restrict you to one, and even worse, one that is a subset<br>
> of their particular world view.<br>
><br>
</div>*** +1. Identities are made to recognize people.<br>
<br>
It is in the interest of bureaucracies and surveillance systems to<br>
recognize people globally. That's why they want you to bear a "fam=
ily<br>
name" and well as a "given name", to get a passport and an i=
dentity<br>
card (a recent invention that's supposed to prevent crime, but<br>
everybody knows that criminals can forge identities), or in a too soon<br>
future an implanted chip (now sold as "cool" for VIPs in hype clu=
bs,<br>
"life saving" for people with medical conditions or soldiers,<br>
"protective" for inmates, or "efficient" for cattle).<b=
r>
<br>
But in social networks, people are used to share identity with their<br>
own circles, and independently of their "Real Name (TM)". If you&=
#39;re<br>
"Mister Smith" to your employee, you're "John" for =
your neighbor,<br>
"daddy" for your children, "honey" for your wife, "=
;spud" for your<br>
former classmates, etc. Your identity only means that the people<br>
susceptible to interact with you know who they are addressing<br>
consistently, and you do as well know who is talking to you.<br>
<br>
Identity is not about 1 person, but about a bi-directional<br>
relationship. I have nothing to do with the NSA, nor any suspicious<br>
government, nor any marketing entity that want to commodify me. So to<br>
them my identity must be ephemeral.<br>
<div class=3D"im"><br>
><br>
> 10) Protocol agnostic - you should be able to cross-communicate<br>
> with different protocols, be they XMPP, HTTP, or p2p based.<br>
><br>
</div>*** It depends. If I'm willing to use the Briar Transport Protoco=
l,<br>
obviously I don't want nor need that it interoperates with anything<br>
else. Again, spooks might want that, but not me.<br>
<br>
If I want to communicate using a protocol, with someone who is using<br>
another, there should be a possibility for me to bridge that<br>
communication to that protocol, but I would not put that as a requirement.<=
br>
<div class=3D"im"><br>
> Although I would love to see this happen, it's perhaps taking on<b=
r>
> too much for the first phase.<br>
><br>
</div>*** Yes.<br>
<div class=3D"im"><br>
><br>
> 11) Secure groups - groups with membership determined<br>
> cryptographically. Groups function as a virtual user, with all<br>
> users in the group able to receive and send as the group, because<br>
> they share a private group-key.<br>
><br>
</div>*** +1. Private group communication is fundamental.<br>
<br>
It's also a hard problem: sharing a private group key was discussed at<=
br>
length last year during the hackathon in Berlin. Two main issues were<br>
raised: 1) how do you bootstrap the key? 2) what to do when people<br>
join or leave a group?<br>
<br>
So maybe the notion of group must be revised as well to match<br>
volatility of the concept. Transient groups might form and want<br>
ephemeral communication; more stable groups will arise and want<br>
perennial archives. Etc.<br>
<br>
*<br>
<br>
For me, most of the points you propose are conveyed by the<br>
GNUnet/Secushare project, which you mention in your presentation, and<br>
that is the explicit goal of the GNU/consensus project. For which I'm<b=
r>
being an opportunistic Bolchevik and wish for a (somehow short)<br>
dictatorship of the Web people until we are ready to move to a true<br>
p2p architecture. :)<br>
<br>
=3D=3D<br>
hk<br>
<br>
[0] The GNU/consensus Whistle is an upcoming monthly newsletter that<br>
should start its life soon. A draft is available on the GNU/consensus<br>
wiki at <a href=3D"http://libreplanet.org/wiki/GNU/consensus/whistle/002013=
-07" target=3D"_blank">http://libreplanet.org/wiki/GNU/consensus/whistle/00=
2013-07</a><br>
and you're welcome to edit it.<br>
<br>
[1] 3 years ago:<br>
<a href=3D"http://libreplanet.org/wiki/User:Hellekin/A_User_Perspective_Of_=
GNU_Social" target=3D"_blank">http://libreplanet.org/wiki/User:Hellekin/A_U=
ser_Perspective_Of_GNU_Social</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.12 (GNU/Linux)<br>
Comment: Using GnuPG with Icedove - <a href=3D"http://www.enigmail.net/" ta=
rget=3D"_blank">http://www.enigmail.net/</a><br>
<br>
iQIcBAEBCgAGBQJR7YfuAAoJEEgGw2P8GJg9wBEP/Rdc/Akdiei2xEJ6t2aT6Qvn<br>
WHbD72x9TdmP2Q5jj5iHJPnZO3xFCeRx73ZXeXbZKjVTOkP2pG+d5KXCVq7/wUwk<br>
joy0hptBJVW6LSdv1hggf9s4emwfT0K8SyNxl2t5l1KC5EPVLcflZYWsQ2lmw61C<br>
8JJPM2QtPVJbAQ+FiNZnK4DJebzfUPVvkQ19ImANrm/SPAtO0LqnO3UUXWbtRmLf<br>
IXS43+PQn+Yq8Gm/hLVZxaZDR4RVF86eER2fV/993+DUZJczMogNapslQ19Z8VRo<br>
mXXFhg2T9zP1A8w4ZGJJPB6ar5havCBlaS7xWp+zwTDuuwy3pt4VkLpGGG/oNRM5<br>
NGDEed3pGJXloyZ2kapk8vowcVhT8ano/f+uJCbMavhU6f407CjpDAEo+Y1wWhbl<br>
whWOI+oOOkitQfSbSwPP1I2x/JSCJMhI2lSzhC8o1/cMofbmZV8z3tEFAeizFtBa<br>
1VHXYbVzNxhzgDVQqSe8ioj7Q2bd55hvPHaTHdxwTibENjyErij/M6bZJ1wIEYEi<br>
WT+dlePfhfa2/LdVsi5i5BJ4/u+GWLhFKFE9lQevdECJkdS3wzuCBd6SRK3poPee<br>
I5TmAiJZT3XfGZaAXKPjaP/zEK0JoXtiDnI5oki1t5B6BJERT9hSIPxxc4/G1rUZ<br>
xH960Bxxi8w8gYe/KgJi<br>
=3DLPX5<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div></div>
--001a11c3504cd7061604e21f4d6a--
><br>
> I agree although Linus was also an exceptional mind, coder and<br>
> community leader. =A0He had a pure focus, ie to port the UNIX kernel<b=
r>
> to GNU as free software.<br>
><br>
> In the social web we cant assume that we'll be blessed with someon=
e<br>
> as brilliant as Linus, and there is mixed focus, so working<br>
> together becomes important, which is one area where standards can<br>
> maybe help. =A0I say *maybe* because a standard that is restrictive<br=
> may sometimes be counter productive.<br>
><br>
</div>*** Yes! We don't need a leader, we need leadership. And consensu=
al<br>
leadership. Based on ethical values, and clearly defined objectives.<br>
<br>
The more I look at it, the more I think we should go for the simplest<br>
possible thing, and leave convenience out of it, because convenience<br>
is a vector for surveillance and control.<br>
<br>
Ironically, Mozilla made a "Prism" project some time ago that wou=
ld<br>
allow to run a feature-stripped firefox to reduce risks, and make the<br>
web app look more like a native OS app. A concept that Ubuntu recycled<br>
pretty well, so much that it became itself a vector for<br>
commodification of the user into a consumer.<br></blockquote><div><br></div=
<div>I love most of what comes out of Mozilla, but underwhelmed with Perso=
na, which is the identity solution that sits in the middle of most things.==A0 They are in the church of "your email is your identity" -- le=
t's be clear this is an unnecessary restriction with will not scale.=A0=
Other projects (not mentioning any names) *cough cough* are also in this r=
eligious sect.=A0 <br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
><br>
>> Before we can start to speak about standards, we need to have a<br=
>> consensus of those interested in a post-faceboogle social web<br>
>> about its structure and capabilities. You may call this worthy of<=
br>
>> a standard in itself, but very basic properties have to be agreed<=
br>
>> upon before serious efforts<br>
should be<br>
>> invested into realizing it.<br>
><br>
</div>*** Oh, I think we're on the path to reaching a GNU consensus on =
free<br>
social software :)<br>
<div class=3D"im"><br>
><br>
> Together with Elijah of the LEAP project we came up with this list<br>
> of priorities:<br>
><br>
> 1) Client side encryption<br>
><br>
</div>*** +1, but only if it's end-to-end, otherwise, see (8).<br>
<div class=3D"im"><br>
><br>
> +1 Certainly should be an option, or a default, but key management<br>
> is hard and a topic in itself, it takes time. =A0I would say a goal<br=
> to build towards.<br>
><br>
</div>*** We tend to always repeat the same: public communication does not<=
br>
need to be encrypted, so it's a use case that should easily be agreed<b=
r>
upon. Yet, everything that is not explicitly public is, in my opinion,<br>
to be private: that means, in the current context, strongly encrypted.<br><=
/blockquote><div><br></div><div>Great point.=A0 We've not even solved t=
he public version yet.=A0 When we do I suspect the encrypted version will b=
e easy, just some shared keys and AES or another symmetric cypher, asymmetr=
ic PKI, or hybrid, or security by obscurity.=A0 I'm not a huge believe =
in advertising which crypto algorithms are being used to the whole world, t=
hat all the relevant parties know should be enough.<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
> 2) Social graph obfuscation<br>
><br>
*** +1<br>
<div class=3D"im"><br>
><br>
> 3) Self determined data storage<br>
><br>
</div>*** +1. I've been looking into OwnCloud 5 and Git-Annex lately.<b=
r>
<br>
><br>
> 4) Scalability<br>
><br>
*** +1<br>
<div class=3D"im"><br>
><br>
> 5) Integration of old friends on legacy networks (which would<br>
> compromise 1 and 2 for those, of course).<br>
><br>
><br>
> +1 =A0Some projects are underway to build this kind of 'driver'=
;<br>
><br>
</div>*** Are you talking about Friendica (probably the largest surface of<=
br>
contact with legacy networks), GNU Social (AKA StatusNet+Free Social),<br>
others?<br></blockquote><div><br></div><div>Freindica is one sure.=A0 <br><=
/div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
><br>
> 6) High availability - you should be able to access your data when<br>
> you want it.<br>
><br>
</div>*** Including OFFLINE! I'm not sure whether that is covered by th=
e<br>
more server-sideish "HA".<br>
<div class=3D"im"><br>
><br>
> 7) Device portability - you should be able to access your data<br>
> from multiple devices at the same time<br>
><br>
</div>*** +1, and with various ACLs: I can't trust my phone as much as =
my<br>
laptop for example. And certainly not a random computer in a random<br>
cybercafe. [1]<br>
<div class=3D"im"><br>
><br>
> 8) Client choice - you should be able to use a mobile, desktop, or<br>
> html5 app client (once webcrypto is deployed in browsers).<br>
><br>
</div>*** Honestly, I'm not sure that is a sane decision. Not until the=
re<br>
are some things fixed:<br>
<br>
=A0 - 1 TLS certification authorities (utterly broken and mostly<br>
untrustable)<br>
=A0 - 2 TLS perfect forward secrecy implementation everywhere (servers,<br>
browsers) including protection against TLS-downgrade attacks. That's<br=
mostly a matter of proper configuration though.<br>
=A0 - 3 Javascript protection: Libre JS to ensure the code run on the<br>
page is genuine and not malicious<br>
=A0 - 4 proper protection against XSS, CSRF, and other MITM<br>
<br>
3 and 4 are way out of reach at the moment. HTML5 is bringing new<br>
attack vectors, and the development of the Web is going towards more<br>
usage of centralized resources (+1, Like, Login with X, analytics,<br>
etc.) without mentioning javascript-less CSS-based or DOM-based XSS,<br>
plugin-based infection, and mobile phone network insecurity as a whole.<br>=
</blockquote><div><br></div><div>I dont believe in trying to create perfect=
security, security should be "good enough" then you start the ar=
ms race between attackers and defenders.=A0 Facebook didnt even start with =
https remember and go to 100 million users.=A0 In any other project I'd=
be a security fundamentalist, but for a social project, users count, this =
often seems to be underestimated...<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
To me (8) is the convenience door open to keeping the spyware operate<br>
as is. We should aim instead for much more ambitious things: secure<br>
hardware, end-to-end encrypted connections (see (1)).<br>
<div class=3D"im"><br>
><br>
> 9) Multiple identity - you should be able to maintain multiple<br>
> identities, and choose to link them or not.<br>
><br>
</div>*** +0 Again I see that as a convenience door open to spooks. True<br=
unlinked identities are to remain... unlinked. Maintaining multiple<br>
identities on a single device for example, is hard to protect in case<br>
it is compromised...<br></blockquote><div><br></div><div>The user should be=
in control of their identity.=A0 They should be allowed to have their iden=
tity the way they want it, so long as it doesnt impinge on any other user.<=
br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
><br>
> These are sometimes called 'nyms' (short for pseudonyms) ... y=
es<br>
> it's important to think in terms of multiple identities, most<br>
> systems restrict you to one, and even worse, one that is a subset<br>
> of their particular world view.<br>
><br>
</div>*** +1. Identities are made to recognize people.<br>
<br>
It is in the interest of bureaucracies and surveillance systems to<br>
recognize people globally. That's why they want you to bear a "fam=
ily<br>
name" and well as a "given name", to get a passport and an i=
dentity<br>
card (a recent invention that's supposed to prevent crime, but<br>
everybody knows that criminals can forge identities), or in a too soon<br>
future an implanted chip (now sold as "cool" for VIPs in hype clu=
bs,<br>
"life saving" for people with medical conditions or soldiers,<br>
"protective" for inmates, or "efficient" for cattle).<b=
r>
<br>
But in social networks, people are used to share identity with their<br>
own circles, and independently of their "Real Name (TM)". If you&=
#39;re<br>
"Mister Smith" to your employee, you're "John" for =
your neighbor,<br>
"daddy" for your children, "honey" for your wife, "=
;spud" for your<br>
former classmates, etc. Your identity only means that the people<br>
susceptible to interact with you know who they are addressing<br>
consistently, and you do as well know who is talking to you.<br>
<br>
Identity is not about 1 person, but about a bi-directional<br>
relationship. I have nothing to do with the NSA, nor any suspicious<br>
government, nor any marketing entity that want to commodify me. So to<br>
them my identity must be ephemeral.<br>
<div class=3D"im"><br>
><br>
> 10) Protocol agnostic - you should be able to cross-communicate<br>
> with different protocols, be they XMPP, HTTP, or p2p based.<br>
><br>
</div>*** It depends. If I'm willing to use the Briar Transport Protoco=
l,<br>
obviously I don't want nor need that it interoperates with anything<br>
else. Again, spooks might want that, but not me.<br>
<br>
If I want to communicate using a protocol, with someone who is using<br>
another, there should be a possibility for me to bridge that<br>
communication to that protocol, but I would not put that as a requirement.<=
br>
<div class=3D"im"><br>
> Although I would love to see this happen, it's perhaps taking on<b=
r>
> too much for the first phase.<br>
><br>
</div>*** Yes.<br>
<div class=3D"im"><br>
><br>
> 11) Secure groups - groups with membership determined<br>
> cryptographically. Groups function as a virtual user, with all<br>
> users in the group able to receive and send as the group, because<br>
> they share a private group-key.<br>
><br>
</div>*** +1. Private group communication is fundamental.<br>
<br>
It's also a hard problem: sharing a private group key was discussed at<=
br>
length last year during the hackathon in Berlin. Two main issues were<br>
raised: 1) how do you bootstrap the key? 2) what to do when people<br>
join or leave a group?<br>
<br>
So maybe the notion of group must be revised as well to match<br>
volatility of the concept. Transient groups might form and want<br>
ephemeral communication; more stable groups will arise and want<br>
perennial archives. Etc.<br>
<br>
*<br>
<br>
For me, most of the points you propose are conveyed by the<br>
GNUnet/Secushare project, which you mention in your presentation, and<br>
that is the explicit goal of the GNU/consensus project. For which I'm<b=
r>
being an opportunistic Bolchevik and wish for a (somehow short)<br>
dictatorship of the Web people until we are ready to move to a true<br>
p2p architecture. :)<br>
<br>
=3D=3D<br>
hk<br>
<br>
[0] The GNU/consensus Whistle is an upcoming monthly newsletter that<br>
should start its life soon. A draft is available on the GNU/consensus<br>
wiki at <a href=3D"http://libreplanet.org/wiki/GNU/consensus/whistle/002013=
-07" target=3D"_blank">http://libreplanet.org/wiki/GNU/consensus/whistle/00=
2013-07</a><br>
and you're welcome to edit it.<br>
<br>
[1] 3 years ago:<br>
<a href=3D"http://libreplanet.org/wiki/User:Hellekin/A_User_Perspective_Of_=
GNU_Social" target=3D"_blank">http://libreplanet.org/wiki/User:Hellekin/A_U=
ser_Perspective_Of_GNU_Social</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.12 (GNU/Linux)<br>
Comment: Using GnuPG with Icedove - <a href=3D"http://www.enigmail.net/" ta=
rget=3D"_blank">http://www.enigmail.net/</a><br>
<br>
iQIcBAEBCgAGBQJR7YfuAAoJEEgGw2P8GJg9wBEP/Rdc/Akdiei2xEJ6t2aT6Qvn<br>
WHbD72x9TdmP2Q5jj5iHJPnZO3xFCeRx73ZXeXbZKjVTOkP2pG+d5KXCVq7/wUwk<br>
joy0hptBJVW6LSdv1hggf9s4emwfT0K8SyNxl2t5l1KC5EPVLcflZYWsQ2lmw61C<br>
8JJPM2QtPVJbAQ+FiNZnK4DJebzfUPVvkQ19ImANrm/SPAtO0LqnO3UUXWbtRmLf<br>
IXS43+PQn+Yq8Gm/hLVZxaZDR4RVF86eER2fV/993+DUZJczMogNapslQ19Z8VRo<br>
mXXFhg2T9zP1A8w4ZGJJPB6ar5havCBlaS7xWp+zwTDuuwy3pt4VkLpGGG/oNRM5<br>
NGDEed3pGJXloyZ2kapk8vowcVhT8ano/f+uJCbMavhU6f407CjpDAEo+Y1wWhbl<br>
whWOI+oOOkitQfSbSwPP1I2x/JSCJMhI2lSzhC8o1/cMofbmZV8z3tEFAeizFtBa<br>
1VHXYbVzNxhzgDVQqSe8ioj7Q2bd55hvPHaTHdxwTibENjyErij/M6bZJ1wIEYEi<br>
WT+dlePfhfa2/LdVsi5i5BJ4/u+GWLhFKFE9lQevdECJkdS3wzuCBd6SRK3poPee<br>
I5TmAiJZT3XfGZaAXKPjaP/zEK0JoXtiDnI5oki1t5B6BJERT9hSIPxxc4/G1rUZ<br>
xH960Bxxi8w8gYe/KgJi<br>
=3DLPX5<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div></div>
--001a11c3504cd7061604e21f4d6a--