Hacker News Reader

Comment by dev_throw | Hacker News Reader

I understand that centralized systems are much more efficient than P2P when it comes to high bandwidth communication. But as of today, it would be possible to create a completely decentralized Snapchat (signed ephemeral videos that are shared between two parties). The routing would be the only non-trivial component of this, but it could be solved with a DHT. Why do we continue to trade convenience for privacy? Such a solution would protect from most third parties, including government requests.

As someone without much knowledge of implementing decentralized communication, am I missing some knowledge, or is it solely lack of interest?

View on HN

What happens when one peer doesn't have internet access for a moment and a snapchat is delivered at that moment? How do you build "retries" into a decentralized infrastructure? If no server is storing the content, couldn't someone fill up my phone storage simply by sending me videos repeatedly? The infrastructure forces my phone to instantly download the content, because no one is paying for storage of it before it gets routed to me right?

These are genuine questions because I don't understand everything either

Have the receiving phone send an acknowledgement message back and if the sender's phone doesn't get one after a few seconds, show a "{name} failed to receive your message. Maybe they're offline." dialog. Allow the sender to try again later.

I like this idea and the features being brainstormed in the thread a lot

It wouldn't make sense for your phone to be part of a P2P network. It's only connected to your radio tower, and not really anything else.

Also, you could define a maximum file limit size, and at that point your phone would be considered backed up, and then if no other route is found, the transfer is cancelled after a certain timeout.

>It wouldn't make sense for your phone to be part of a P2P network. It's only connected to your radio tower, and not really anything else.

That is only a software bug.

I’ve been thinking about a Pi Zero W w LoRa acting as a wifi bridge between the smartphone and the Pi and the Pi uses LoRa for the P2P portion.

Well, these days a lot of phones are part of P2P networks such as BitTorrent, so that's not a blocker.

>How do you build "retries" into a decentralized infrastructure?

Heartbeat pings to contact list, cached at senders end until recipient is ready and offer aliased nodes as a feature so multiple devices can act as a RAID array for an identity, both at senders end and recipients.

> What happens when one peer doesn't have internet access for a moment and a snapchat is delivered at that moment?

The video will be on the sender's device until the recipient confirms that they have received a 100%. So this prevents a phone storage clogging situation.

> The infrastructure forces my phone to instantly download the content, because no one is paying for storage of it before it gets routed to me right?

Yeah, that would be accurate. There could be intermediaries that charge low prices to cache snaps for you so you didn't have to download it ASAP, but that would negate the ephemeral nature built into Snapchat)

The users of Snapchat don't know about this so how would they know to stop using it because of it?

One big reason is battery life. I don't want my mobile device to have to rely on the reliability of another party to transmit. If the other party can't receive at the moment, my phone has to do a lot of work to figure that out and periodically retry sending in a graceful fashion. With a server I am guaranteed that as long as my phone has connectivity, my message will eventually be received, and it only takes as much energy as it takes for me to send it to the server.

Fair point. This problem could be alleviated by @InflatableDodo's comment of using other nodes (devices) on the network to cache the video, so even if the sender went offline, another node could make the connection with the recipient when they are both online. Sort of like seeding a torrent, except in this case, the video gets wiped upon confirmed receipt.

Of course, this is more viable if this gains a large network.

You can have e2e encryption and authentication in centralized systems, p2p is not really needed for it. See Signal for example.

> but it could be solved with a DHT

I think that tox is the solution to what you are asking for.

Agreed, I think I made the leap to decentralization primarily for resilience. Tox looks great, I'm gonna try it out, thanks!

> Why do we continue to trade convenience for privacy?

I think there's a big misconception about privacy rights in America. I think a lot of people believe the government is actually allowed to collect otherwise private information, and that it's important they do so. I think this causes people to become complicit in giving away their information because they don't feel they have any choice, which allows people to become willfully ignorant, which makes it easy for the private sector to do the same.

Tldr, the government is setting a precedent where we shouldn't care about our privacy.

Value (valuation) is proportional to cashflows and decentralized systems have decentralized cashflows

most people wouldn't understand or care about the benefits and P2P is inherently more fragile and complex to program than server-client

Reply on news.ycombinator.com