Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox
284 points by arpitagarwal on Dec 21, 2021 | hide | past | favorite | 185 comments
Hey folks,

We are the team behind Slik.

Over the past year, we have been hacking on SlikSafe [1] a Dropbox alternative where all your data is first encrypted on your own device and then stored on decentralized storage.

Some features we're most excited about are -

  - multi-device data sync,
  - auto-backups via desktop apps,
  - search your docs by name or contents with end-to-end encryption,
  - easy sharing via email, QR-code or private-link,
  - Password-less login using MetaMask/Phantom
We leverage storage providers IPFS and Storj for global redundancy, reliability, and immutability.

You can use our web app [2] and macOS app [3] today. Our desktop app for Windows is currently in beta, and will be launched in early Jan.

You can read our WhitePaper [4] for the technical implementation, or see a quick demo [5] of the product.

Would love to hear what you think.

Arpit, Charvi

[1] SlikSafe: https://www.sliksafe.com

[2] Web app: https://app.sliksafe.com

[3] macOS app: https://sliksafe.com/downloads

[4] WhitePaper: https://sliksafe.com/whitepaper.pdf

[5] Demo video: https://www.loom.com/share/abe133c4ce874655a952a30601e99408



The website and demo look cool, I like your clean and simple design. The supposed whitepaper however doesn't go into any details at all. It says in addition to Storj the files are also stored directly on "the blockchain". What blockchain? It's not even named. There are no technical details on the encryption process or anything else either.

I'd love to like this because imo decentralized private storage is an important issue that urgently needs solutions. But how can you convince people this is better than trusting dropbox when you don't even tell them how it works? And how do you guarantee lifetime storage through a small one time payment? Surely Storj disk space providers aren't going to host files for free.


If a quantum computer gets good enough to crack common encryption algorithms, what are the consequences for decentralized storage? Could some hostile nation state just collect and store the data until such time they can decrypt it?


We'll have much bigger fish to fry than worrying about decentralized storage.


Sure, that’s true. However, I would personally like to know whether “all my files being out in the open forever” is a thing I need to worry about in addition to all the default problems


If encryption gets cracked by quantum computing, everything digital that's connected to the Internet, is "out in the open" until quantum-proof encryption becomes the norm.

The only way to be sure would be to physically self-host with the option to air gap the storage from the Internet.


That's a great point. However, in Slik's case, the data is first fragmented into small chunks and then distributed into a decentralized storage. Thus, for a bad actor to pose a problem, they'll also have to collect all the encrypted chunks, before making any sense out of it.


Okay so the chunks are distributed, a follow up question is are they duplicated to multiple copies per chunk? I ask because if one chunk is lost then the data would be unusable wouldn't it?


That's some great feedback, trompetenaccoun. Slik's file storage is powered by Storj and Filecoin. About encryption, would love to hear what part you find missing in the 3 protocols for backups, sharing, and multi-device support, mentioned in our WhitePaper.

We're constantly improving our WhitePaper to provide as much clarity as possible about our systems and algorithms.

We had set lifetime storage for 10 years, and have clarified it on our website to prevent it from being misleading. Thanks a lot for your inputs! :)


> We had set lifetime storage for 10 years, and have clarified it on our website to prevent it from being misleading.

If you say it's lifetime and then have to explain it as being 10 years, it's still misleading. Just take out the word 'lifetime'.

The chances of me trusting a technology company, especially a startup, especially especially one doing anything on blockchain, to provide a lifetime service is effectively zero. Annual pricing is fine; if you want to go crazy offer two or three years.


"lifetime" meaning "10 years" makes no sense at all. It makes your company seem incompetent or badly intentioned. Just say "10 years" if that's the time period.


Thanks for the great feedback Gary! We'll work on it. :)


> Slik employs authenticated symmetric encryption. We use AES block cipher in Galois Counter Mode (GCM) with 256-bit key for all of our encryption operations

That plus the high level overview of the algorithms seems fair enough for a whitepaper

Although I don't get what additional security is gained from using an additional symmetric sharing key in protocol two. Isn't the key gonna be encrypted anyways with the temporary public key from Bob? Also which protocol is used for the asymmetric encryption?


I haven't really understood how the "decentralized" comes into place. My notion of decentralization is the existence of multiple instances managed by unrelated people, such that the service keeps going if one actor falls down. From what I see here, the decentralization lies in the fact that the central service stores the data across multiple servers. So it's not technically speaking a lie, but i would say it is a bit missleading.

Edit: If this is/was a trully decentralized tool (which would imply some sort of open source code to host it) i would be stoked


Great points gtsop! We have a very similar understanding of decentralization. My co-founder and I are passionately working on making sure that we eventually reach that goal where Slik keep going, even if any one actor falls down.

Here were our goals when we started this out -

  - Prove and implement the encryption technology [completed],

  - Switch over from centralized storage to decentralized storage [completed],
The above two goals help us achieve a working solution that users can start adopting.

Next few near-term goals are -

  - Switch over from centralized compute to decentralized compute,

  - Make the code open-source so that the technology can be extended, forked, etc as the community needs.
Hope that gives you a reason to be stoked! :)


> My co-founder and I are passionately working on making sure that we eventually reach that goal

Isn't it a bit sketch to be calling it decentralized if that's merely a goal though?


