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.
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://
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.
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.
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.
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.
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.
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.
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]
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.
(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.)
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?
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.
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.
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.
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.
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".
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)
Maidsafe isn't on there, probably because it hasn't really launched yet, but Storj, IPFS, Wuala and others are. Should give you a good feel for what Infinit is doing.
Ceph is listed as "block" model when it's actually a distributed object store. Part of this is confusion because there has been both a block store and a filesystem built on top of Ceph (the latter named CephFS). But at its lowest level it's clearly an object store, not a block store.
I have to admit the situation is a little funny, but Dropbox will probably have an easier time justifying their use of the word "Infinite" that Infinit justifying "Dropboxe".
Both infinite and dropbox are standard dictionary words.
Dropboxes are also not limited to the physical world, as many online educational software platforms (that pre-date Dropbox the company) call their shared storage areas for assignment submissions a "dropbox".
I think the parent comment meant that Infinite is a word, and also a sensible name for Dropbox to name their product. Dropboxe is a silly neologism that only makes sense in the context of Dropbox's recent press, and not a good name for a product outside of this context.
>I think the parent comment meant that Infinite is a word, and also a sensible name for Dropbox to name their product. Dropboxe is a silly neologism that only makes sense in the context of Dropbox's recent press, and not a good name for a product outside of this context.
* Infinit is not releasing a product, this is a satirical post which "rebrands" their base service under a faux name.
* Dropbox is releasing a service which directly competes with Infinit called Infinite
If you think Dropbox can directly compete with Infinit using Infinite, then you should join me for my new Googl search engine!!
>Such are the risks of naming your company after a common word that describes the product.
What? Not at all! Infinit has a trademark and will almost assuredly destroy Dropbox in court, including getting an injunction against even using the Dropbox Infinite name during the case.
The real risk is on Dropbox: Not doing their homework and attempting to name a product something that happens to be legally too close to a trademark from a competitor.
What you're saying is that it would be acceptable for me to make a Googol search engine, since googol is a real word and it's Google's fault for picking a name so similar to a real word.
EDIT: Also consider that Infinit is as close to the word Infinite as iPhone is to the word "phone". Do you think Apple assumed the same risks you bring up by naming their product 1 letter away from a common word?
Just because a word is a common dictionary word doesn't mean it can't be trademarked with limited use. For example, you can't launch a new computer and name it Apples. However you can launch a new type of lipstick called Apples (assuming it's not trademarked in that context already).
If the original trademark owner can show that there's the potential for confusion among consumers, that the products are competitive, Infinit may very well prevail. Dropbox's lawyers didn't do a great job at due diligence here.
I think we all know the article is a joke. :) But people seem to be missing that tux3's comment was also tongue-in-cheek (at least, that is my interpretation).
Also, for ages Macs have had a "Public/Drop Box" folder as a write-only way for other people to give you things (and it actually makes a lot more sense in that interpretation). It did make it a little confusing when starting to use Dropbox itself, as then you have "~/Dropbox" and "~/Public/Drop Box".
Only if they refer to something non-generic in their domain of application. Microsoft nearly lost the "Windows" trademark with the Lindows lawsuit, because a window was a generic term for the kind of UI that Windows does (when they realised that they might lose the trademark, they decided to settle out of court with Lindows instead). You can't sell produce under the name Apple, but you can sell computers under that name. "Dropbox" is a more generic term than "Infinite", so I can see how it could run into trouble if someone came up with a similar file sharing service and also called it a drop box.
Yeah but the dictionary words are "dropbox" and "infinite", not "dropboxe" and "infinit". If Dropbox was called Dropboxe and Infinit had started a project called "Dropbox" that would have made sense, but like this they are just asking for a lawsuit (but only if this was a real project, of course)...
Nope. Perhaps: if it requires justification, it requires revision.
I personally dislike 'Project Infinite' because the only thing I think of in context of dropbox and infinity is infinite storage, which this is not. It's misleading.
How else would you do it, though? If anyone could call their product whatever they wanted how would you know that your Apple iPad was actually an Apple iPad until you tried to use it? Look at the thriving counterfeit markets in China.
So, first of all, you are talking about straight-up fraud. I don't think anybody will actually mistake Dropboxe for Dropbox.
But yes, I think that in an information age society, we can surely make sense of the myriad of product names and their varying level of veracity without needing to wonder beforehand whether a particular name will warrant the hammer of government intervention.
>I don't think anybody will actually mistake Dropboxe for Dropbox.
Nearly all phishing attempts rely on users mistaking m with rn or not noticing an extra/similar/missing letter. eg Citibank vs Citlbank or Wellsfargo vs Wellsfarrgo. People make that mistake all the damn time - so I'm not sure how you can say with any certainty nobody will mistake Dropboxe with Dropbox.
We're open sourcing parts of our code as soon as we consider it modular and well documented enough. We started with our build system but the plan is to open source everything over the coming weeks!
Hi,
that is great. I've never heard of you before, so I am still trying to wrap my head around it, could you please help me understand it, I have some questions.
If I have two servers, each with ZFS filesystem, could I use infinit.sh to connect them, create shared "disk" and expose it to clients on Mac/Win/Mobile so they can access the files? Will the ZFS advantages be maintained? E.g. if I set the Z2 raid on one server and mirror on another? Could I do snapshots on the server and later browse them? Will the ZFS data integrity prevent data corruption?
Thanks.
We don't build the FS for ARM just yet but since we use a lot of the same code we did for our file transfer application that runs on Android and iOS, it shouldn't be too difficult to do.
> Sorry Dropbox, we couldn't resist. It's quite an honor that you decided to use our name for something we've been building with our peer to peer file system over the last few years.
How is it fair use to use your competition's trademarks in branding your own projects? If that's the case, I've got a Googl search engine I'd like to sell you.
It's not actually a product guys, it's just a spoof on Dropbox's blog post. They pretty much copypasta'd the whole thing and just replaced "infinite" with "dropboxe".
I got the part about spoofing the post. I didn't realize that they weren't actually releasing a product. I thought they were seriously pissed and putting it in Dropbox's face by stealing their language.
It's pretty unreasonable of them to assume Dropbox even heard of their company or what they were building, when using an extremely common dictionary word.
In the world of product branding and trademarks, companies pay people to make sure they're not stepping on toes and opening themselves up to be sued. To have a product that does the same thing and is called almost the same thing is pretty sketchy. The smartest thing for Dropbox to do is just rename it, especially since it hasn't launched.
Except for that in the post the author acknowledges its basically a parody. It seems like a bit of salt from DB naming their new product in the same sort of space a very similar name, which is kind of a dickish move.
This is seriously a big deal for the storage industry! Basically what you have created is something in high demand, yet lacking in the storage industry because of its complexity.
What I've read so far is that this is a storage solution that seamlessy integrates several storage technologies, including your own. This storage layer will have cross platform clients, using Fuse and Dokany with user sessions per client managed by your Infinit Storage Service. The end-users do not have to learn a new technology/user-interface and just get an external hard drive. Very similar to how Bitcasa works, with the exception that you give the power of the actual storage architecture to the system administrators. This mean we can freely choose our own storage cluster, for example Ceph or Infinit's own.
And as you plan to release this has open source, you allow a lot of new businesses to grow which together will manage to challenge Dropbox, Amazon, Azure and so on.
For the last few months I have been working on building a Dokany client that used Ceph Rados-GateWay with Erasure Coding. Where I live we have really fast fiber internet with extremely low latency. Dokany is really performant and can easily manage to read/write 30-80MS/s between two clients living in Norway and Denmark(same ISP). It's a lot of work though, and there are several corner cases that causes issues. However if I scrap mine and start using your technology, I can take advantage of your great work and I can contribute back mine to make it even better. My final point being, with this it should possible to offer high performance "remote drives" to end-users. In some cases maybe even faster than an external hard drive. A partnership with a local ISP could offer them a great incentive to use this technology to sell even faster internet access to their existing customers. The best part, this traffic is inside their own network which means less money has to be paid for internet bandwidth. I know my ISP is desperate for something like this, and I guess a lot of other ISP's around the world is highly interested in offering something similar too.
This is what they're (Infinit) are already doing, isn't it? I can see why they might be a little annoyed at the name Infinite, but it's not like infinite is an unreasonable name for Dropbox to pick for their project...
With trademark, the test for a new name depends on whether the name can cause confusion with an existing trademark. When it's the same industry then it's pretty cut-and-dried in favor of the existing mark owner.
Reasonability of the name has nothing to do with whether or not Dropbox can use "Project Infinite". That's the point that Dropboxe makes. Dropbox can either fight that name (which really, they must or lose their own mark meaning anyone can use "Dropbox") and lose their Project Infinite name as well.
I think they're being a little silly. If you use a relatively mainstream word from the language in which you do business (and which happens to be virtually identical in all languages anywhere near where you do do business), you don't (shouldn't) have a leg to stand on, IMO. You can't reasonably arrive at Dropboxe independently. But is everyone at Dropbox really supposed to tip-toe around being careful not to name a project after a common word if it's pronounced the same as a company that was accepted to a tech incubator just 2 years ago?
It's indeed similar to Tahoe-LAFS. The largest differences are that you can build hybrid infrastructures with Infinit (local storage and cloud storage) and that we try to make it really accessible and easy to setup. We made a comparison page that sums it up here: https://infinit.sh/documentation/comparison/tahoe-lafs
Note exactly, Tahoe only has Tahoe nodes chatting between each other; it can be the decision of a given Tahoe node to actually store content in the cloud rather than on the local file system, but that's a node-specific decision, not something that each Tahoe client has to speak.
This is really interesting for my growing photo archive where syncing isn't important (and even potentially problematic) but where covenience is! I need to take a look at this, thanks.
For uses like this, I really want the ability to prevent any user (myself included) from deleting or modifying preexisting files: no matter how a client screws up, I want to be able to get old data back. I wonder how Infinit handles this.
Fantastic! I hope it allows rollback to an earlier version of the entire filesystem, too. I know people who have lost large amounts of data on Dropbox because some client-side issue (malware or just plain error) deleted everything. I think they also had some online backup service that could roll back files but only if the file was still there, which is useless.
Will you also support deduplication (files, blocks, context-aware blocks, or otherwise)?
12. Dropbox Project Infinite (dropbox.com)
741 points by maguay 3 days ago | flag | 288 comments
...
17. In Reaction to Dropbox's Project Infinite, Infinit Announced Project Dropboxe (infinit.one)
693 points by winta 5 hours ago | flag | 92 comments
We're planning on open sourcing our implementation for the FS. We want to do it responsibly (i.e.: not a giant code dump) so it's going to take a little time. You can see our build system here: https://github.com/infinit/drake
We haven't publicly released our Windows client yet but our internal build hasn't had stability issues.
This is really, really cool. Anyone know where they prefer to post issues/requests? Looks like Github is mostly dead[1], but there is a uservoice[2].
I'm debating replacing Camlistore with this - i prefer Camlistore, but this appears to have better tooling, and easier for me to peer with nontech people
We're still working to open source the code and put in place the infrastructure to manage a community. I'd encourage you to chat with us on IRC (freenode #infinit) or on Slack (see bottom of our homepage https://infinit.sh)
Online (cloud) storage seems to be a pretty silly business to operate or invest in, given the amount of solutions available and also the "threat" of open solutions that will inevitably become popular (such as IPFS). Also, essentially, storage is a commodity product. It is ready for a race to the bottom.
Also IPFS is being developed as a basic layer. Since it is open, we may expect many independent developers to provide things like access control, and a POSIX API on top of it.
So when the train needs to break it generates energy for storage that can be used later uphill etc. Simple and interesting, especially for regions with a lot of variation of heights.
We don't do any ARM builds yet. It uses the same C++ backend we built for our file transfer application which runs on iOS and Android so it shouldn't be too hard for us to get it working on a Raspberry Pi.
Alright, good to hear that it is within reach. In our startup what we want that we can't get from Dropbox/Google is privacy. I've been looking at owncloud which would give us privacy but redundancy seems complicated and therefore my excitement about you guys. The possibility to start out super cheap with two RasPi3 and external drives and in the future migrate to more scalable solutions like S3 would make this product pretty awesome for everyone from home tinkerers to enterprises.
Dropbox? No thanks, no integrity there. I'm looking forward to protonmails comming equivalent. Security and integrity for the win! It does not matter that I've nothing to hide, nsa etc has no right to prive in my personal life.
> 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/