consensus
[Top][All Lists]
Advanced

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

Re: [GNU/consensus] [wiki] Call for Participation


From: hellekin
Subject: Re: [GNU/consensus] [wiki] Call for Participation
Date: Tue, 01 Jul 2014 14:28:09 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 07/01/2014 06:35 AM, carlo von lynX wrote:
> Hej to hell!
>
*** Dear Carlo, that is exactly the kind of conversation I want to see.
> On Mon, Jun 30, 2014 at 01:25:11PM -0300, hellekin wrote:
>> Topics we should address, in no particular order:
>>
>> - -    Blockchain-based systems
> 
> When there is a race involved, then there may be the problem
> that certain governments have more computation power than all
> of the participants combined, which can have drastic effects
> on the blockchain.
> 
> When it is a messaging medium, then it is probably less
> efficient than a multicast distribution tree, so it is only
> interesting in situations when there is a need not to have
> an "owner" of a distribution channel. Since most channels
> are about distributing some person's stuff, and even political
> channels need to have a moderator to function properly, I have
> yet to encounter a use case.
>
*** Probably the people at Ethereum and DarkWallet will have a different
stance on the Sybil attack, or the energy consumption issues which, I
believe, they have been considering.

The public ledger certainly presents a strong case for the replacement
of opaque banks operated by banksters. To reiterate: I do not believe in
one technology to rule them all, but in a diversity of technologies that
work together to each do what they do best.

If GNUnet can run the equivalent of a public ledger without the
vulnerability on the Sybil attack, or if Ethereum can do it, we're good.

>> - -    Cryptography and Usability
> 
> We should get more stuff with the new paradigm out there, then
> I think this issue will be considered dealt with. The problem
> only exists with broken-internet tech like PGP, SSL and OTR.
> It doesn't with SSH, for example.
>
*** There is always the bootstrapping issue that should be done in
person. We tend to bootstrap conversations online on the assumption that
we can recognize the other party. We all do it.

Even with SSH, how many sysadmins ask you for a strong key, with a
strong passphrase (they have no way to verify that), and send you back
an SSH config ALONG WITH THE SERVER'S FINGERPRINT? So there's room for
improvement there as well. And anyway, would your father know what to do
with that?

Then, this bootstrapping issue is not solving the human factor (or "Sabu
hijodeputtitude"), or the James Bond factor (NSA implanting hardware
bugs into your favorite keyboard), etc. I don't want to reduce the
usability issue to "broken-Internet tech" nor to out-of-band, XKCD 538
style security.

Instead, I want to compile the state of the art in crypto usability, and
put both cryptographers and UX designers together to make it usable
across society. One such initiative was Sean O'Neil's PureNoise
cryptographic proxy service. Which is now going to be GNUnet: everything
going out the computer goes through encrypted channels to their
destination, and that's automated. But this does not remove the initial
question "how do I ensure it's the right recipient, the right key,
correct encryption.", etc.

>> - -    Economy of Sociability
> 
> We need a law that impedes making money on the fact that people
> socialize. If you want to make money, you have to sell actual
> goods, like beer in a pub.
>
*** Ah! Well, I wasn't actually thinking in those terms. The idea is
more about the trade offs we go through to enjoy proper sociability
online. What are they, and what price are we ready to pay to follow
through? If we can identify them, we're likely to make better design
decisions to automate conversation flows that will actually interest
people who, for now, think their ability to belong to a group is worth
the risk of seeing one's drunken picture end up in a meme factory.

>> - -    Funding Free Social Software
>> - -    The GNU Name System
>> - -    How To Choose Where To Contribute?
>> - -    Indie Web / Linked Data
> 
> The indie web should have .onion addresses.
>
*** Bazza is proposing a wrapper, ciboulette, that allows people to
setup hidden services to interact with other. Pretty crude and
experimental, but it starts from that assumption.