as they've outlined the storage is decentralized the compute is not. I don't think its an unfair sales pitch - they clearly are heading down the right path.


> the storage is decentralized the compute is not.

How does that work? Are people sharing storage? I.e. is it truly using "p2p storage" even if the transfers (at this point) are centralized?


  - Switch over from centralized storage to decentralized storage [completed],
kind of looks like they are already there?


Thanks for the detail, yes now I really look forward to that :)


super! :)


The terms are not well understood. Allow me to over simplify this into 3 buckets:

* centralized - a single funnel by which all traffic is managed, such as a web server

* federated - various disparate nodes comprising a centrally managed/governed network. This is blockchain and IPFS where the network is an application layer protocol. The more appropriate description is pseudo-decentralized or semi-autonomous. It is not centralized but it is also not fully decentralized.

* decentralized - disparate nodes communicating directly using agreed upon conventions. There is no centrally managed network. Think in terms of snail mail, IPv6, or phone numbers. This could be as simple as people using an agreed upon application to abstract away the transmission concerns but that application does not route traffic through a third party server.

The greatest misconception, or rather abuse of the term decentralized, I am seeing on HN is confusing it with a federated scheme. Federated schemes are not decentralized. Web3 is not decentralized. They are distributed.

In some cases the abuse of these terms is accidental, but it seems in many cases it is intentional. I suspect some large organizations, yes I am looking at you Facebook and Andreesen-Horowitz, are fearing functional obsolescence, either in their investments or their properties, in the near future and so are attempting to validate their existence by muddying the waters. By functional obsolescence I mean what would you need Facebook for if you can directly transmit media, or micropayments, between friends and family without some sinister third party destroying your privacy. The commercial web has become very hostile to its users, so pending a proper convenient end-user application, there is little incentive to continue using the web.


The most common canonical definitions in regard to network connectivity graphs are:

Centralized: most of the data and compute lives in one place and is controlled by one entity. This is standard issue SaaS, etc.

Federated: anyone can run a server and the servers can talk to each other somehow and either propagate messages or replicate data, but still centralized from the client point of view since each client connects to one or more servers. While anyone could run a server it often requires a lot of administration overhead, storage, and often "peering" permission from at least one other server.

Decentralized: clients are servers and everything connects in some kind of mesh graph.

It's not a binary thing, more of a gradual shift. Bitcoin for instance is somewhere between federated and fully decentralized. Technically anyone can run a node and they connect in a full mesh, but most users don't use it like this and the cost of running a node is at least "annoying" for most people (a lot of bandwidth and storage).

Centralized systems are the easiest to engineer by far but come with the obvious downsides of single point of failure, moral hazard, censorship, lock-in, latency issues if you are not near the servers, etc.

Federated used to be very very common. Classical e-mail, Usenet, FidoNET, UUCP networks, etc. are all federated systems. The old school file server with mirrors paradigm is also a simple from of federated network. It declined in popularity when all the old systems fell victim to spam but is rising again in the form of things like Mastodon.

There are not very many fully decentralized systems in common use. The most well known is probably the BitTorrent magnet network. Fully decentralized systems that are secure, robust, fast, and light on resources are incredibly difficult to engineer.

Edit: if you look deeper it gets more complicated though. Google, Facebook, and most of the other "hyperscalers" are federated systems under the hood but this is all hidden from the user. They are still "logically centralized" though.

It's possible to further break things down by what is decentralized. You can have decentralized or centralized compute, storage, trust, control/administration, and so on.


The third point is peer-to-peer in my understanding. Decentralized to me means that there isn't an entity who has custody/control over information propagated by the network and ability to control access to it


You're referring to decentralization of trust, while peer to peer means decentralization of compute and storage.

You can have a system that is decentralized in one way but not another. A peer to peer system where every object must be signed by a centralized authority has decentralized compute/storage and centralized trust. The Apple ecosystem is probably the best example of that. Apple has to sign or notarize most things but these things are then sprayed across a huge diaspora of machines.

A physically and computationally centralized repository of objects that anyone can create is the opposite. GitHub is a good example of that.

The BitTorrent magnet network and most cryptocurrencies are examples of systems that are decentralized in both respects.

Eliminating all forms of centralization without making huge sacrifices in areas like security or efficiency is really hard. I would say it's an unsolved problem since even if you try really hard centralization tends to creep in... e.g. how proof of work economies of scale create centralized mining cartels in cryptocurrencies. PoW is also very expensive, making it inefficient but moving that inefficiency "out of band" and hiding it in an externality.

Decentralization is a big rabbit hole.


Yeah, I was thinking if you really wanted decentralized something like Syncthing would be the direction you would want. Each individual computer manager who/what it shares with.


I understand it this way. Say, you are a nuclear terrorist and store atomic bomb schematics in S3. The FBI learns about that and tells Bezos (or whoever is Amazon CEO these days) to delete your files or go to jail. Bezos obliges. That's the centralized service.

Now if you store your atomic bomb schematics in Storj, FBI can't delete it because it's distributed across thousands of computers whose owners don't even know what they are storing.


Another piece of it, I think, is the lack of a central authority that can censor and/or pry into your content. With any well-implemented zero-knowledge solution, this should be the case.

