[HN Gopher] Spork: Peer-to-peer socket magic in the air
___________________________________________________________________
Spork: Peer-to-peer socket magic in the air
Author : pcr910303
Score : 134 points
Date : 2021-10-19 08:02 UTC (14 hours ago)
(HTM) web link (spork.sh)
(TXT) w3m dump (spork.sh)
| KennyBlanken wrote:
| > Spork is all about creating forward and reverse proxies between
| traditional sockets and p2p sockets.
|
| > Sockets are identified by a public key and connect using a
| Distributed Hash Table (DHT). Connections are end-to-end
| encrypted using the NOISE framework.
|
| Okay, sounds like pretty neat. Is anyone aware of whether Spork
| is undergoing any sort of formal review?
|
| NOISE appears to be popular and well-reviewed, but Spork uses
| noise-peer, a two-contributor project. Spork itself is one-
| contributor.
|
| So...neat sounding, but I'm not using it for anything remotely
| sensitive until it sees more eyeballs. Hopefully a bunch of HNers
| can help with that.
| dandanua wrote:
| > Spork is a part of the Atek Cloud mission to self-host our
| lives. We're channeling the deep magics of the Hypercore
| Protocol. Atek and Spork were built by the same people behind
| Beaker Browser
|
| The guys behind Hypercore Protocol and Beaker Browser are
| building a lot of interesting p2p tools. I suggest starting
| here [1] if you want to understand their stack deeper.
|
| [1] https://hypercore-protocol.org/
| KennyBlanken wrote:
| My understanding of the stack is irrelevant - there's no way
| in hell I will ever be qualified to evaluate it.
|
| I want to see respected, trusted members of the cryptography
| community say at least that noise-peer implements NOISE in a
| secure, proper manner and that spork doesn't weaken or
| improperly use NOISE.
|
| With just two people working on noise-peer and one person
| working on spork, I don't trust it further than I can throw
| it.
|
| Very cool stuff though. Wish the project well and will be
| excited to see where it goes.
| supermatt wrote:
| Any comments on hyperswarm vs libp2p (ipfs)? Why would I choose
| one over the other.
| pfraze wrote:
| Libp2p is technically a framework so you could probably
| integrate hyperswarm into it. Hyperswarm's new release has
| gotten some really focused effort to improve the DHT success
| rate. That's the part I'm most interested to see play out
| red0point wrote:
| This is very cool, but it seems extraordinarily cumbersome to
| pass on the generated super long string to another computer or
| mobile device.
| OJFord wrote:
| I'm not sure about 'extraordinarily cumbersome', just copy-
| paste through Slack or whatever? Surely most use cases are
| between people, not just between (one person's) devices?
|
| An improvement could be to reversibly derive a few random words
| ('what 3 words' style) from the public key I suppose - so that
| it can be easily shared over a voice call, or to make it easier
| for the same person to enter on another device.
| KennyBlanken wrote:
| There's a (mostly) serverless file transfer tool whose name
| escapes me at the moment that uses this method to exchange
| the actual keys for the secure transfer...but it works there
| because the connection is only available for initiation, for
| that specific host and port, for a pretty limited period of
| time. The key is also one-use.
|
| In this case the 'server' is up for an extended period of
| time, presumably, and the public key is both the address _and
| authentication_ (unless you turn on requiring a specific key
| on the initiator, I think? I only glanced at the docs.)
|
| With enough nodes you'd end up with multiple nodes having the
| same words (divide the possible keyspace by the possible
| combination of words and you'll get a _very_ large number),
| and also you 'd be at significant risk of people finding
| nodes just by banging away trying to connect to different
| 3-word addresses.
|
| I agree that the tool seems to be intended for same-party
| use.
| pfraze wrote:
| Magic Wormhole is probably what you're thinking of. The
| live handshake requirement is definitely a limiting factor
| on that approach, but probably still worth doing. Other
| options would be QR codes and registry services.
|
| The protocol team is looking at using the ristretto
| algorithms to derive "subdomains" which would reduce the
| amount of key sharing a fair bit
| criddell wrote:
| Are you talking about AirDrop?
| gauchojs wrote:
| Yeah - this could work for more people if they had a small app
| that opened "Spork urls"
| spork://whattzzuu5drxwdwi6xbijjf7yt56l5adzht7j7kjvfped7amova
| api wrote:
| One question that always comes up for me with DHT backed systems
| is resistance to DOS attacks. Making any P2P system resistant to
| DOS/DDOS is brutally difficult, but DHTs have always seemed
| especially vulnerable to a sophisticated attacker. A hybrid
| sybil/DDOS attack seems like it could down the network easily.
|
| The Internet is a dark forest. Anything that gets popular will be
| attacked. The fact that it does not have a single owner may
| reduce the chances of ransom as a motive, but it doesn't reduce
| the chances of all attacker profiles including just "griefing."
| Tepix wrote:
| So is there a tool that makes it easy to look up the IP
| address(es) behind a public key? If not it should be trivial to
| code it, right?
| ianopolous wrote:
| This is similar to p2p streams in IPFS. We've been using these in
| Peergos for 3 years now via the p2p http proxy in IPFS (which we
| contributed). It is a glorious model. The client, in our case
| Peergos, sends normal http requests to a localhost proxy URL that
| includes the target public key and voila! We wrote it up after
| developing it here: https://peergos.org/posts/dev-update
|
| The underlying streams use TLS 1.3 as the transport encryption.
|
| And we've just written a super minimal ipfs replacement (for
| ourselves) which includes this: https://github.com/peergos/ipfs-
| nucleus/
| exporectomy wrote:
| I'm confused how the client/local proxy finds the rest of the
| distributed hash table to do its lookup in. Are there some fixed
| conventional internet addresses it can start from or something?
| rytill wrote:
| Are there configurable reliability settings, or is it TCP-only?
| MayeulC wrote:
| See also: yggdrasil/cjdns/hyperbora that also provide p2p routing
| in a mesh network (without DHT), but also map public keys to an
| unused chunk of IPv6.
|
| IPFS p2p is more similar to that project, with a DHT, though I am
| not sure about encryption.
|
| To me, this is the future. I wish we had a set of APIs to allow
| connecting to a public key instead of an IP adress... however
| that requires reinventing most of the network stack (subnets,
| etc). That could be a base for IPv7. As a bonus, this could run
| on top of IPv4 or IPv6.
|
| Creating ephemeral, E2EE addresses has a lot of nice properties:
| you can roam with the same address (making it easy to move a
| server around, even behind cellular internet). Browsers could use
| a different key for each site. Sites could use that as a session
| identifier to authenticate against.
| white-flame wrote:
| I use onion addresses to have basically a hash-addressable
| socket on the internet, which can be relocated without any
| additional configuration. It can even work without any inbound
| ports on the firewall.
|
| However, I haven't done any serious roaming with such a
| configuration; has anybody tried it?
| brendoncarroll wrote:
| > To me, this is the future. I wish we had a set of APIs to
| allow connecting to a public key instead of an IP address
|
| INET256 is working on exactly that. It's a set of APIs for
| connecting to addresses derived from public keys.
|
| https://github.com/inet256/inet256
| MayeulC wrote:
| Thanks for mentioning this, it's the first time I hear about
| that project, and will definitely have a look!
| ahnick wrote:
| So basically urbit without all the weirdness?
| neilalexander wrote:
| > you can roam with the same address (making it easy to move a
| server around, even behind cellular internet)
|
| In particular, Yggdrasil's mobility performance is far better
| than anything provided by the likes of BATMAN-Adv, Babel etc,
| making it ideal for roaming users and ad-hoc/mesh networks.
| https://yggdrasil-network.github.io/assets/images/latest/mob...
| collegeburner wrote:
| Interesting, how is Ygdrassil performance against Tailscale
| or Zerotier?
| MayeulC wrote:
| I haven't used either, but one of the catches with
| yggdrasil is that you have to peer manually over the
| Internet. On the other hand, you could install it on every
| router on a network, and everything would work
| automatically.
|
| There are some higher-level tools that can manage your
| peerings, but at that point, yggdrasil just offers a unique
| IPv6, derived from your crypto key, and end-to-end
| encryption, both of which can more or less be achieved with
| wireguard alone.
| lifty wrote:
| I think lately they use wireguard as well, so it should be
| comparable to Tailscale.
| dsr_ wrote:
| Let me recommend two more features:
|
| - universal human-assignable names As long as
| you're replacing IPs, replace DNS, too. When you tell a friend
| about this great new site, make sure you can tell them with
| something closer to "pasciencia y fe" than
| "fe88-2533-a210-dead-b33f-3301-3412-4dc1"
|
| - universal anycast Big services will need
| scale and distribution; if it's built in early and well, that
| makes it easier to adopt.
| lijogdfljk wrote:
| > universal human-assignable names
|
| Any implementations of this you'd recommend? I write a lot of
| hash (content addressable/etc) code in my spare time and i'd
| be curious to toy with identifiers (256bit hashes) being
| provided to humans in human-friendly ways.
| RL_Quine wrote:
| You might like bech32, which encodes data (nominally
| hashes) into strings which include error detection and
| error correction, while being optimized for human use and
| typing by avoiding homogylphs and capitalization.
|
| https://en.bitcoin.it/wiki/Bech32
| redleader55 wrote:
| The first thing that pops in my mind is choosing a
| dictionary of 2^n words and making an identifier that maps
| the 256 bit hash space to a k-tuple of words, where k =
| 256/n.
| djbusby wrote:
| Like this? https://github.com/singpolyma/mnemonicode
| MayeulC wrote:
| While I agree with the second, this is an implementation
| "detail" of the routing layer. Universal multicast is much
| more interesting as an usage, though I am not sure about the
| feasibility.
|
| As far as human-assignable names go, I am not sure. "pet
| names" would be a good fit: you "pin" a service using your
| name or someone else's.
|
| Sure, you can also use a ready-made mapping from words to
| binary like https://what3words.com/inferior.chapels.nerve for
| instance, but I feel like picking one is a separate endeavor
| with its own pitfalls (not everyone speaks English, etc).
|
| You're asking for a solution to Zooko's triangle:
| https://en.wikipedia.org/wiki/Zooko's_triangle
| dsr_ wrote:
| I'm willing to throw away "decentralized" in the "DNS is
| centralized" sense in order to have a meaningful alias
| system. If I can't talk about a service in normal
| conversation, it will be difficult for me to tell people
| about it.
|
| "You should check out correct horse battery staple" vs "You
| should check out news.ycombinator.com" -- one of those
| requires me to maintain a meaningless mapping in my head,
| and the other contains structure and clues even if it isn't
| "Hacker News".
| MayeulC wrote:
| If that's the case though, why not keep DNS for now,
| especially for the initial handshake?
|
| Then, similar to HSTS, the browser could remember the
| mapping and use the DNS name as a pet name for the
| target.
|
| Another alternative would be to use "phonebooks". One
| could trust a few trusted websites for the initial
| handshake: "oh, just google _battery horse_ to find my
| blog ". Or: I'm linked on John's blog. That goes well
| with pet names, but is a bit more involved.
|
| In any case, as long as the underlying identifier is
| secure and unique, you can just share that trough other
| means (links, Qr codes, messages, etc).
| munro wrote:
| I love this idea of pub keys for connecting to sockets. I
| wish we could standardize on something, yggdrasil looks very
| interesting as well.
|
| > - universal human-assignable names
|
| Seems like if we wanted to add human names, DNS would work
| just fine--it could just be a new record. And IDK if there
| really is a better way to manage multiple people wanting the
| same names, other than our existing system. These systems can
| remain orthogonal too. dig SPORK
| news.ycombinator.com
|
| or maybe :) dig YGGDRASIL
| news.ycombinator.com
| [deleted]
| notum wrote:
| Looks cool and simple to use, now can someone please explain to
| me why this matters?
|
| What centralized system does Spork remedy? It bypasses DNS? Is
| there any sort of discovery and/or replication and/or redundancy?
| pfraze wrote:
| The goal is to create an Internet of home servers. You want to
| have your own NAS or rpi you deploy apps on. The p2p turns
| those devices into a network
| marcodiego wrote:
| This is good but, in terms of requiring special software on both
| sides, it is no better than tor which allows you to expose a
| service even behind NAT.
|
| Anyone knows a similar service which do not needs special
| software on the client side?
| pfraze wrote:
| Yeah that's a basic problem of the approach. I'm going to
| create a public gateway service for spork (similar to IPFS
| gateways). You lose the end-to-end encryption by using a
| gateway, but then only the serving user needs to have spork
| installed. I figure that can help with asymmetric adoption.
|
| Long-term, the Hyperswarm & Hypercore stacks will need to have
| whatever apps/browser-extensions available, and then the
| featureset will hopefully be compelling enough to make them
| worth an install. Spork isn't the end-point.
| pfraze wrote:
| Hey all, I'm the author of spork. Just want to give credit to the
| Hypercore Protocol team as they're responsible for 99% of this
| tool. They're going to be speaking at NodeConf on Wednesday so
| check that out if you're interested [1]
|
| 1. https://www.nodeconfremote.com/#workshops/how-to-
| build-p2p-a...
| metadaemon wrote:
| How did you find the implementation of the Noise protocol to
| be? I've looked at it in the past as an alternative to SSL.
| pfraze wrote:
| This is where I have to again point to the Hypercore Protocol
| team, as they're the ones that implemented it. I bet you
| could ask in the #hyperswarm channel of their discord
| https://chat.hypercore-protocol.org/
| pfraze wrote:
| A couple fun things I haven't documented yet.
|
| We were able to spork an SSH session using password auth. (That
| one went from Texas to Virginia via Starlink.)
|
| Some folks on the discord sporked a Minecraft game. Quake
| didn't spork, probably because it uses UDP which doesn't spork
| yet.
|
| We're going to keep adding fun/useful features, including a
| public gateway service so folks can make use of spork without
| people having to install the client first.
___________________________________________________________________
(page generated 2021-10-19 23:01 UTC)