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.
|
|
|
|
> 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...
|
|
|
|
Interesting, how is Ygdrassil performance against Tailscale or Zerotier?
|
|
|
|
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.
|
|
|
|
I think lately they use wireguard as well, so it should be comparable to Tailscale.
|
|
|
|
> 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 addressINET256 is working on exactly that. It's a set of APIs for connecting to addresses derived from public keys. https://github.com/inet256/inet256
|
|
|
|
Thanks for mentioning this, it's the first time I hear about that project, and will definitely have a look!
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
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".
|
|
|
|
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).
|
|
|
|
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
|
|
|
|
> universal human-assignable namesAny 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.
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
So basically urbit without all the weirdness?
|
|
|
|
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?
|
|
|
|
kind of a weird idea but routers have names, i always wondered if there was some way we can use this as addresses to give a position of sorts, that way, nearby host can direct traffic towards a location. like a pass off, idk if i am explaining it right
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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/
|
|
|
|
> 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.
|
|
|
|
> 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 BrowserThe 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/
|
|
|
|
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.
|
|
|
|
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-updateThe 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/
|
|
|
|
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."
|
|
|
|
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?
|
|
|
|
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
|
|
|
|
This is very cool, but it seems extraordinarily cumbersome to pass on the generated super long string to another computer or mobile device.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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
|
|
|
|
Are you talking about AirDrop?
|
|
|
|
Yeah - this could work for more people if they had a small app that opened "Spork urls" spork://whattzzuu5drxwdwi6xbijjf7yt56l5adzht7j7kjvfped7amova
|
|
|
|
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?
|
|
|
|
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.
|
|
|
|
Any comments on hyperswarm vs libp2p (ipfs)? Why would I choose one over the other.
|
|
|
|
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
|
|
|
|
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?
|
|
|
|
Are there configurable reliability settings, or is it TCP-only?
|
|
|
|
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?
|
|
|
|
Had the same questions. The homepage and demo don’t explain in layman’s words how this works. How does the hash get generated and how does it find the target from the hash? Are there servers online that do this?
|
|
|
|
As for how the hashing works, that's more an implementation detail, isn't it? How it finds the target is what the DHT tech does. But I have to say the home page and example was incredibly clear! For such an abstract thing, it was truly about as perfect at communicating what it is as I could imagine!
|
|
