[lispython]

Both of them remind me Plan 9's "single most important feature"[1]:

> all mounted file servers export the same file-system-like interface, regardless of the implementation behind them. Some might correspond to local file systems, some to remote file systems accessed over a network, some to instances of system servers running in user space (like the window system or an alternate network stack), and some to kernel interfaces. To users and client programs, all these cases look alike.

And Rob Pike once said[2]:

> When I was on Plan 9, everything was connected and uniform. Now everything isn't connected, just connected to the cloud, which isn't the same thing. And uniform? Far from it, except in mediocrity. This is 2012 and we're still stitching together little microcomputers with HTTPS and ssh and calling it revolutionary. I sorely miss the unified system view of the world we had at Bell Labs, and the way things are going that seems unlikely to come back any time soon.

[1] http://www.catb.org/esr/writings/taoup/html/plan9.html

[2] https://usesthis.com/interviews/rob.pike/

[codemac]

Saying things were uniform when your entire interface is "bytes to and from a file descriptor" is just editing the past to me.

For most of these p9fs interactions, each one had a different format / API that you had to know in advance before reading or writing to the file. This meant many things just had custom ascii, others were binary. Some pushed elements into different file locations, some piled them all into a blob under the same file.

It makes oauth2 look decent.

Saying that you managed to push everything through a file interface is interesting, but it's no more or less connected than a world of http://

[f2f]

you're being deliberately obtuse. the uniformity in plan9 didn't mean everything spoke the same protocol, but that every resource could be shared everywhere. you wouldn't want your tv tuner card to talk ascii, but with 9p and a plan9 kernel you could access any tv tuner on the office network as if it was connected to your own machine. indeed on any other network that gave you could login to. that is the part that's sorely missed.

[lomnakkus]

> you're being deliberately obtuse.

To me it sounds like codemac is being entirely sensible and pragmatic about what the limitations are. Pervasive "piping of bytes" is all well and good, but if you don't understand what the bytes mean, it doesn't really matter.

> you wouldn't want your tv tuner card to talk ascii, but with 9p and a plan9 kernel you could access any tv tuner on the office network as if it was connected to your own machine

Office network? Sure. Not try it over a WAN and suddenly it doesn't look so hot.

The thing is that once you're going over the network you really need to start thinking about the effects of latency and how to compensate for it or hide it. Network transparency is a foe in this (very common) scenario.

[codemac]

If I can get the damned TV onto the network at all, then I can use 9fs or any other protocol including http.

plan9 did not invent the network, or even the concept of shared resources. They focused on putting all resources into a filesystem API, entirely and exclusively. That's their innovation. I'm not being obtuse by pointing it out.

[f2f]

i'm not entirely sure about your timeline. plan9 came about in 1990. plenty of "sharing" back then was the unique property of distributed systems like amoeba.

[aidenn0]

On P9 at Bell labs, everything could be connected and uniform. In the real world with corporate firewalls, HTTPS is very nearly the only reliable option for connecting to other computers.

On top of that, the fact that most workstations in this world do not have public IP addresses, and p2p becomes really a non-starter.

[chatmasta]

This seemingly destructive segmentation of the Internet is precisely what will lead to its successor: a collection of "overlay networks" built on top of the existing IP stack. We're already seeing it in many ways, with Tor and VPNs as two commonly used examples. But overlay networks are not just advantageous for packet transport. They can represent any decentralized network. BitCoin is an overlay network, in that it's literally a payment network, is a payment network, built on top of existing IP infrastructure.

We are going to see more and more of these "overlays" as the Internet "re-decentralizes". Sure, what we know as "the Internet" is becoming increasingly centralized, and people are right to be concerned. But there is nothing to fear, so long as we can build more abstractions on top of the Internet as we know it. Let Amazon, Google, and the big "clouds" centralize as much of the Internet as they want. They are only digging their own grave, because the next revolution, the "Internet 2.0" will be as decentralized as its predecessor. Only instead of being built on the "dumb pipes" of copper and fiber, it will be built on the "dumb pipes" of the existing, increasingly centralized, Internet.

The more the Internet infrastructure consolidates itself, the more it provides an opportunity to re-decentralize on top of it.

[0xdeadbeefbabe]

What you say made me think of hamachi, a nice vpn overlay network for windows (at first) from the late 90s, and guess what happened to it?

> For paid subscribers Hamachi runs in the background on idle computers. The feature was previously available to all users, but became restricted to paid subscribers only [0]

More short sighted business practices as usual.

[0] https://en.wikipedia.org/wiki/LogMeIn_Hamachi

[chatmasta]

You should check out the ipop project [0], the technology behind socialvpn and groupvpn. They have an active and extensive github. [1]

