> If this is decentralized, what is its solution to Zooko's Trilemma?

I was going to say: Gnunet pet names aren't globally unique, therefore Gnunet gives up on having the human-meaningful addresses be globally unique. However, from your link it appears that there is no requirement in Zooko's Triangle for those human-meaningful addresses to be globally unique. So it doesn't actually give up anything:

1. Pet names are human meaningful (though not globally unique). Check.

2. Public keys are secure (and in the typical cases globally unique, btw). Check.

3. Gnunet zones are decentralized. Check.

There you go. Triangle drawn.

AFAICT Gnunet punts the names down to the user in a similar way to how Convergence punted CA choice down to the user. In both cases the user chooses which entity or entities to trust, being more or less strict in what to do if those entities disagree based on some predetermined criteria.

In reality, however, I remember that Google balked at adopting Convergence because it seemed likely that most would have eventually just standardized on delegating their own choice of "decentralized" CA to Google. Then you'd end up with an ostensible decentralized set of authorities where that set is simply { Google } for the vast majority of users.

I don't see any mechanism in Gnunet that would avoid a similar fate. Especially given that the examples given in the current docs are so goddamned confusing and convoluted that a tempting workaround would be "Step 1. Just set Google as your thingy." I offer into evidence exhibit one: Gmail.

> it appears that there is no requirement in Zooko's Triangle for those human-meaningful addresses to be globally unique

If they aren't globally unique they aren't really names anymore.

If I send you a link involving news.ycombinator.com, and you think that news.ycombinator.com is really furrypr0n.com, I would say that we are not using the same naming system.

That isn't distributed; it's merely incoherent.

It's a naming system, which is human-meaningful and decentralized, but not globally-unique. It fulfils 2 out of 3 criteria, just as Zooko predicted.

It's an overlay of two systems: one of which is HM+DC and the other is GU+DC. Triangle not drawn - you have two systems.

Exhibit two: Google Public DNS.

Google public dns is different than Gmail. It isn't the source of the data, for one thing. It's just a cache. The cost of switching to someone else's cache is approximately zero. And it's not very difficult to set up your own nameserver that actually queries the root nameservers.

The resolution mechanism is decentralized. Zones are published and resolved through a peer-to-peer mechanism with the goal of preventing censorship and allow for query/response privacy.

Is the namespace decentralized? That depends on how you use it. If you use GNS with an ICANN provided root zone configuration (this is an example, there is no such thing atm), then your names will have the same meaning as for other people using this configuratin. If you build your root zone from scratch, you will have modified the namespace in such a way that names are no longer unique. If you go full petname system (ie. names are basically treated as your personal address book), the names are no longer unique.

Think about DNS: If you are sufficiently technically literate, you can run your own root servers and use them. Is DNS at odds with Zookos triange? I would argue: Yes, depending on how you use it. It is just very common to use it with unique global names.

I have experimented with GNS. While DNS is designed to be a tree/hierarchy of zones, GNS appears to be a web of zones with no real notion of a root zone. ICANN-provided zones will at best be just a bootstrap zone - not a root zone. Globally unique names don't seem to be a goal at all.

The issue is going to be how to communicate a domain name that resolves identically between sender and receiver. Some sort of relative domain naming will have to be implemented. Perhaps sub domains may have to be resolved against the zone used to access the original information. Or, the address may also specifies the zone pkey against which names have to be resolved. If this could be resolved, the Zooko's triangle may finally be completed, without the need for globally unique names.

This system pushes the "not human friendly" parts into the initial setup of a trusted root zone. This also establishes chain of trust security. The fact this can be used to create nationally and corporately controlled root namespaces that ship with machines seems like a survival trait even if I don't personally like it.

After that initial non-human friendly+secure part, the ideal result is that it is secure+human friendly. The reality is that this is just as vulnerable to eventual implicit centralization like DNS has been. That just means things need to be hijacked by regulatory capture instead of hacking.

A (very dull) silver lining is that regulators are at least nominally accountable where hackers don't answer to anybody.

The “human-meaningful” point seems like a pretty moot point to the end-user in a browser. See also: the current trust the general browser user places in a lock symbol somewhere on screen.

This is the compromise chosen by i2p (*.b32.i2p) and tor (*.onion). Basically your public key, or some hash of it, is your domain name.

I agree that it's probably the least-bad compromise available at the moment.

> GNS is based on the principle of a petname system

That might be part of the answer

So called "pet names" like /etc/hosts span only two of the three corners of the triangle:

http://www.skyhunter.com/marcs/petnames/zooko-triangle.gif

GNS does not "square" Zooko's Triangle. It relies on petnames as said above, so names are purely local, like /etc/hosts. The global identifier used by each Zone is an opaque identifier, like IPFS hashes, that is not human memorable.

It sounds to me like an elaborate scheme for managing your personal collection of *.onion url bookmarks.

It's a very similar UX, but doesn't have anything to do with onion routing.