NathanFlurry

I've worked at a few small studios that have shut down games with ~200 CCU peak because the cost/benefit of maintaining the ops for these games was not worth it.

> Another alternative would be spinning off the project: Meta letting it go and allowing team members to leave, take over the rights for a nominal fee of $10,000, and maintain it.

In my experience, studios have a contradictory FOMO mindset of letting other people run the game:

* If someone else makes money off it, they want to be part of it

* At the same time, they don't want to run it themself

* It's not worth the effort to open source it, also see argument #1

What usually ends up happening is the community reverse engineers the protocol and writes their own OSS backend.

Shameless plug: I founded Rivet (W23, https://rivet.gg) to simplify multiplayer game server ops. We talk to a lot of studios with hard-to-manage old games (i.e. 3+ years old can be ancient in gaming). We often help studios move these to our standardized ops so they don't have to worry about it anymore. We also help lower the server cost for old games by auto-scaling their servers based on player demand.

We help developers build and scale multiplayer games (https://rivet.gg). Our backend has a lot of moving parts, so we spend a lot of time dealing with moving secrets around. We recently joined the YC W23 batch and launching an open beta next month. Cheers!

Congrats on the launch!

The first thing that strikes me is the flat organizational structure of secrets. We have at least 45 KV secrets per environment in Vault organized in a directory structure over at Rivet. Managing access policies and organizing these without a directory structure would not be fun.

Either developers are locking their users into Epic/Steam/Apple/PlayStation in exchange for services/users, or they're rolling your own solution with PlayFab/Nakama/Pragma and are stuck footing the bill once their game fades away. Both business models are bad for developers and gamers.

Now for the sameless self plug: we wanted to solve these problems but with a business model that primarily serves developers at Rivet (W23).

Instead, we offer cross-platform console-like services as a REST API for free (friends, parties, leaderboards) and only charge for services that help developers build/grow their games (multiplayer servers, matchmaking, CDN, database). Our #1 priority is providing the best services possible to developers. There's no incentive to rent-seek or lock in your users since we're a services company, not a platform company. Any data your users generate is yours to keep.

Regarding operating legacy multiplayer servers: We plan to let users pay for their own game servers instead of developers fronting the cost. This way, developers can operate legacy games at no cost by letting users "own" their servers and easily enable custom game servers. It's like allowing users to self-host games but without having to open-source your software. Plus, many games can't run as a standalone binary and need the supporting infrastructure.

We're still in closed beta, but there's more info here if you're curious: https://rivet.gg/developer/

Ah, I love seeing new things in this space!

I wrote a much simpler demo back in 2018 using the Apple Pencil + OCR to compile Swift code: https://twitter.com/NathanFlurry/status/980501243377344512

It's essentially just a glorified Swift AST and in no way competes with the efficiency of a traditional keyboard, but 48h of hacking scratched enough of that itch I had to build a VPL.

I’d recommend giving Docker Swarm + Traefik a shot. It’s dead simple to set up manually and has very little “magic” in how things work under the hood. Plus much of your existing Docker Compose config will work out of the box. It vastly simplified the deployment process too.

I previously avoided Docker Swarm for ages since I assumed it involved the same level of complexity as k8s. I also initially figured that managed k8s would be a safer bet than managing my own Swarm cluster, but if you’ve used anybody’s managed k8s (or read https://k8s.af), you’ll realize that every cloud provider has their own closed source fork of k8s with plenty of nasty bugs that you can’t do anything about.

Filecoin is a blockchain which Protocol Labs is using to (a) creating a decentralized way to pay miners to pin your file (i.e. store a permanent copy of your file) and (b) partially used as a funding source for the core project through its ICO.

Beyond that, [here](https://discuss.ipfs.io/t/ipfs-incentives/2456/2) is a good explanation.

To elaborate a bit more: When you set up a node using an unmodified version of their program at the moment, you tell it how much storage to allocate and it will automatically fill the remaining space that you're not using with cached chunks of other peoples' files, essentially "donating" your extra resources. When you fetch a file, your computer will purge the LRU chunks and replace it with that data you just fetched and store that in the cache. This way, the more people who access a file, the more widely distributed that file is cached.

For example, Cloudflare hosts an [IPFS gateway](https://blog.cloudflare.com/distributed-web-gateway/). Since it's in their interest to deliver these files as fast as possible, their nodes which fetched these files from the IPFS network will have them cached and available to anyone else who requests said files. While it's definitely not the same concept in terms of incentive/resource intensiveness/authority, my hope is that IPFS will work well for the same reason things like DNS works effectively. Time will tell on this one.

[This](https://github.com/ipfs/notes/issues/208) summarizes it well. [Related.](https://news.ycombinator.com/item?id=18650670)

TLDR: IPFS acts as a single swarm (i.e. universal deduping) and has more projects like IPNS, IPLD, and Filecoin under its umbrella.

In my opinion, the project is more of an effort to evolve of decentralized technologies to a point where they can be used for mainstream products.

Web 3/Dweb minus the crypto built on IPFS (or something similar).

I believe many developers will soon come to realize that you don't need a blockchain to build most decentralized applications. Products like like Google Docs, social networks, messaging app, etc don't depend on a proof of stake, and we shouldn't be running miners to power such simple operations. All these applications need isa decentralized form of message distribution and log storage paired with public-key cryptography in order to build a CRDT log. I understand why IPFS in itself at first glance often seems over-hyped, since it is essentially just a hyper-distributed caching layer. However, I highly recommend looking at technologies built on top of it like [OrbitDB](https://github.com/orbitdb/orbit-db) and [Textile](https://textile.io/). When they work reliably, their API is as easy if not easier than other "server-less" products like Firebase or Parse to use. Once libraries like these become mature, I believe the way we build software will be flipped on its head within 10-15 years to be completely client focused with minimal backend infrastructure.

The main advantages I see are:

* Increased reliability. This allows developers to remove almost all of their centralized servers and rely instead on a common infrastructure and protocol.

* Much simpler codebases and infrastructure. You only need to write a frontend for most applications. Building on u/searchableguy's comment: I can see no/low code tooling really taking off with decentralized-first applications, since there is no need to manage a complicated backend infrastructure with vendor lock-in.

* Real-time by default. Since IPFS databases run off of CRDT logs which rely on realtime syncing of new operations, they are benefit from immediate updates at all times – even when not connected to the main swarm out in the boonies. * Offline-first by default.

* Cost/resource efficiency. No technology is magical, but [this](https://withblue.ink/2019/03/20/hugo-and-ipfs-how-this-blog-...) article from March is an early real world demonstration of how well this technology works already.

* Transport agnostic. It's completely feasible to have your watch, your phone, and your laptop have their IPFS nodes connected over Bluetooth, but never have to worry about if and how they're connected together since IPFS takes care of handling that P2P connectivity automatically. Instead of writing code that says "my watch created a reminder, upload this to the cloud for my laptop and also tell my phone this happened if we're connected," I can just write "my watch created a reminder, broadcast this operation to the IPFS network" and your phone and laptop will automatically receive this update.

* Security. The less that is stored on centralized servers, the better. While OrbitDB is not built to work off an encrypted database yet (it's in the roadmap for v1), Textile already is. Having everything be encrypted by default and optionally never leaving my device has many advantages.

The main challenges I see blocking this from going mainstream:

* Reliability still feels like the early days of the internet. The database-level libraries are still young, IPFS is slow/unreliable at times, and browser support is fairly strong but still has a way to go, and native mobile/native support is nonexistent.

* Filecoin is not ready yet. You still need to run your own IPFS node/swarm in order to do anything serious. Existing pinning services can only go so far if you're working with something like OrbitDB.

* Education. Security is of upmost important when designing technologies like this, so developers need to understand how a CRDT log works, how to build with merge conflicts in mind, and how to write/manage custom ACL for complex interactions. It also takes a different way of thinking to design networks like this.

* Reliability and security audits.

* Transport protocols. At the moment, many of the advantages of P2P over things like Bluetooth have not been realized yet since the IPFS core is still where most of the development is focused at the moment.

* Cross-platform support. IPFS only has an official Go and JavaScript node implementation with a Rust implementation in the works. While Go has become fairly portable in recent years, it still has a very bloated runtime that doesn't embed well on mobile and web. Once we have a reliable Rust port and some OrbitDB-like Rust-based libraries ports, I suspect we'll start seeing ergonomic mobile and web APIs that bind to these popping up.

To be clear, I'm not saying centralized servers will vanish in to thin air. There are many tasks like indexing large amounts of data that are incredibly difficult and not beneficial to build on a distributed network. The decentralized web – if done right – will make developers' lives much easier for many common applications, but there should not be a need to port things that aren't practical to run on the Dweb.

[Edit: Formatting]

The term "weak types" is incredibly confusing to developers who have used languages that support weak references. I was excited for a second there thinking that "weak types" meant TypeScript would generate code for using a `WeakMap` in order to create weak references, but I guess not.

Yes, I know about Kotlin Native, but it's not quite there yet.

One has structures, ARC, proper extensions, good protocols/interfaces, flexible enums, and runs natively. The other one doesn't. I think I'll choose the former.