Some of those are honestly pie in the sky, I'll admit. But still seeing a statement that's where resources would be being spent would be ideal for some of those.
With regards to Tor/I2P, It would go a long way to be able to understand that a .onion or .i2p link was clicked and to use an alternate resolver. That would also call for a mode in the browser that sanitizes all user fields and makes the browsers look all exactly the same (to maintain anonymity).
For IPFS, I'd like to see a client-side javascript that handles the peer processing of a node, as well as being able to understand a /ip[n/f]s/hash is an ipfs link. So far, we have resolution via localhost:8080 or ipfs.io/ipfs/hash resolution depending if you're running the peer program or not.
I know that IPFS is actively working on a websockets/client side js for their system, so that any browser can play along, with no noisome downloads or binaries.
And honestly, I didn't know about Servo. I've already enough on my plate, that I didn't need to know about yet another awesome project :)
With regards to Tor/I2P, It would go a long way to be able to understand that a .onion or .i2p link was clicked and to use an alternate resolver. That would also call for a mode in the browser that sanitizes all user fields and makes the browsers look all exactly the same (to maintain anonymity).
For IPFS, I'd like to see a client-side javascript that handles the peer processing of a node, as well as being able to understand a /ip[n/f]s/hash is an ipfs link. So far, we have resolution via localhost:8080 or ipfs.io/ipfs/hash resolution depending if you're running the peer program or not.
I know that IPFS is actively working on a websockets/client side js for their system, so that any browser can play along, with no noisome downloads or binaries.
And honestly, I didn't know about Servo. I've already enough on my plate, that I didn't need to know about yet another awesome project :)