3 ms·

The long-term idea with Aquameta is that users run their own local database and make connections directly to their friends/peers to basically "git pull" new con

The long-term idea with Aquameta is that users run their own local database and make connections directly to their friends/peers to basically "git pull" new content as it appears via pub/sub. Then users would do the "browsing" on localhost. I still have some work to do figuring out all that NAT piercing p2p stuff, but some combination of WebRTC and headless chrome is showing some promise.

ficklepickle 7y ago
Neat! I was wondering how webRTC fit in. Thanks for sharing, I find outside-the-box stuff like this inspiring.
rancor 7y ago
My favorite NAT-busting mechanism is Tor hidden services, The onion network provides the basic P2P overlay as well, so it keeps life simple. STOMP over WebSockets is cool, and I believe can be implemented without using any Chrome code these days.
- erichanson 7y ago
  Hadn't seen STOMP before, cool. I think making Tor a core part of the architecture is a little over-engineered in our case. The Internet is already a p2p network damnit! I like WebRTC because they seem to solve just the NAT-piercing problem specifically without a whole additional network layer.
  - rancor 7y ago
    I've worked with WebRTC NAT punching pretty extensively, and it is not the solution to your problem. STUN and TURN both require details like proxies with fixed IP addresses, specific DNS and SSL configuration, and so on. So for the nodes to be independent, most users will need to set those services up. So while the added network layer of Tor (or any overlay network really) certainly adds a level of complexity, from the application standpoint it actually simplifies matters for the following reason: Your application doesn't need any longer to think about the topology of the underlying IP network, as this implicit detail dragged in by direct IP connectivity use is abstracted by the overlay network. Instead, your application is able to interface with any peer via (in the case of Tor) an HTTP proxy and a set of opaque base URLs. IOW, you're going to need one or more additional daemons to make the P2P part go, and Tor is legitimately the simplest thing available today that accomplishes this without ruling out other styles of overlay network from an architectural point of view.
    - erichanson 7y ago
      Interesting. I don't mind adding additional daemons to the system if it's essential. But, Tor also (as I understand it, given that this is a ways outside my core competency) adds a whole encryption and anonymization layer, which would be undesirable overhead in at least some scenarios, which is why it seems too heavy to be part of core. Maybe WebRTC isn't going to work reliably which would be very disappointing. I'd like to hear more about your experiences and could really use some help making a good decision here. Ping my email if you're available!
_frkl 7y ago
Not sure if that would work for what you have in mind, but maybe people in the same 'realm' could all be on the same zerotier network (or maybe tinc, or something similar), and you'd have a firewall only letting the pub/sub traffic through that interface. Might be good enough for prototyping, anyway...

ficklepickle 7y ago

Neat! I was wondering how webRTC fit in. Thanks for sharing, I find outside-the-box stuff like this inspiring.

rancor 7y ago

My favorite NAT-busting mechanism is Tor hidden services, The onion network provides the basic P2P overlay as well, so it keeps life simple. STOMP over WebSockets is cool, and I believe can be implemented without using any Chrome code these days.

erichanson 7y ago
Hadn't seen STOMP before, cool. I think making Tor a core part of the architecture is a little over-engineered in our case. The Internet is already a p2p network damnit! I like WebRTC because they seem to solve just the NAT-piercing problem specifically without a whole additional network layer.
- rancor 7y ago
  I've worked with WebRTC NAT punching pretty extensively, and it is not the solution to your problem. STUN and TURN both require details like proxies with fixed IP addresses, specific DNS and SSL configuration, and so on. So for the nodes to be independent, most users will need to set those services up. So while the added network layer of Tor (or any overlay network really) certainly adds a level of complexity, from the application standpoint it actually simplifies matters for the following reason: Your application doesn't need any longer to think about the topology of the underlying IP network, as this implicit detail dragged in by direct IP connectivity use is abstracted by the overlay network. Instead, your application is able to interface with any peer via (in the case of Tor) an HTTP proxy and a set of opaque base URLs. IOW, you're going to need one or more additional daemons to make the P2P part go, and Tor is legitimately the simplest thing available today that accomplishes this without ruling out other styles of overlay network from an architectural point of view.
  - erichanson 7y ago
    Interesting. I don't mind adding additional daemons to the system if it's essential. But, Tor also (as I understand it, given that this is a ways outside my core competency) adds a whole encryption and anonymization layer, which would be undesirable overhead in at least some scenarios, which is why it seems too heavy to be part of core. Maybe WebRTC isn't going to work reliably which would be very disappointing. I'd like to hear more about your experiences and could really use some help making a good decision here. Ping my email if you're available!

_frkl 7y ago

Not sure if that would work for what you have in mind, but maybe people in the same 'realm' could all be on the same zerotier network (or maybe tinc, or something similar), and you'd have a firewall only letting the pub/sub traffic through that interface. Might be good enough for prototyping, anyway...