search

minbrowser / min

A fast, minimal browser that protects your privacy
https://minbrowser.org/
Apache License 2.0
7.85k stars 695 forks source link

Add P2P Protocol support #1485

Open RangerMauve opened 3 years ago

RangerMauve commented 3 years ago

Hello, I'm the lead developer of the Agregore Browser which is another minimalist electron browser. 😁

One thing that I've been excited about is using p2p protocols on the web and I was wondering if you'd be interested in a pull request that adds support for the hyper:// and ipfs:// protocols.

This could bring more users to your project from the respective distributed web communities and could lead to interesting use cases with local-first apps that don't rely on central servers/

Milo123459 commented 3 years ago

I don't think that's really the appeal of min and also, wouldn't this be a potential breach of privacy?

RangerMauve commented 3 years ago

@Milo123459 That's fair, thank you for at least looking. 😁

Regarding breach of privacy do you mean IP addresses being exposed to people that are also loading the p2p website? Generally everything gets encrypted on the wire so you usually have privacy from ISPs and third parties.

I understand that putting your IP address on the net can be very unappealing, though.

Milo123459 commented 3 years ago

Yup precisely that and still I don't think it's a particularly good idea just because of security

RangerMauve commented 3 years ago

Sweet, thank you for discussing it! 😁

Milo123459 commented 3 years ago

All good, have a good one!

PalmerAL commented 3 years ago

I don't think I agree with this at least on the security aspect - IPs are basically public information anyway, and there generally isn't much harm in disclosing them. It is possible that having a server running on your computer would increase your attack surface, but there are ways you can mitigate that.

I also think dweb support could enable a lot of really interesting use cases, so it's generally something I'd like to see happen.

The bigger issue, I think, is that there's a basic chicken-and-egg issue with regards to client support and sites using it, that means existing usage is almost zero. I doubt Min's support is going to provide anywhere near the scale needed to overcome that. It also concerns me that there's two competing protocols, since that doubles our maintenance burden and makes it harder to have a clear UX for publishing.

So I'm going to reopen this for now in order to keep discussing it, but I don't think it makes sense to add support at the moment.

RangerMauve commented 3 years ago

The reason Agregore uses multiple protocols is that different protocols have different strengths and weaknesses and I wanted to give application authors more control / avoid falling into a silo.

For example, IPFS is good for CDN-like workflows because content is deduplicated between domains due to it's content-addressible nature. This comes at a performance cost since more data ends up getting advertised on the p2p layer. As well, it's easier to crawl the p2p network and download people's data blindly so unless your data is encrypted it shouldn't have anything remotely sensitive. Lastly, IPFS isn't good for data that mutates quickly or needs versioning - IPNS kinda works but it's still a bit hard to use and can take a while to update / keeping updates available is more effort. You can publish IPNS records from multiple devices, but this can be error prone with race conditions.

On the other side, hyper is good for stuff that mutates and keeps a history since data is grouped within "drives" identified by a public key that's used for verifying content. It also means that you just swarm on the top level discovery key to find peers, reducing network traffic. The p2p layer is a bit more private too since you need to be linked the public key if you want to access the data and you can't scrape for content. However, it doesn't have content addressibility and it doesn't do de-duplication between domains. It also doesn't have support for multiple devices writing to the same key since it's single-writer by default.

I'm currently working on integrating another protocol called earthstar which supports multiple writers being able to update stuff in "workspaces" which get synced either to servers or between peers. It's kinda like leveldb but p2p and multiwriter. However it's better for smaller amounts of data and isn't as good for large files or CDN use cases.

There's other protocols I wanna support in the future, but it's all tradeoffs and there's no one protocol that does everything. Ideally a distributed app would make use of the best bits of different protocols to it's advantage.

What's interesting about the client support is that there's already projects starting to build on these protocols which means the data from them could be used on the web. As well, there's other browsers that have support for these protocols like Brave's IPFS support, Beaker Browser's hyper support, Gateway Browser for mobile hyper support, and Agregore which does a bunch of protocols.

That said, it could also make sense for min to focus on just one protocol that feels most appealing to the devs/community if that'll make the overall messaging easier.

RangerMauve commented 3 years ago

Oh also regarding maintenance, the fetch interfaces that Agregore is using are being used by different projects so there's a collaborative effort to maintain them so it wouldn't all be on the min developers shoulders.