What's wrong with raising money? Is it more ethical to build systems while living of one's savings?

One of the reasons why there's is a lot of Ethereum-based projects currently raising a lot of money is because token-based systems avoid relying on the traditional financial system for payments and value transfers. If your app is using traditional payments it can be shut down by your payment provider.

Blockchain-based tokens allow users to be in control of their own funds and not have their payments tracked or tied to their identity. I'd say that's a pretty big win.

Moreover ERC20-based tokens allows for engineering of incentives in a way that is far more efficient than company shares. It can accelerate network effects in a way that was simply not possible before blockchain technology.

Raising money to fund work is not the issue in my view. But raising money from venture capital firms has implications that I find hard to reconcile with the stated goals of this particular project.

Venture capital funds many projects in the hope that a tiny share of them will pay for all the others and a profit on top of it. So for this project to meet the expectations of its owners it would have to be extremely lucrative way beyond funding the work put into it.

Is that really the right structure to fund a foundational protocol with non-commercial goals that are potentially in conflict with very powerful interests?

Even worse: VC still expect even the "failed" projects to maximize their return. They don't fund things pro bono, and they will force every project to make decisions that put investor returns before sanity and basic human decency.

Yes. But I think what we don't know is what the agreements really look like in this case. I don't know what a SAFT (Simple Agreement for Future Tokens) is. So maybe this investment is structured differently than regular venture capital deals.

That's fair, and as this is one of the first SAFTs (link below) sold to SV VCs, there's quite a bit of new ground in the thinking and incentives.

Basically, the deal is that our investors bought the right to future Orchid Tokens, which is a new token used for payments within the Orchid Network. Since it's a utility token it's value should be driven by the utility of the network - the size, health and of course user count of the network.

Since there is a huge market for VPNs which overlaps with the utility of Orchid in terms of enabling access where there is censorship, if Orchid can grab a small part of this market then the utility of the network would drive the price of the token.

Whether this is the right model remains to be seen, and like any project there could be a conflict of interest if investors push for features that are not aligned with the project vision.

The difference is that, unlike traditional startups that are in control of their IP and the deployment of their software, once the Orchid Network is deployed, no one controls it but the users who run nodes. They choose what software to run for their source, relay and exit nodes, and no one can force them to upgrade to some new version. This is similar to other decentralized networks such as Bitcoin and Ethereum.

In practice the developers and teams behind decentralized networks do hold some power of software upgrades from their reputation and control of github repos, etc. But if push comes to show and for example we try to add payment fees or adds or other types of monetization, then users are very likely to simply reject such upgrades or even outright fork client software (thus effectively forking the network once such clients are deployed).

It is my hope that this is a structure that allows for both raising money from VCs and still end up with a truly decentralized network. We'd love to get feedback on this and understand what we can do to ensure that the network remains controlled by it's users and not (too much) influenced by any specific group.

https://www.coindesk.com/saft-arrives-simple-investor-agreem...

There's nothing wrong with raising money. One reason open source projects without large corporate sponsors haven't succeeded in attaining mass consumer adoption is that they haven't had effective compensation and incentivization mechanisms. With cryptocurrency/ERC20-based-tokens, now they do.

The best thing about the project is that the tokens will be valued by use from the beginning and not with an ICO.

Could you name the other projects that you think are better? Given the interest in this article I’m sure others would be interested as well.

The money raised is a total turnoff. How can this be an independent effort with all that big-name backing?

Since you brought up TOR and money, I would say one advantage this project has is that since payments are sent with packets, that will provide an stronger incentive for transmitters other than just for goodness of humanity.

This should be on the top. They did not even put a lot effort in their current presentation but already are millions "in dept".

As novel as the idea sounds, i doubt this is it this time but lets hope for the best.

Exactly. I ditched one of these save-the-world projects recently because they did little but talk about fundraising and how to distribute their buttload of tokens to each other.

I agree with your point . But there is a company out there called Althea-mesh,http://altheamesh.com. They have not raised a dime, however they have proof of concept products. Their next move is building commercial products.

Projects like bitcoinereum will try to make ICOs more reasonable. You don't preprogram how much the founders get. It's less susceptible to abuse. It's the bitcoin blockchain implemented on ethereum and lets anyone mine by competing with transactions.

Check out cjdns for a less stupid, less blockchain BS take on fixing the internet.

https://github.com/cjdelisle/cjdns

One question I still haven't found answer to: what's with the name? What does it mean / why is it the way it is?

