Minor clarifications, but libp2p also uses TLS ALPN for protocol negotiation, and also uses native quic streams - there is no additional muxer layer when using quic.
@lxpz It would be great to do a follow up to this blog post with the latest Peergos. All the issues with baseline bandwidth and requests have gone away, even with federation on. The baseline is now 0, and even many locally initiated requests will be served directly from a Peergos cache without touching S3.
You might be interested in Peergos [0][1] (creator here) which has official Linux apps, is E2EE, fully open source (including the server), and self-hostable. It's also recommended by privacy guides: https://www.privacyguides.org/en/cloud/#peergos
You might be interested in Peergos [0][1] which is E2EE, fully open source (including the server), and self hostable. We've been audited by Cure53 and Radically Open Security.
At the moment if your client accesses a server with a mirror, and your primary is offline, then you can read, but not write. Writes are proxied to your primary, and thus need your primary to be accessible.
Yes your files stay on your server, unless you share them with a friend on another server. It basically just uses libp2p as an internode communication protocol, and you need auth to retrieve ciphertext blocks.
The good news is Peergos also has serializable transactional modifications. This comes from us storing signed roots in a db on your home server (not ipns). We also have our own minimal ipfs implementation that uses 1000x fewer resources than kubo, aka go-ipfs.
You're absolutely right. We need a big push on marketing and PR (Peergos founder here). We are self, grant and customer funded and a not-for-profit so we necessarily need to grow more slowly than a VC backed company, but that lets us keep our incentives aligned with our users. Our aim is absolutely ease of use, there shouldn't be a usability tradeoff for privacy in our view. We do already have some very non-technical users who love it.
Yep, if that's possible for your service that works. If the service doesn't want your email and/or doesn't have access to your data, e.g. an E2EE service where account reset is impossible, then that's not an option.
The supposition for all this is that the service wants to use passwords for whatever reason. In that case, generate them for the user.
People should absolutely be using password managers where possible.
A website doesn't have control over whether you are using a password manager though. This is about stopping the human from generating a password themselves, which will be terrible.
Humans shouldn't generate passwords. ~0 people are good at that. Websites should just generate a password for a user, letting them regenerate as many times as they like until they get one they like (without breaking password manager based generation). A bit like this: https://peergos-demo.net/?signup=true
Iroh is still awesome.