Hi,
Going to hop straight to it.
- Centralized signaling servers: are there any plans to integrate signaling in to the core of IPFS and create a distributed signaling mechanism? Centralized, dedicated signal servers are a huge concern of mine with IPFS and one of the reasons I haven’t used it for any serious endeavors. Any plans for onion relay message channels? I’d like to disconnect intent from delivery for messages.
I’ve been thinking about a signal system where each node participates in testing the capabilities of other nodes. In a sense, any node capable of signaling should participate in signaling. If we drop nodes into a DHT it should be possible to signal based on distance from nodes, with some premade peer map distributed classically and further discovery taking place in-system. Of course, there needs to be some entry point, but the entry point is of great concern to me. It is relatively easy to create a small universe of machines to trick nodes to believe they have access to the entire system.
How much thought has been given to discovery of new peers / high-value peers with trusted knowledge of the system? In particular, it’s important for as many people as possible to know as many peers as possible, and to share those peers freely. Are there any chaotic discovery mechanisms planned – ie, there are only ~4 billion ipv4 addresses, any random ip querying for discovery occurring?
- Encrypted relay hopping / onion routing: are there any plans to include nested encrypted messages until it reaches its destination? I’m interested in disconnecting knowledge of what is requested from retrieval of the requested. This is very important in preventing censorship. Considering a keypair is already generated per node for identification, and a list of peers is also generated, it should be relatively trivial to negotiate a sym encryption key with each peer distinct for each onion message channel generated. Say the number of hops is 3-5, each layer of the message just needs to say the “next recipient” with each layer encrypted with the current’s pre-negotiated symmetric key. Each hop would only have knowledge of the next hop and an encrypted payload.
It could also have a “next” address, which is the entry point of a return onion route. Or even better, the message is dropped off encrypted to an exit node 3 hops away, with a pubsub / “DHT neighborhood subscription” message indicating a file is ready for retrieval. So something like:
request, nested encrypt ----> hop-1, decrypt, see relay message for next + encrypted payload ----> h-2 ----> h-n… ----> retrieval node, publishes a request message, retrieves block ----> send message to exit circuit, h1 ----> h2 ----> hn… -----> exit node, publish retrieval id ----> original node can grab it with a unique key.
Or just return the message through the original circuit is prob good enough.
-
True p2p / native UDP based comms (WebRTC): any plans to make this the default for ipfs / a highly supported citizen? The way I see it, it’s important for adoption to make the browser ubiquitous. Turning a browser into a node is very useful for distributed applications. WebAssembly version of IPFS with javascript bindings to negotiate websockets for signaling and WebRTC for udp file / message transfers?
-
Blacklists: very worried about blacklists without the above being done very soon. In a sense, isn’t it a bit irresponsible to release this idea without having those foundations already in place? If authoritative governments get wind that it’s possible to content-address via a digest then how easy does it become to blacklist, and legally force blacklisting? This could very quickly turn into a tool of censorship it it gets widely adopted prior to many more security foundations.
Need to disconnect identity from intent ASAP and flood the system with encrypted traffic.