Live data from Hacker News

Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

news.ycombinator.com

61–70 of 194 posts

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#63
post #26

Earlier quoted context omitted.

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.

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#64
post #42

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…

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

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#65
post #31

Earlier quoted context omitted.

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 wal…

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

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

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

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#67

Earlier quoted context omitted.

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.

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#68
post #42

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…

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! :)

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#69
post #64
post #42

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…

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.

Re: Show HN: SlikSafe – A decentralized, end-to-end encrypted alternative to Dropbox

#70
post #42

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…

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.

Post reply on HN