
Infinit announces Project Dropboxe - winta
http://blog.infinit.one/infinit-announces-project-dropboxe/
======
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](http://www.catb.org/esr/writings/taoup/html/plan9.html)

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

~~~
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](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/](http://ipop-project.org/)

[1] [https://github.com/ipop-project](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...](http://dedis.cs.yale.edu/dissent/papers/hotpets14-torpath-abs) \-- 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.

------
futuravenir
Great marketing. I'd never heard of Infinit before. Now I have.

Can anyone describe to me how it differs from MaidSafe?
[http://maidsafe.net/](http://maidsafe.net/)

~~~
edraferi
They have an excellent comparison FAQ:

[http://infinit.sh/faq?q=&hPP=20&idx=infinit_sh_faq&p=0&is_v=...](http://infinit.sh/faq?q=&hPP=20&idx=infinit_sh_faq&p=0&is_v=1)

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.

~~~
aidenn0
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.

------
tux3
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".

~~~
Sephr
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".

~~~
curryhoward
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.

~~~
criley2
>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!!

~~~
koluft
Such are the risks of naming your company after a common word that describes
the product.

~~~
criley2
>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?

------
davidwtbuxton
Ha! Reminds me of Nick Lowe's reaction to David Bowie's Low.

[https://s-media-cache-
ak0.pinimg.com/736x/f6/a2/a1/f6a2a1ca4...](https://s-media-cache-
ak0.pinimg.com/736x/f6/a2/a1/f6a2a1ca47c79fc0f0f7a2f38a0ff5f2.jpg)

[https://tomhuntington.files.wordpress.com/2009/10/bowi-
and-r...](https://tomhuntington.files.wordpress.com/2009/10/bowi-and-
record.jpg)

~~~
nocman
or the band "Green"'s response to the R.E.M album "Green":

[https://en.wikipedia.org/wiki/Green_(band)](https://en.wikipedia.org/wiki/Green_\(band\))

(look under the heading "Singles")

xD

------
mtrn
Never heard of infinit.sh, but it looks great. The repo is almost empty,
though
([https://github.com/infinit/infinit](https://github.com/infinit/infinit)).

Is the code completely open source? Could I setup infinit.sh inside my own
infrastructure?

~~~
cadeuh
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!

And yes, that's exactly why it was made for. Have a look at our examples of
deployments:
[https://infinit.sh/documentation/deployments](https://infinit.sh/documentation/deployments)

~~~
virtualritz
That sounds like I will be able to deploy infinit.sh on my NAS (QNAP 469),
running some ARM Linux flavor?

~~~
ccrone
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.

Feel free to add and upvote what you'd like to see: [http://infinit-
sh.uservoice.com](http://infinit-sh.uservoice.com)

------
nashashmi
Terrifically smart jab at Dropbox. If only more companies could take up this
sort of attack, lawsuits would stop complicating life.

~~~
dhimes
We've yet to see where this ends, however. Legal papers may be next.

~~~
zymhan
You didn't read the post, did you?

> 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.

~~~
Grue3
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.

~~~
akrigline
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.

------
mark-r
Reminds me of the time back in 1977 when David Bowie came out with an album
called "Low", and Nick Lowe followed with an EP called "Bowi".

------
olavgg
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.

~~~
ccrone
Thanks, we think the same :)

You can join us on Slack or IRC so that we can chat more!

------
sghi
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...

~~~
wavefunction
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.

~~~
TallGuyShort
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?

~~~
outworlder
> If you use a relatively mainstream word from the language in which you do
> business

What about "Windows"? Or "Word"? Or "Office"? It's difficult to find words
that are more "mainstream" than that. Yet, Microsoft does just fine.

~~~
TallGuyShort
Yeah and if Microsoft made tongue-in-cheek blog posts about IBM because they
had something called "Project Officer" we'd all roll our eyes.

------
Uberphallus
It looks like Tahoe-LAFS, but without redundancy. Am I missing something?

~~~
cadeuh
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](https://infinit.sh/documentation/comparison/tahoe-lafs)

~~~
Uberphallus
Tahoe is listed as homogeneous, but there are arbitrary backends, including
cloud ones like Dropbox.

~~~
rakoo
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.

------
jug
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.

~~~
amluto
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.

~~~
ccrone
We plan to add versioning for exactly this. It's on our roadmap which you can
find here:
[https://infinit.sh/documentation/roadmap](https://infinit.sh/documentation/roadmap)

~~~
amluto
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)?

~~~
ccrone
We already offer replication so that if a node goes down (or loses data)
clients can still get their files.

We could add deduplication to our system but it's not a priority for us just
yet

------
tedmiston
The real question is which one will win on HN.

/best right now:

    
    
        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

------
jorangreef
What are Infinit using for the Windows file system? Dokany? How is it working?

~~~
ccrone
Yep, we're using FUSE for OS X on Mac and Dokany for Windows

~~~
jorangreef
Thanks, will you be open sourcing your FUSE and Dokany bindings?

Are you getting any blue screens of death with Dokany? Is it stable enough?

~~~
ccrone
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](https://github.com/infinit/drake)

We haven't publicly released our Windows client yet but our internal build
hasn't had stability issues.

~~~
jorangreef
Thanks, looking forward to learning from the source.

------
cranium
Thanks to Infinit for this, it was right on my humour sweet spot!

------
fizzbatter
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

[1]:
[https://github.com/infinit/infinit/issues](https://github.com/infinit/infinit/issues)
[2]: [https://infinit-sh.uservoice.com](https://infinit-sh.uservoice.com)

~~~
ccrone
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](https://infinit.sh))

------
kylec
In a similar vein, I'm disappointed RedTube didn't launch something called
"RedTube You" in reaction to "YouTube Red"

~~~
TallGuyShort
"In Soviet Russia..."

------
amelius
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.

~~~
programLyrique
They compare Infinit with IPFS:
[http://infinit.sh/documentation/comparison/ipfs](http://infinit.sh/documentation/comparison/ipfs)

"Note however that IPFS does not focus on providing high-level file system
functionalities such as access control, POSIX compliance "

~~~
amelius
Yes, IPFS was just an example.

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.

------
tschellenbach
This is hilarious :) Also, it's a terrible thing for our friends at Infinit.

------
sickbeard
"Project Dropboxen"

------
kempe
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.

~~~
nekopa
Methinks your comment is misplaced.

But I did have a moment of joy at the Monty Python-esque comedy it brought on
:)

~~~
kempe
LOL yes it is, was supposed to go to another article.

------
vikeri
Exactly what I've been looking for! Does anyone know if I could run this on a
couple of Rasberry Pi 3?

~~~
ccrone
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.

~~~
vikeri
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.

------
Jemmeh
You could do this all day. Like an _infinite_ loop. ( ͡° ͜ʖ ͡°)

------
NamPNQ
Base on FuseFS

------
Odenwaelder
Such data. Many byte. Wow!

------
Amir6
In reaction to Infinite's reaction to Dropbox's action, I announce my
"Reaction".

------
kempe
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.

