[shawn]

Yes! This is an important point, and I completely agree that decentralization is the main driving force here, not necessarily blockchains. Blockchains are a nice fallback mechanism to enforce trust, but Bittorrent proves that you can have happy ecosystems that work just fine without it.

The corollary is that I'm most interested in services that are focusing on decentralization, not merely trying to be a general purpose blockchain. One of the most important unsolved problems seems to be "I want to put this file up on the internet, but I don't want it to be taken down," plus "I want to request this file, but I don't want it to be traceable back to me," plus "I want to distribute this file, but I don't want it traceable back to me." Tor solves some of these concerns, but it remains a specialized niche. I can't just do it for any old file at any time; might as well use Dropbox for that. And why? There's no reason. It should all just be decentralized. After all, I'm online most of the time, and I'd happily upload the file to whoever wants it.

This all sounds quite shady, but the motives here are mostly pure: I'd like to distribute old ROMs and anime. Such things will get you kicked offline just as quickly as the more nefarious stuff. But this seems like a net negative for society. Society is at its healthiest when you're free to remix other people's ideas.

(More specifically, I want to write a service that lets you play whatever old ROM you want, whenever you want. There still is no Netflix of this area, and the game companies that could make it happen seem too inept. May as well force their hand with some decentralization. But that requires being able to write the equivalent of <img src="http://foo.com/img.jpg">, but for distributed binaries keyed by sha256. Blockchain could help here, but I look at this and go "Y'know, this is a perfect decentralization problem. Why aren't blockchains solving it already?")

[Karrot_Kream]

You can already put ROMs on IPFS, and if you use a JS Emulator and point it at a ROM in IPFS, well there you go.

[shawn]

Good idea; I tried that. Unfortunately IPFS doesn't yet seem reliable. Or at least I couldn't get it to work very well. I'll try again though.

Wanna collab? Shoot me an email and we can work it out. I'm really interested in getting this concept running. If only IPFS were low latency and easy for average gamers to upload files to, that seems a perfect fit.

I was hoping that as users play games, they would also upload the games to other people who want to play. That way there's no scarcity of server resources. You could fit ~40 n64 games into 1GB, so it's not a lot of bandwidth.

[Karrot_Kream]

IPFS definitely has high latency, but you might be able to combine this with the Web Storage API [1] to compress and then store the ROM data for local use. I'd be interested in a collab, is your email in your profile?

1: https://developer.mozilla.org/en-US/docs/Web/API/Storage

[shawn]

Yeah! We're thinking along the same lines. I think with a bit of work, libretro can be modified to do it: https://github.com/libretro/parallel-n64

It's already been ported to the web. https://medium.com/webmr/n64-vr-with-javascript-e188de42ced5

The trouble is performance. N64 emulation is all software rasterization based, but it can be rewritten to use WebGL. It's just a lot of work that no one's done yet. RetroArch runs at 40fps because it can use SSE ops, which is beyond what browsers can do currently.

I think it would be possible to ship an Electron app with a local build of Retroarch, modified to export the rom's game data and selectively replace the draw calls with other ones. That way you can basically swap out starfox with mario, if you wanted. If any of this sounds interesting, shoot me an email (see profile).