Is that maybe a bit misleading? Probably, but a lot of people who search for decentralized are looking for something "off grid" in the sense of no one is watching vs "off grid" in the sense of roll your own grid.


Decentralized in this case means you don't trust a single entity to control your access to your data.


My own interpretation of the definition of decentralized as it pertains to technology would also imply there is not a single super-node you have to boot-strap from. One should be able to host their own boot-strapping cluster of nodes so that if a company goes out of business their nodes will continue to work, software updates not withstanding.

Not depending on a single node to me sounds more like distributed like Tor or clustered like Ceph or in some cases federated like Mastadon or Matrix.


Not sure I understand. Should you trust Silk in this case? Wouldn't any issue with this company mean unavailability to everyone's data? Maybe i have missunderstood the producy


Isn't git decentralized?


In theory, but who uses something other than either Github or Gitlab?

Obviously I know some people do, but I've yet to work on a project that doesn't just stick with the one.


I believe everyone here is talking past each other. Decentralization doesn't just mean hosting. My copy of git repo is equally as valid as yours. Or, the master branch is nothing special, any branch is equally as important. In that way, it is decentralized.

But, as you're saying, rightfully, hosting of the remote repository is in the hands of Github. So its not decentralized.

These discussions tend to be like the ones involving 'conciousness'. Until a clear definition of the term is agreed upon, it is impossible to talk about it. Going around measuring with a yard stick requires that the stick is calibrated to a yard and everyone agrees it is a yard. May be you can do some probabilistic measurement (consensus of people whether something is decentralized or not), but it's pretty useless.


Interesting that when given a choice, people choose centralised over decentralised.


That's because of economies of scale. It's much cheaper/easier to do something when it's the only thing you do. It's why we have professions, rather than each of us doing a bit of everything.


i think this is mostly because of the maturity/popularity of the tooling, not the underlying aspect of centralization. if there was a just as slick, widespread and useful decentralized alternative, i would be on that instead.


Depends on what problem the adoption of decentralisation is solving. There's no point choosing a decentralised option just for the sake of it.


i think i would choose decentralized almost all of the time if it worked the same performance wise


Sqlite

https://www.sqlite.org/whynotgit.html


I've heard of companies that pass their git repo around on a USB disk? lol.


Distributed. Federated.


Isn't it impossible to really delete something from ipfs? I'd think that would make this dangerous, as any security flaw would be impossible to fix retroactively. Everything before the flaw would be compromised and can't be reencrypted safely.

If a passphrase was lost, the security of every past file would be at risk.

This is what has kept me from approaches like this in the past.


Yes, that's one reason I'm really not sold on storing private data on IPFS and similar services.


You can unpin it, and it will eventually be removed from other non pinned sources.


>it will eventually be removed from other non pinned sources

Hopefully, though, they unpin it.


Can you really delete anything from NSA servers? Or from Internet in general?

For me the problem with IPFS is - it is just not interesting enough. It's not a storage solution, it is distribution and caching mechanism. You can't really upload to IPFS, you can only publish via IPFS - the same way you publish via HTTP.


I am quite confident that the NSA does not have a complete image of the encrypted data in my self-hosted Nextcloud instance. With IPFS they wouldn't even have to do anything, if they sometime in the future were able to break the encryption.


Yeah there's actually powerpoints from the snowden leaks showing how much they ingest per month and how much of that they keep, etc.


So how much do they keep?


https://en.wikipedia.org/wiki/Room_641A

I looked at this briefly for a security module for my MSc and from what I vaguely recall they were tapping roughly half of all data going through AT&T on the West coast


After skimming the whitepaper and the storj website, I am not sure which parts are actually provided by Sliksafe.

The website tells me I can pay by solana (or even by credit card!), but there seems to be no indication of how much I actually would have to pay.

The claims are also not exactly thought out:

> No Backdoors > > Since all your files are encrypted on your device, there is no way for us at Slik Safe to access them ever. Even if we wanted, we could never access them.

That does not follow from the provided info. Simply leaking the keys in some form would already be enought as a backdoor, as the data is obviously not only stored locally.

There seems to be a lot of metadata on sliks side, or is it using some form of encrypted search?

Reminds me of "the good ol time" while working on distributed storage, getting annoyed about the filecoin whitepaper and its inaccuracies and missing references (which of course got much much further than our small research project)!


> I am not sure which parts are actually provided by Sliksafe.

The full end-to-end encrypted backup and sharing experience is provided by Slik. We use Storj only for storing the encrypted blobs, or simply as a replacement of S3.

> The website tells me I can pay by solana (or even by credit card!), but there seems to be no indication of how much I actually would have to pay.

Our detailed pricing page is currently available within our web/desktop apps. You can pay - 0.1 SOL for 10 GB lifetime storage (10 years), or

  - $4.99/mo for 500GB storage, and so on..
> That does not follow from the provided info. Simply leaking the keys in some form would already be enough as a backdoor, as the data is obviously not only stored locally.

This is similar to the problem of leaving your device accidentally open, which unfortunately is a much harder problem to solve. However, we do provide a way for you to remotely wipe a device in case of unauthorized access.

> There seems to be a lot of metadata on sliks side, or is it using some form of encrypted search?

