Infinit announces Project Dropboxe | Hacker News Reader

Infinit announces Project Dropboxe

blog.infinit.one

830 pointswinta134 comments

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/

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.

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

You seem so angry for such a bizarre reason.

Maybe he used to have 'r' as login.

Irrationality and denying reality annoys me.

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

And what's that to you?

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

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)

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.

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.

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]

More short sighted business practices as usual.

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

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

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.

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

Read my replies to your sibling comments for more details.

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

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

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.

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.

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

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/

They have an excellent comparison FAQ:

http://infinit.sh/faq?q=&hPP=20&idx=infinit_sh_faq&p=0&is_v=...

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 it's a joke. They ain't going to actually use it for any product.

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

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

I don't know anything about Infinit or Infinite, but I do know that no product could be described as "infinite"

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

The USPTO may have a differing opinion.

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 like how Infinit responded.

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

Yep, it makes sense because when you drop something into the box, you can't get it back out.

https://en.wikipedia.org/wiki/Post_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)...

"infinit" is a dictionary word in the language spoken by the company founders.

If you mean french for the infinit.one founders, it's actually spelled "Infini".

"dropbox" is not a dictionary word.

http://www.macmillandictionary.com/dictionary/american/drop-...

Dictionary words can still be trademarked.

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.

Dropboxe isn't a standard dictionary word

Is anyone else sick of people having to justify the words they use to describe their ideas? It's one of the most toxic effects of IP.

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.

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://tomhuntington.files.wordpress.com/2009/10/bowi-and-r...

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

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

(look under the heading "Singles")

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

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

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

Excellent, thanks!

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

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

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.

"Coming soon" http://infinit.sh/open-source

Great, thanks, would love to contribute since it looks like a useful product.

Feel free to come in our Slack channel or send us an email!

Thanks, just sent an request for invitation.

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

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

That will Streisand on Dropbox very quickly.

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.

A search engine spider may not be able to understand this kind of subtlety though, let alone parody.

When people name their company generic words about their product, that's what happens.

Show some creativity if you want to be uniq.

ITT: People not getting the joke

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.

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.

If Dropbox is not aware of every competitor and their products in their market space, someone isn't doing their job very well.

How can you properly respond to your competition when you are ignorant of your competition's existence?

A company of Dropbox's size most certainly has a legal department that does, among other things, trademark and patent searches for upcoming products.

It was recognizable as satire already, but that part made it even more crystal clear. Dropbox would get thrown out on "fair use" grounds PDQ.

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'm talking about Dropbox.

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.

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

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.

Thanks, we think the same :)

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

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?

Parent was saying the "Dropbox" is also a generic word.

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

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.

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

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

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

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.

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

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

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

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

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

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

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?

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.

Thanks, looking forward to learning from the source.

Wow, didn't even know something like Dokany[0] was even possible on Windows, let alone being already available!

[0]: https://github.com/dokan-dev/dokany

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

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 [2]: https://infinit-sh.uservoice.com

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)

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

"In Soviet Russia..."

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.

They compare Infinit with 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 "

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.

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

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.

Methinks your comment is misplaced.

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

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

This is also how electric car brakes work, going back to the Prius.

The concept of a flywheel goes back much further than that.

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

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.

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

Base on FuseFS

"Project Dropboxen"

Such data. Many byte. Wow!

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

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.

Reply on news.ycombinator.com