The problem with technology like Hamachi, and even IPOP, is that the nature of NAT traversal means that for any given p2p network, "supernodes" will always be required. IPOP uses STUN/TURN (the same technology as WebRTC) for NAT-traversal. According to Google usage stats (can't find the URL right now), about 10% of p2p connetions over STUN/TURN require relaying all packets over the TURN server. So that means for every ten nodes, at least one will need a supernode to connect to the others.

At first glance, the requirement of "supernodes" seems to impede the proliferation of true p2p networks, because it introduces a point of failure into the system controlled by one entity but relied upon by many. The problem is that "supernodes" cost money, and somebody needs to pay for them. So you end up with companies like LogMeIn, happy to provide a "p2p" solution, as long as you pay them to maintain the requisite supernodes.

However, there is no requirement that one centralized entity supply the "supernodes" in a network. It's 2016, we have "the cloud," and anyone can launch a "supernode," aka a cloud server with a public IP that can assist in NAT traversal.

I hope we will see more business models based around a combination of "p2p" and "federated" network architectures, where they are federated in the sense that a group of "super-peers" provides the "supernodes" required for functional NAT traversal on the rest of the strictly p2p network.

[0] http://ipop-project.org/

[1] https://github.com/ipop-project

(Shameless plug: You should also check out my senior thesis, TorCoin: http://dedis.cs.yale.edu/dissent/papers/hotpets14-torpath-ab... -- I've been thinking about this a lot since then, but that was my first real exploration of the ideas I'm trying to express here.)

[0xdeadbeefbabe]

Interesting abstract, but what about just asking for donations?

Freenode does that, and so does public radio, but they seem uniquely positioned to do that. If I were running a bunch of STUN/TURN servers I wonder where I would ask for donations.

Makes me wonder how the Internet came to be. Something about DARPA funding?

[chatmasta]

The cost of a supernode is more than just monetary. There is a cost to the network when one single entity controls all the supernodes, because in almost all cases that means they have some disproportionate level of power over routing or quality of service. You wouldn't want one company running every Tor exit node, because then it's not decentralized.

A business model that relies on donations to one, or a few, entities controlling the supernodes perpetuates the centralization of infrastructure. Not to mention that donations are historically the most cost inefficient solution, especially compared to "market forces." If the efficiency of a decentralized system depends on the number and quality of supernodes, then some economic mechanism must exist to incentivize peers to become "super peers." The competition will ensure that the super peers who survive are the ones with the highest quality nodes at the lowest cost.

Then the question becomes, who pays the cost that gets distributed to the supernodes? In the case of TorCoin, we wanted to avoid the situation where people need to pay to join the Tor network. So our solution was a cryptocurrency with "proof of bandwidth" as its "proof of work." Just like a single Bitcoin represents some amount of CPU power that was expended to "mine" the BitCoin, a single TorCoin would represent some amount of bandwidth that was transferred to "mine" the TorCoin.

The idea was that a TorCoin would have value outside of Tor, and Tor was simply the mechanism used to mine it. So relay operators would mine TorCoins, then sell them on an exchange just like they would any other altcoin. This way they get value from providing bandwidth to Tor users, but the users do not need to pay for the service.

However this gets complicated very fast, because you're not talking about one person mining coins with one CPU, but pairs of people mining coins by transferring bandwidth between each other. So the priority of the paper was addressing the threat of collusion, where two malicious nodes (possibly controlled by the same actor) spoof terabytes of bandwidth between each other, flooding the market with TorCoins. Our key insight was "TorPath," a circuit selection mechanism that ensures every circuit participating in the TorCoin mining scheme is "privately-addressable but publicly verifiable." So each TorCoin (or part of a TorCoin) would represent a circuit that actually existed, and anyone could verify that via a public ledger, without revealing the identity of the circuit participants.

I think the idea of non-CPU "proof of work" schemes is very interesting in general, and bandwidth is one of the most profitable venues to apply it to. For example, imagine if the BGP system were operated along an incentive scheme like this, where instead of "circuits" we are talking about "peering." The path selection mechanism we devised would work in any routing system with multiple participants, not just Tor.

[frostymarvelous]

I'm really interested in hearing more about this. I mean "Internet 2.0".

Anh pointers on where I can find material that speak about the ideas you've expressed? Obviously I'll hit Google but you might just have something better.

[chatmasta]

No idea, this is all based on my own observations.

Read my replies to your sibling comments for more details.

[zymhan]

First of all, you can just tunnel whatever storage protocol over HTTPS if needed. The point of the quote is that we could be using Operating Systems that abstract away the various kinds of storage available so that you can use whatever combination of options work for you.

It's like if everyone was using Linux and paid for plans from for example a cloud storage provider, but was able to reliably and automatically mount their storage like any other network share.

With open technology and widespread fast internet, it's really not that hard to accomplish. We've already got the former. Now we just need a lot more of the latter.

[pjc50]

everything was connected and uniform

I've never been entirely clear whether this referred to 'everything within the Plan9 organisation' or 'everything visible from a Plan9 machine including external independent systems'. The former is much easier to achieve. So much of the nonuniformity is because of competing administrative domains.

[knorker]

"Everything that was on my machine was uniform because I wrote it from scratch to work the way my brain works"

Yeah… that doesn't scale, no matter who you are, mr "I refuse employment unless my employer gives me 'r' as login name".

[koluft]

You seem so angry for such a bizarre reason.

[Joeri]

Maybe he used to have 'r' as login.

[knorker]

Irrationality and denying reality annoys me.

[coldtea]

>mr "I refuse employment unless my employer gives me 'r' as login name".

And what's that to you?

[knorker]

Another sign that he lives in his own arrogant world. A separate arrogant world that affects other people.

[chronial]

What is new about this, is that it is none of the three things that your quote listed as possibilities. The new thing is a remote storage that has a smartly synchronized local "cache".

[rakoo]

Nothing could prevent a remote filesystem to have a local cache, actually this is what every remote filesystem would implement quite soon.

The real novelty of Infinit is that you can mix and match multiple storages and build a unified filesystem with encryption on top of this. Roughly something like truecrypt over aufs over (sftp+local fs+s3fs+whateveryouwantfs)

[Aleman360]

Seems like a leaky abstraction. Did their interfaces have a way to account for differences in latency and failure modes, or was that hidden?

[maaku]

Downvoted because when I click "comments" I want to see comments about the article, not some unrelated system.