All your metadata is encrypted on your device before it is backed up to Slik. We provide client side search experience so that Slik is unaware of even the keywords that the user is searching for.


How did you arrive at SOL instead of BTC or ETH?


That was simple, it is fast and scales as you need it. No logical consumer would like to pay gas prices of $120 on a transaction of $20.


Congrats on the launch! Your implementation of sharing from the whitepaper scares me. The second that the private key travels anywhere it's no longer safe in my opinion. This is why Signal uses the double ratchet and 1password has their own sharing. Unless I missed something.


The whitepaper has no details about an authenticated key exchange like Signal does with X3DH, it just assumes that it already happened, but then the rest of their protocol does not offer any post-compromise security.


Great point! We integrated the QR-code and link based sharing into the app to provide a seamless experience for users.

However, we also have an email sharing solution already integrated into the app which uses public-key cryptography. This is protected from accidental leaks as you correctly pointed out.

Thanks for the feedback, we would update our WhitePaper with the details from above, and also indicate that to users in the UI - so that it scares people less! ;)


So, how does this compare to a solution like Bittorrent Sync?

And, perhaps more interestingly, why would this become popular where BT Sync failed to live up to the hype?

Furthermore, storage can be paid for by crypto. Does this mean the storage is linked to some kind of cryptocurrency, or is there some kind of central payment system that converts crypto into actual value in the system?


BTW this has now been renamed to Resilio Sync.

I still use Resilio but am looking for an alternative since development seems pretty dead at this point (no updates for months).


syncthing


Another vote for syncthing. I have Synology home NAS, Syncthing in Docker on NAS, Tailscale on both Synology and my laptop so the IP address of the server is always the same, and it works way better than either Dropbox, OneDrive or Synology's own SynologyDrive.


What’s wrong with Synology Drive?

It’s working just fine for me.


Definitely syncthing - it's incredible. I have all my files managed with it, bare git repositories managed with it, a common shared folder with my partner, my android phone auto uploads photos etc.

It all truly just works and it works well.


I’ve used syncthing for years now to keep a bunch of large folders with millions of files synced between multiple computers running windows, linux and macos. Works really well and it is light on system resources.


Same here. No updates for over q year. In constant worry that the next OS update (iOS, DSM and MacOS) will break resilio sync and with that my files.


It seems btsync (Resilio) has had minimal development over the last few years. I used to be a huge fan but had to stop using it since I kept hitting weird SQLite errors and all support channels seemed dead


I'm always interested in the business model of a company before using their products.

Storj is mentioned as a part of the tech platform. Is the goal of eventually open sourcing Slik essentially is what is described as an open source partner in the Storj whitepaper executive summary [1]? Relevant part here:

> Bridging Open Source and Decentralization

> In addition to being open source, our new V3 network also financially empowers open source companies by enabling them to generate revenue every time their users store data on the cloud. This supports the open source companies interested in monetizing their product’s use in cloud, while also helping Storj grow adoption of its platform within the innovative open source community.

> The new program is enabled by the network through connectors built in conjunction with each open source partner. The connectors track data usage either by storage bucket or by user. When data flows through one of these connectors, the open source company is given credit for the usage and a percentage of the revenue generated flows back to the corresponding project. Partners also earn revenue for bandwidth usage on the network.

Storj pays out on average per month [2]:

> Egress Bandwidth $20/TB > Repair Egress Bandwidth $10/TB > Disk Space $1.50/TB > Audit Bandwidth $10/TB

How much is Slik going to charge to use the app? It almost seems like it the app should be free, or even get paid to use it, if all we are doing is providing the resources for the paying Storj customers.

[1] https://www.storj.io/whitepaper [2] https://www.storj.io/node


Those are some great points, no_circuit. We have multiple storage pricing plans, however, none of them give out $'s to users, because that would be counterproductive for the team at this point.

There are parts of the system like the multi-device sync, encryption, cross-platform support, etc. that would need to be factored in. However, reducing $/TB is an area that we plan to explore when all other systems are stable and our unit-economics is net positive.


I don't need that. I can just set up an SFTP server and rsync my files to it.


There's the standard Hacker News response I was looking for


You can almost set your watch to it.


I don't need that. I rsync my watch with nist.gov


Congrats on the launch, looks really slick!

I'm trying to decode the trend for decentralized services. If you have a sec:

Q1: In your case, why did you opt for decentralized storage?

Q2: Which benefits do I get as a consumer that I wouldn't if this was encoded, but centralized with a lot of redundance?

Don't take me the wrong way, really trying to understand where this is all going.

Cheers


Where's the source code? If it's not under a libre license, then it doesn't matter that you are decentralized, control is still centralized in your developer team.


An e2e Dropbox alternative would be great. Though for it to actually count as a Dropbox alternative (to me) it would need:

  1) a Linux app
  2) an Android app
  3) on-demand syncing, aka "smart sync"


Those are some great requests. Thank you!

We currently have a macOS app available and are targeting January for a Windows launch and a Linux launch soon after. We also have an iOS and Android app with a few beta users, and will release it around Jan/Feb'22.

Slik’s desktop apps have the ability to automatically detect changes in your local connected folder and sync those changes.

About On-demand syncing - we built Slik in a way that, once backed up, no files are required on your local machine. This doesn't prevent you from searching through all your files, and you can selectively download files based on your need.