Should it be read as CJ DNS, i.e. something to do with DNS? Or CJD (author's initials) NS (??? again, name server?)? C (?) J (JavaScript/Node) DNS?

Related, what the hell it is, actually? You say in other comment that it's a mesh network, they say it's a network, but I see a program to install. How a program is a network? What does it do?

Tor is a network, and yet you have to install a program to connect to it. You can think of the cjdns program like a driver that allows you to connect to a cjdns network.

To answer your question on what it does : cjdns is a routing protocol that intends to replace the current IP protocol. Like the standard IP protocol, it needs a way to communicate with another node to function (the default gateway). From there, you can communicate with the rest of the network. Your packets will go to the default gateway, who will then redirect it to the "closest node" recursively, until it reaches its destination.

You can setup cjdns over the current internet (essentially making cjdns an "overlay network" like tor) using UDP, or through an ethernet link.[1]

CJDNS indeed works in a mesh : anyone can route other people's traffic, somewhat similarely to tor. The only difference is that you need to manually configure your "Entry Node" (to lift tor terms). See [0] for the reasoning.

About the name, the creator is Caleb James DeLisle, so I guess CJDNS stands for Caleb James DeLisle's NameServer ? Doesn't really make much sense but I don't see how bad a thing it is.

[0]: https://github.com/cjdelisle/cjdns#2-find-a-friend [1]: https://github.com/cjdelisle/cjdns/blob/master/doc/configure...

Caleb James Delisle's Networking Suite

"One question I still haven't found the answer to: what's with the name?"

"Where did the name cjdns come from?

Cjdns was based on a codebase which was originally intended to handle name resolution (DNS) and so it was a combination of 'cjd' and 'dns'. The project changed direction early on and currently is still lacking DNS resolution but the name stuck. Make up your own acronym for it if you like."

Source: https://github.com/SlashRoot/cjdns

What is it? The author has said it is meant to be a single binary: a router. The router accepts "customized" IPv6 addresses, e.g., each address contains a public key fingerprint. The packets are also custom, each containing a full route to the destination, which might be reminiscent of the bang path in UUCP. The nodejs stuff is just a prototype method of getting data from the router.

I remember watching a video of him explaining this at a cafe a number of years ago. Not sure if that was the first "public announcement". In that video he mentions a concern over censorship via DNS. And then he states that at a certain point he realized routing was easier to do than DNS.

http://www.youtube.com/watch?v=zINQYkl01N8

He uses NaCl. As for the name "cjdns" and why he started out experimenting with DNS, my guess was always that the original experimentation he did with NaCl was probably related to encrypting and forwarding DNS packets (or perhaps custom "name system" packets), since encrypting DNS packets was the "PoC" for NaCl.

Lead author is CJD. cjdns == cjd network suite

Is cjdns more of same address-centric hosting? If y, would not NDN content-addressing be the more smarter internet fix?

http://youtu.be/opKJsVTcofg#t=164 Ask the network for what you want. Not say 'who' you wanna talk to, but say 'what' you want.

Smarter for what exactly? content-addressing is great if what you are looking for is pieces of content, it's not if you want to talk to services.

Here's the tl;dr: a practical encrypted mesh network that can work over the traditional internet protocol (IP) or over real-world links and radio antennas.

Since the parent was deleted and I couldn't comment by the time I finished typing, here's the non-tl;dr:

The main advantage is non-hierarchical routing. Your ip address is in fact the fingerprint of your public key, which is used to encrypt all traffic.

Because of this the address allocation works a lot different and there's no need for a central authority. The lack of a central authority is usually a problem if you ever tried to merge two large internal networks you might have run into the issue that both networks have used 10.0.0.1 for something. This isn't possible in cjdns because you can just generate as many key pairs as you want, which would map to one out of 2^120 possible addresses which are very unlikely to collide. Merging two networks is just a matter of configuring one or more peers and the networks are able to see each other (this is so easy, it might happen by accident).

The main difference to other projects is that you don't need to write code to support it. If your application supports unicast ipv6, your application is able to run on top of cjdns.

That sounds like a good way to get very inefficient routing.

Supposed I have keypair A at a friend and keypair B for me, how is cjdns going to find the fastest route between me and my friend?

Tbh, this doesn't look like something that could scale to Tbps Bandwidths... It seems a lot of processing is required to properly route the packet to the next hop and that happens independently of whether the next hop is even remotely an ideal one.

Atleast, as far as I can tell from this page.

There are some issues with cjdns with pure DHT on small footprint devices with poor connectivity. The author is hence currently introducing experimental supernodes, which are stable fat nodes with large memory which can build routes quickly.

Two questions about mesh networks:

1. at some point there will be an expensive hop across the ocean, or between cities, that will likely only be built once, then shared. Won't whoever owns that hop have similar centralized control of any non-local traffic, similar to an isp?

2. how meshy should mesh networks be? On one extreme, every computer can be directly connected to every other computer in the world. On the other, every computer can be connected to just one neighbor, and requests are routed through many hops. What is the prevailing wisdom on the optimal amount of peers nodes should have on average in a mesh network?

While the project is interesting, what is up with running it off nodejs!?

What? It's written in C.

The build system is written in nodejs -- it turned out way faster than both CMake and classic Makefiles.