But the identity in the Indie Web is an URL. It's unlikely that people
want to swap a readable thing with an unreadable one. On the other hand,
if the domain is a zkey, then it also matches whatever funky alias you
want to make for your friends.

So yes, a .onion could be used, and if that becomes a standard, etc.
This brings a new issue: if you're running a Tor hidden service at home,
will you relay as well? If you do, will your relay slow down the whole
network? All considerations need to belong to a larger scope, because
end-users will not be able to make the technical decisions to optimize
the network setup. Bittorrent does pretty well on that account, right?

> Other than that this isn't really a problem that needs
> fixing. The web is broken, we can improve the browsers
> and Tor, but the servers are not the problem. And the
> fundamental idea behind the indie web that says that you
> are free if you are exposing your privacy yourself rather
> letting others do it for you, is fallacious.
>
**** Yes, I agree with that. Besides, it's a solution if everybody can
actually be a PEER on the Web, and not one of thousands of customers of
a virtual appliance on a giant commercial "cloud" service. That would
basically replace the centrality of Facebook with the cloudiness of
CIAmazon. Not so good. But, on the other hand, if people can use their
devices to run their own service as a peer, then the centralized
emotional control of Facebook [0] is already a step away. That is
already better than what we have now.

So, again, it's a matter of trade-offs, and looking at things honestly
and thoroughly. When Secushare can do what the Indie Web can do, how to
make the switch? Etc.

>> - -    Secushare API
>> - -    Sexifying Free Software (Accessibility, Graphic Design,
>> Usability, UX)
>> - -    UnHosted Apps
> 
> I didn't comment the ones I fully agree upon.  ;)
>
*** I appreciate your perspective, and you attention. Conversation is
critical because there are trends, running like furious torrents down
the mountains, growing into rivers, and stabilizing in the ocean. The
Internet itself is this ocean, and dances with the land--our physical
world, that sustains the digital ocean, and increasingly gets shaped by
it. As I see it, GNUnet is a key infrastructure of this digital ocean.

==
hk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQJ8BAEBCgBmBQJTsu+nXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3MDM3QTJCNjlFNkMxQzA1NjI4RDUzOEZE
OEU3QkQ4MDk0MUM4MjkzAAoJENjnvYCUHIKT//MP/2htJYYFRrG5iMkl1XBXUEz1
GCLF8Xfpvho+pbpzgxHkP4uAPSHzDpOKw+HYm/OoOpoB694E1Tyc6KBcpna03bx4
z66duQX5Sxa29/TToDRlxKlfR7s3eTDQPWO+C7AC9NSKb5/KoT4zCxGbFDgHVzSa
LwUXl8H3GBogk+5NyGuJfKrScYS1ZTz+2I/QMf06t7pJliyF8gFZd9X51/l8juGo
m81O1dtx7HX0WXBbDTGG/iIgZEVBhRtTpMWRDgmJsNwjDp66Hlo0adL7qB/un04N
uXU9Nff0I09a7oZiW9ALYOtXtF5YUrrqNUyak9KC3FinBUXenzUXttL8f7X4oz+T
cC99xLTIfSfl8DlbAdV0h6dlkkt1yoZUHsVblSZvXugn3FIcZ1C5rmN42fzRVu74
edHvpuKiON6N/Pw4ZEayTGWO5GgUcJGLTeFSjne2K0PJ+x9Iy8VjffBXf97dU3vV
1fFNT1atPXCJiTd2s5+pxT4ztuSwVYgl40hSFAXyV91lG+fLVDoHS1+C6c/N1ZSZ
7NbJqF0jMfw4qaQL0OVjBGRZwqSmcxeTv9iKXrv8zheVPVLD0/YbMNF3Shezna59
lHhXv9YufkvHVodN2G2RKFKV4g9T0f/1+JAt8X5mIoOvjX6z2NPvOPbJWHzQAm66
A8xMy1mh16mZocKSoXkI
=wiW2
-----END PGP SIGNATURE-----



reply via email to

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