However, I have added an item on our roadmap that would selectively download folders for offline syncing and faster access. Thanks again!


The other half of what I'd consider "smart sync" is delta sync -- basically only uploading the bit of a file (or other reasonable small chunk) which has changed. Dropbox does this well, and is very useful if you're only making a small change to a GB file. Last I checked, this has not yet been handled well with encryption. Even worse if you try to do a naïve e2ee cloudstore by e.g. putting an encrypted volume on dropbox.


Nextcloud does this, you need to install an extension (they call it "app") [1] to enable e2e encryption. It offers all features you require.

[1] https://apps.nextcloud.com/apps/end_to_end_encryption


Nextcloud syncing is terrible because it's based on WebDAV. It's slow, especially with lots of files. And it's not reliable.


Speed leaves something to be desired but I have not had problems with reliability. I've used it - and Owncloud before that - for almost 10 years without losing any files. Which problems are you seeing?


Are you looking for Syncthing? https://syncthing.net/


I am looking for syncthing but with an iOS app.


There's https://www.mobiussync.com/


Has iOS just not been implemented yet or is there a technical hurdle?


There was a propriety implementation a few years ago (written in Rust of all things), but I think it's dead.

I think the bigger problem is that both iOS and Android are doing everything they can to deprecate the concept of a filesystem. Android has a history of killing filesystem features, receiving tons of developer backlash, and then hacking in workarounds with reduced performance. I think the writing is on the wall.

In my experience, porting general purpose tools to Android is a nightmare.

Hopefully something like pinephone gets good enough before things are too bad.


As long as Android has a Linux kernel running in the background there will be filesystem access. If Google ends up switching to Fuchsia this might change but we're not there yet. General purpose tools seem to run just fine on Android for the most without the need for much porting as can be seen by glancing through the list of patches [1] needed to build a host of packages for Termux.

[1] https://github.com/termux/termux-packages/tree/master/packag...


Not trying to come across as argumentative, but have you personally worked on porting something to Android? Termux actually illustrates my point. That situation is an absolute mess[0].

[0]: https://www.xda-developers.com/termux-terminal-linux-google-...


Yes, I ported a few tools to Android and worked on a few Android ports to random devices (Motorola Defy and Ainol Novo Advanced 8 being the ones I was most involved in). With regard to the problems of the "Play store" requiring $things I'm not affected since I do not use it, there is no Google-proprietary software on any of my devices. If I ever need something from the store I get it anonymously through Aurora Store. Maybe this is why my opinion of/experience with porting *nix tools is less negative?


Syncthing doesn't do smart sync. The library of stuff I want available is larger than can fit on my phone.


Syncthing has ignore files which can be used to selectively not sync certain files or folders per device. I'm not familiar with Dropbox's smart sync, so if it's like a transparent on-demand sync then no, Syncthing doesn't have that.

