[HN Gopher] Show HN: SlikSafe - A decentralized, end-to-end encr...
___________________________________________________________________
Show HN: SlikSafe - A decentralized, end-to-end encrypted
alternative to Dropbox
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
Author : arpitagarwal
Score : 224 points
Date : 2021-12-21 13:33 UTC (9 hours ago)
| seltzered_ wrote:
| 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?
| no_time wrote:
| >Pay with Solana for lifetime storage (ten years)
|
| So which one is it then?
| daqhris wrote:
| 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!
| akvadrako wrote:
| 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"
| arpitagarwal wrote:
| 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!
| mNovak wrote:
| 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 naive
| e2ee cloudstore by e.g. putting an encrypted volume on
| dropbox.
| smoldesu wrote:
| Are you looking for Syncthing? https://syncthing.net/
| willis936 wrote:
| I am looking for syncthing but with an iOS app.
| dividuum wrote:
| There's https://www.mobiussync.com/
| derbOac wrote:
| Has iOS just not been implemented yet or is there a
| technical hurdle?
| anderspitman wrote:
| 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.
| hagbard_c wrote:
| 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...
| anderspitman wrote:
| 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-...
| akvadrako wrote:
| Syncthing doesn't do smart sync. The library of stuff I want
| available is larger than can fit on my phone.
| Joeri wrote:
| I have multiple top-level syncthing folders to work around
| that. Different machines get different sets of folders.
| t0astbread wrote:
| 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.)
| spicybright wrote:
| 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)
| akvadrako wrote:
| 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.
| howdydoo wrote:
| 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.
| rhamzeh wrote:
| 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
| howdydoo wrote:
| 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.
| hagbard_c wrote:
| 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
| akvadrako wrote:
| Nextcloud syncing is terrible because it's based on WebDAV.
| It's slow, especially with lots of files. And it's not
| reliable.
| hagbard_c wrote:
| 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?
| [deleted]
| coolspot wrote:
| E2E encrypted Dropbox is a Dropbox with EncFS:
|
| https://en.m.wikipedia.org/wiki/EncFS
|
| Also, mega.nz
| neximo64 wrote:
| Looks good until I saw it was on IPFS, which isn't 'forever'. How
| can you guarantee it will be there for lifetime storage?
| arpitagarwal wrote:
| To ensure lifetime availability of data, we provide redundancy
| using Filecoin and Storj.
| olah_1 wrote:
| Most important thing with this type of product is the options for
| account recovery. Anything exist around that?
| aarondevera wrote:
| Very cool, congrats on launch-- love the use of IPFS and
| blockchain here
| temp8964 wrote:
| Who are the targeted users of this? If I want full control of my
| data, shouldn't I just use a self hosted solution?
| noxer wrote:
| 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.
| jeroenhd wrote:
| 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?
| nijave wrote:
| 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
| newman314 wrote:
| 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).
| rspoerri wrote:
| syncthing
| XorNot wrote:
| 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.
| apetrovic wrote:
| 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.
| aborsy wrote:
| What's wrong with Synology Drive?
|
| It's working just fine for me.
| Joeri wrote:
| 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.
| deluxeroyale wrote:
| 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.
| Arubis wrote:
| 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.
| arpitagarwal wrote:
| 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.
| mmastrac wrote:
| 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.
| guico wrote:
| 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
| spicybright wrote:
| 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.
| gtsop wrote:
| 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
| api wrote:
| 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.
| pcthrowaway wrote:
| 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
| api wrote:
| 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.
| arpitagarwal wrote:
| 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! :)
| djrogers wrote:
| > 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?
| snappythrowaway wrote:
| - Switch over from centralized storage to decentralized
| storage [completed],
|
| kind of looks like they are already there?
| breakfastduck wrote:
| 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.
| alkonaut wrote:
| > 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?
| gtsop wrote:
| Thanks for the detail, yes now I really look forward to that
| :)
| arpitagarwal wrote:
| super! :)
| EVa5I7bHFq9mnYK wrote:
| 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.
| tata71 wrote:
| Distributed. Federated.
| austincheney wrote:
| 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.
| sam0x17 wrote:
| 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.
| [deleted]
| systemvoltage wrote:
| Isn't git decentralized?
| exdsq wrote:
| 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.
| systemvoltage wrote:
| 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.
| glutamate wrote:
| Interesting that when given a choice, people choose
| centralised over decentralised.
| volkk wrote:
| 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.
| stavros wrote:
| 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.
| miohtama wrote:
| Sqlite
|
| https://www.sqlite.org/whynotgit.html
| cle wrote:
| Decentralized in this case means you don't trust a single
| entity to control your access to your data.
| gtsop wrote:
| 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
| LinuxBender wrote:
| 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.
| [deleted]
| no_circuit wrote:
| 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
| arpitagarwal wrote:
| 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.
| cab404 wrote:
| so, it's like syncthing, but closed source and "blockchain!"?
| trompetenaccoun wrote:
| 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.
| arpitagarwal wrote:
| 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! :)
| [deleted]
| aloukissas wrote:
| 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.
| arpitagarwal wrote:
| Looking forward to your feedback!
| beedrillzzzzz wrote:
| 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?
| antoniuschan99 wrote:
| 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
| beedrillzzzzz wrote:
| 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.
| dreadlordbone wrote:
| How would Storj be centralized when its node operators have a
| much lower barrier to entry compared to Filecoin?
| beedrillzzzzz wrote:
| 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.
| arpitagarwal wrote:
| 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.
| beedrillzzzzz wrote:
| 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!
| mmmmkay wrote:
| shouldn't this be open sourced?
| _1tan wrote:
| That is sick, gonna play around with it!
| arpitagarwal wrote:
| Awesome! Looking forward to supporting your use case. Feel free
| to request any feature, would be excited to integrate it. :)
| applgo443 wrote:
| This is such a cool demo!
| pharmakom wrote:
| What happens if I lose my private keys?
| cookiengineer wrote:
| 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.
| edf13 wrote:
| 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.
| detaro wrote:
| > _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...)
| cdnsteve wrote:
| 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.
| arpitagarwal wrote:
| 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!
| pketh wrote:
| 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)?
| arpitagarwal wrote:
| 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.
| cabalamat wrote:
| Will there be a Linux version?
| jsight wrote:
| 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.
| Saris wrote:
| Yes, that's one reason I'm really not sold on storing private
| data on IPFS and similar services.
| [deleted]
| mrharrison wrote:
| You can unpin it, and it will eventually be removed from other
| non pinned sources.
| sodality2 wrote:
| >it will eventually be removed from other non pinned sources
|
| Hopefully, though, they unpin it.
| exo762 wrote:
| 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.
| bananabernhard wrote:
| 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.
| sam0x17 wrote:
| Yeah there's actually powerpoints from the snowden leaks
| showing how much they ingest per month and how much of that
| they keep, etc.
| trompetenaccoun wrote:
| So how much do they keep?
| exdsq wrote:
| 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
| norswap wrote:
| How are files stored ultimately? Something like Arweave or
| Filecoin?
| charvimittal wrote:
| We currently use Filecoin and Storj for file storage.
| thesausageking wrote:
| Can the user chose which network their content is stored on?
| Are you planning to add support for Sia at some point?
| gregwebs wrote:
| 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.
| rdbell wrote:
| This looks amazing dude. Great work. I hope you guys do well.
| ketzu wrote:
| 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)!
| arpitagarwal wrote:
| > 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.
| turrini wrote:
| moralestapia wrote:
| Lol, you got me there for a second.
| noahtallen wrote:
| For those who might not get the reference:
| https://news.ycombinator.com/item?id=8863
| teluride5 wrote:
| That's all true, though I suppose the same could be said of
| Dropbox
| NoGravitas wrote:
| jalada wrote:
| Very good.
| 0xbadcafebee wrote:
| 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.
| woofcat wrote:
| 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?
| arpitagarwal wrote:
| 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
| hedora wrote:
| 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.)
| spiderice wrote:
| How is this problem specific to web apps?
|
| How do you prevent yourself from serving a compromised
| iOS/Android/Mac/Windows app? Same answer.
| hedora wrote:
| 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).
| sroussey wrote:
| So the distribution is the one that alters the code and
| same issue.
| progval wrote:
| 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.
| edoceo wrote:
| 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)
| hedora wrote:
| 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.)
| [deleted]
| Strom wrote:
| 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.
| Comevius wrote:
| 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.
| arpitagarwal wrote:
| 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.
| Comevius wrote:
| 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_P
| a...
|
| 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.
| CodeWriter23 wrote:
| > 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?
| arpitagarwal wrote:
| 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.
| clircle wrote:
| What is the difference betweek Slik and SyncThing?
| whoisninja wrote:
| 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
| miohtama wrote:
| 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.
| whoisninja wrote:
| why does website says this: Login with your Phantom or
| MetaMask wallet directly into the app
|
| MetaMask is ethereum non-sense
| whoisninja wrote:
| 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
| throwaway02394 wrote:
| 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.
| Comevius wrote:
| 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.
| arpitagarwal wrote:
| 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! ;)
| billpg wrote:
| I don't need that. I can just set up an SFTP server and rsync my
| files to it.
| LikeAnElephant wrote:
| There's the standard Hacker News response I was looking for
| baggachipz wrote:
| You can almost set your watch to it.
| wussboy wrote:
| I don't need that. I rsync my watch with nist.gov
| yupyup54133 wrote:
| > 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.
| nathias wrote:
| Very cool, is it using arweave?
| miohtama wrote:
| 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.
| charvimittal wrote:
| We are using FileCoin and Storj for storage. :)
| nathias wrote:
| Nice, have you considered making storage free up to a point
| like web3.storage with filecoin plus?
| arpitagarwal wrote:
| Yes, to start out, we're providing 2GB of free storage.
| Beyond that our costs are inclusive of multi-device sync,
| egress, and storage.
| purpleidea wrote:
| 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.
| goodpoint wrote:
| 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.
| charvimittal wrote:
| 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.
___________________________________________________________________
(page generated 2021-12-21 23:00 UTC)