Maybe it's possible to implement that as an extra app though, without even touching Syncthing. Android seems to have some concept of virtual file systems provided by apps so perhaps one could on-demand un-ignore files then block until they're available. (But yeah, that's definitely more than a quick hack.)


That isn't a usable UI on Android.

In Dropbox, if I want a file I haven't synced yet, I just browse to it and open it. I can also mark folders as available offline.


Does Syncthing support manual on-demand downloading? What I'd really like is a way to browse files and download only what I need without eagerly syncing everything all the time.

I'm using Seafile for that now, but I don't like that it needs hosting and I'd love to switch to something P2P and get rid of the server.


It's no longer maintained I think but probably still works: they did have Syncthing Lite which functions like a traditional client - https://f-droid.org/packages/net.syncthing.lite - https://github.com/syncthing/syncthing-lite


Interesting thanks. So the protocol supports it, but the official app doesn't expose functionality shaped the way I want. I'll have to see if I can get that lite app running on PC somehow.


The syncthing ignore file works exactly like picking what folders to sync in drop box, just in a text file instead. (and the ability to use file globs if you want)


I have multiple top-level syncthing folders to work around that. Different machines get different sets of folders.


Interesting approach, but if it's decentralized, can I fully self-host? I feel like this term doesn't really apply when you have a centralized provider.

If you have a solution we should be trusting, I would avoid "buzzword bingo" and just be straightforward with your customers.


Don't see how it's better than syncthing, which is free. I don't want a company whose incentive is to make profit to have control over the software.


> SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

but

> https://firestore.googleapis.com/google.firestore.v1.Firesto...

This does not pass the sniff test.


This is pretty interesting. A while back I was in the early engineering team that built something with similar characteristics (Maginatics > sold to EMC/Dell). It was a cloud (S3, others) distributed file system with variable-length chunks, per-chunk encrypted, with strong deduplication and focus on metadata operation optimization. We were primary storage (vs backup), making it a lot more challenging (performance, app compatibility, real-time collaboration, etc). The demo is pretty interesting, definitely need to read the whitepaper.


Looking forward to your feedback!


How is the blockchain structured? Is it shrinkable?

In theory, each user would only have a directory of paths and hashes, and everything else would be accessible via ipfs, correct?

What kind of encryption are you running? First of all, if there's a simple password like recovery mechanism, it's never post-quantum. Second, if you are refering to the _hashing_ mechanism (merkle trees) in ipfs; I would still have my doubts about the claims.

So what kind of Lattice based encryption mechanisms are you running? How do you preserve hash maps to user filesystems, if the data itself is encrypted? If the data itself is encrypted (which it should be), then - by concept - your whole blockchain doesn't make sense because you can literally reuse zero bytes in the whole system.

Either that or you would have to implement a key chain where other users can see my private pics, and have a system that allows multiple keys to access the same data blocks.

So, from your statements in the "whitepaper" I'd argue that this is a paradoxon, and probably bullshit. Either it's not encrypted at all (more likely) or you don't use a blockchain. If you do both, you have no idea what a blockchain's advantages are, which would make me even less likely to trust your product or vision.


Most of this is on their website and/or WP…

They don’t store files on the blockchain, they don’t claim to have their own blockchain.


> They don’t store files on the blockchain,

From the whitepaper:

> As an extra layer of protection, all your encrypted files are also stored on an immutable blockchain

(Yes, that's probably "just" incompetence on the part of the whitepaper author, but if you can't even get a competent author for your whitepaper...)


How could this be integrated with the Chia project with proof of space? The problem with Chia is storage is filled up with useless data, if you could use your photos or other long term data that would create something great.


That sounds like a great idea, cdnsteve. Slik can very easily be integrated with any backend, and we have explored more than 5 different storage backends for the SlikSafe app. Though the current storage backends work pretty well, I'd be happy to connect with the Chia project team.

Do you know anyone in their team? and if so, could you connect me with them? Thank you!


I don't know anyone personally but I know Bram Cohen is the creator and know someone that runs one of the pools.


Hey congrats, the product looks great! Love to see the rise of e2ee tools.

Why did you all decide to go with Storj, a fairly centralized distributed storage aggregator, rather than a decentralized storage network like Filecoin or Sia/Skynet?

Who pays for the storage on Storj? For a tool to be decentralized, the user needs a means to pay a node directly and the ability to seamlessly move between providers, ie interchangeable and zero lock-in. Does Storj allow crypto payments and this type of mobility?

Also noticed the app runs on Firebase/Google, are there plans to move away from this?


Thanks for the great questions!

Reliability, performance, and a scalable infrastructure were strong selling points of Storj for us, and hence, we decided to go with them to provide a more seamless experience in terms of data upload and fetch. We also use Filecoin for immutability of user data, and as another layer of global redundancy.

Currently, we pay for storage/egress to Storj. Users can pay using dollars/crypto on our platform and we convert it to relevant Storj tokens to pay for storage. It is not automated yet, but yes we plan to automate it soon. Also, Storj does accept Storj tokens as payments.

About interchangeability, we plan to provide the migration functionality on our end to users.

We started with Firebase/Google because it was easy to setup. However, our team has been experimenting with different blockchains to sync the different file-ids and file-hashes. This would provide even more dApp developers to develop apps on top of Slik. We have a potential fit, and expect that to be integrated in H1'2022.


Thanks for the reply.

As many other comments suggest, I think it would be great to provide clear documentation to users that they can:

1. Run the entire app themselves, with their own chain/storage nodes etc - its the only way to really guarantee/prove the software is decentralized.

2. Access your data from both any centralized providers (such as yourself) or a local instance, ideally its so transparent you can literally select a different gateway in the app and keep working all within 5 seconds.

This is the bare minimum I would personally require before adopting a "decentralized" software tool.

Looks like you all are taking an incremental approach and not quite there, its a tough problem to solve but I wish you luck!


What I'm getting with Web3 is essentially FileCoin or Sia is like an API layer where Companies (DApps?) can build on top of.

It looks like this may be an existential threat to the current Tech Giants since their data is centralized whereas these new DApps are not.

Looks like they use FileCoin and Storj


Yep, but the important part is that

1. Users pay for their own storage, as directly as possible, otherwise they are not in control.

2. Any centralized APIs are fully interchangeable, ideally you can literally select a different gateway in the app, and keep working all within 5 seconds.


How would Storj be centralized when its node operators have a much lower barrier to entry compared to Filecoin?


Yep I agree, among other things, Filecoin's ridiculous minimum specs definitely reduce the network's decentralization - really not a fan of this.

With Storj I cannot say I have run a node but the first (required) step is literally registering an account and providing all your personal details on the Storj website, if there is an advanced way around this, its not easy to find in the documentation.


This is probably off-topic, but here's what I would love to see: a federated, highly redundant distribution platform where usage requires a contribution of storage. Volume, performance and uptime of that contribution would be rewarded with proportional rights (with respect to available storage, and priority of service).

Can such a distributed solution be developed without requiring a blockchain or the mining of coins?


Yes, it can somewhat be done. The net storage costs could theoretically be tending to zero, but might never be zero because of fill-rate per node and maintaining system reliability.


I saw "password less login" on your homepage, then a smile took over my facial expression. Your product is innovative, that's an advantage over potential competitors with bigger teams and wallets. Another great plus is that you have a walk-through video ready for onboarding new users and visually guiding curious web explorers. Wish you get plenty of success and keep building SlikSafe!


Have you looked at the use cases of small businesses? Dropbox being able to decrypt their files can be problematic in some cases.

The IPFS-based ransomware protection feature seems not quite right in this context. Storing encrypted data in public could be a negative for some as mentioned elsewhere. Instead, users often need to retain an immutable version history which would also provide similar protection.


Who are the targeted users of this? If I want full control of my data, shouldn't I just use a self hosted solution?


I think its supposed to be the off-site backup use case. If you can self-host in a different location you probably dont need it.

On the other hand you can use any other service and encrypt your data first if you just need an off-site backup.


The problem with decentralized as far as what I have used so far, is that you require a whole host of unknown people to donate X amount of storage space to the network.

With IPFS systems I have tried so far you have to struggle to find anyone who has any motivation in storing your stuff for you. Let alone 4 people.

Back in the "good old days" a truly distributed P2P system existed to "exchange" mp3 (all legal of course), and other files. People had incentives to share what they and what they got.

This is still true for some BitTorrent content but it is not very stable most of the time. (People do not seed for long), though there are incentives to seed a lot.

If you dont rely on strangers to store your files and you are paying Digital Ocean S3 or some such it is not really. But sure you can pay multiple providers to store thenm for you.


How does this compare to solutions like git-annex, where multiple 'remotes' can be defined (whether it's dropbox, gdrive, ipfs, etc.) and you can track the availability of a given file across the remotes?


I currently use Keybase for this purpose, and while it's not entirely dead yet (slow-but-present maintenance at https://github.com/keybase/client/issues/24636#issuecomment-...), the writing's been on the wall since Zoom acquihired them. If I can figure out how this works, I'll be happy to give you my money.


Hey Arubis, I was pretty bummed about that acquihire too, but was inspired to build Slik. Please feel free to read through our WhitePaper (https://sliksafe.com/whitepaper.pdf), to learn how the technology works. We've tried to keep it simple and short.

If you have any questions, feel free to reach out at arpit@sliksafe.com. Happy to support your use case.


If you are offering a Web App doesn't that imply that you're storing a set of Encryption Keys? If you are does that not allow you to access any files stored with Slik?


According to their whitepaper the encryption keys stay on the device and can be only recovered with a seed phrase which Slik has no access to, allegedly. There is no source code to verify the details, but they use AES-GCM. That either requires hardware support or a technique called bitslicing to be secure, but it runs on the client, which is fine. The confidentiality of the data however might not be protected because the storage can see the access pattern of the chunks. This is not even theoretical, keyword recovery can be trivial because of a search protocol.


We could definitely expand on the search protocol in our WhitePaper, thanks for the input! However, we provide client side search and not server side search, thus, our servers have no idea of what the user is searching.

The keywords (along with other file metadata) are also encrypted using the user's key, so analyzing access patterns of the chunks, would not be possible for us.


Client-side search is secure if the client downloads all the metadata, and then nothing else based on the result. The access pattern is simply which and how many encrypted chunks are selected. If they are selected based on a search result there could be a statistical correlation.

Not that every leakage is critical, for example if you write chunks when the user uploads a file the client just leaked that an upload happened, it also leaked how much data was written. Depending on the use case this might not lead to sensitive information leakage. It however might, for example if a hospital has an app that let's you download information about your disease an adversary could leak which disease you have without compromising the encryption.

The most advanced technique of hiding which chunks are accessed, or whether they are written or read is called ORAM. ORAM makes chunk accesses indistinguishable, however this technique has a logarithmic overhead, it fails to hide how many chunks are accessed, and it is also hard to design a search protocol on top of it that does not create patterns in the ORAM accesses, which can be also analyzed.

A practical solution is a search protocol that tries to decouple the results from the accesses.

https://www.researchgate.net/publication/356077294_Access_Pa...

This paper is just an idea, I'm designing a different protocol that is more efficient, but requires persistent client cache, which is just becoming a reality for web clients.


> thus, our servers have no idea of what the user is searching.

Until you all are coerced by some legal authority to code a passphrase intercept into the client ala ProtonMail, right?


To explain this in detail -

The encrypted file metadata (and the search indices) are downloaded at once. It is then decrypted using the user's key on device. The user then performs a client side search to get the relevant file-ids. The file-ids are then used to retrieve retrieve the file from the decentralized storage.


Great question - we just keep the encrypting keys on the user's device and in-memory. The keys are encrypted using the user's seed phrase that is only known to the user, and not to Slik.

Feel free to read more implementation details in our WhitePaper - https://sliksafe.com/whitepaper.pdf


How do you prevent yourselves from serving a version of the web app that sends the user’s seed phrase to yourself?

(A malicious employee could do such a thing, or you could be legally obligated to do so in order to continue operating in certain jurisdictions.)


How is this problem specific to web apps?

How do you prevent yourself from serving a compromised iOS/Android/Mac/Windows app? Same answer.


The problem with web apps is that the user doesn't really have any control over updates. With a regular app you can verify a version and stick to it. The web version can change at any point with no notice.

Additionally, a regular app can be signed by a key from the developers that you can verify. With a web app you don't even know if it comes from the developers or if you're being MITM-ed because someone managed to get a SSL certificate for your domain. The certificate isn't the only angle of attack either, your CDN or hosting provider might be hacked. Yes the CDN that hosts the regular app can also be hacked, but that will only work against brand new users, because existing users can already know the signing key and the hacked binary won't have the correct signature.


Well, for traditional Linux desktop apps, the distribution audits the code + ships the binaries.

For app store based distribution, the developers can set up a deterministic build, and end users can verify the checksum of the package matches the developer’s published source code (signal supports this).


So the distribution is the one that alters the code and same issue.


The distribution can alter your browser/kernel/...'s code anyway. So you are not adding a compromise vector by using one more package provided by the distribution, as opposed to getting the package from a third-party.


Isn't this a promise of open source? User doesn't have to get a binary from someone, they could, build from source (given experience+time)


Even for closed source apps, reverse engineering efforts (for sufficiently popular binaries) often find backdoors. This sort of auditing only works because each end user gets the same binary blob. (And if not, there’s a reasonably high likelihood of detection.)


E2E encrypted Dropbox is a Dropbox with EncFS:

https://en.m.wikipedia.org/wiki/EncFS

Also, mega.nz


seems v cool and I hope y'all are successful (although I personally prefer to pay for things with regular $s). After reading the marketing site though I'm unclear on whether decentralized storage in this context is the same as a CDN(content delivery network)?


Thanks for the support pketh! We forgot to mention on our current landing page that you can also pay with $ or your favorite currency using our Stripe integration. We'll update that on our website shortly! :)

We're using Storj and IPFS as the only storage layer behind user data, not as a CDN.


shouldn't this be open sourced?


Syncthing seems provide all the features of Silk and has been around for many years.

The main difference is that it uses your devices for storage and never touches somebody's else storage space.

And you don't have to pay or use cryptocurrencies.


Hey, great points here.

Our focus is on developing a more consumer-friendly solution like Dropbox which has capabilities like search and collaboration so that anyone can privately store their sensitive data :)

Also, we have options to pay in crypto or through credit card.


How are files stored ultimately? Something like Arweave or Filecoin?


We currently use Filecoin and Storj for file storage.


Can the user chose which network their content is stored on? Are you planning to add support for Sia at some point?


Web3 noob here. Is there a guarantee that IPFS and Storj won't go down or delete a file in the next 10 years? How do you ensure that the files are always stored?


Part of the core motivations of ipfs is to make files last forever. The idea is similar to bittorrent (or any p2p file sharing system). There's no guarantee, but it's more likely that a file will be hosted by one of millions of people, over a handful of corporate servers.


This looks amazing dude. Great work. I hope you guys do well.


A big question I have is do you pay per GB of storage, or per GB of uploaded data? That makes a big difference when you're frequently updating your files.


It's pay per GB of storage :)


Any plans for a Linux version? That’s a bit selling point of Dropbox for me as it is one of the few syncing services that have a Linux client.


We are aiming for a Linux launch by end of H1'22


Looks good until I saw it was on IPFS, which isn't 'forever'. How can you guarantee it will be there for lifetime storage?


To ensure lifetime availability of data, we provide redundancy using Filecoin and Storj.


Most important thing with this type of product is the options for account recovery. Anything exist around that?


Thats cool but I am not paying with some digital coin. But good for people who don't have that hang up.


That is sick, gonna play around with it!


Awesome! Looking forward to supporting your use case. Feel free to request any feature, would be excited to integrate it. :)


I'm going to start a start-up to build Decentralized bicycles, and use them for a start-up for Decentralized food delivery, and deliver Decentralized meal kits for Decentralized diet plans. Then I can go to a Decentralized gym and Decentralize my sweat, and later take a Decentralized dump in a Decentralized toilet, look down, and marvel at the wonder of modern technological innovation.


Will there be a Linux version?


This is such a cool demo!


>Pay with Solana for lifetime storage (ten years)

So which one is it then?


Ten years. Which is also the lifetime of something that only lives for ten years. Such as your files in this solution.


What is the difference betweek Slik and SyncThing?


What happens to cp and banned content ?


What happens if I lose my private keys?


Very cool, is it using arweave?


Arweave is not practical, because it is truly immutable and permanent. Updating files is super expensive as all prior copies are kept if I have understood correctly.


We are using FileCoin and Storj for storage. :)


Nice, have you considered making storage free up to a point like web3.storage with filecoin plus?


Yes, to start out, we're providing 2GB of free storage. Beyond that our costs are inclusive of multi-device sync, egress, and storage.


so, it's like syncthing, but closed source and "blockchain!"?


Very cool, congrats on launch-- love the use of IPFS and blockchain here


how's it decentralized if 70% of eth nodes are hosted and their software keeps hard forking(backward incompatible)

you're just relying more middle-man but giving false sense of p2p network to the end-user

no bueno


This is an offtopic comment, as there is nothing about Ethereum here, and this person seems to have a grudge against Ethereum based on his comment history.


why does website says this: Login with your Phantom or MetaMask wallet directly into the app

MetaMask is ethereum non-sense


this is what your profile says: Researching and programming decentralised finance. The code is the law. #defi #solidity #python #vyper #opensource #infosec. Gibraltar

i know what you doing in gibraltar, SEC might be interested to know


[flagged]


Please don't do this here.


For those who might not get the reference: https://news.ycombinator.com/item?id=8863


Lol, you got me there for a second.


Very good.


That's all true, though I suppose the same could be said of Dropbox




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: