5 ms·

I want many more Local-Only apps, thanks. Self-Hosted. Or Federated apps, again Self-Hosted. And I think network infrastructure has been holding us back horr

I want many more Local-Only apps, thanks. Self-Hosted. Or Federated apps, again Self-Hosted. And I think network infrastructure has been holding us back horribly. I think with something like Tailscale, we can make local-only apps or federated apps way, way easier to write.

hasanhaja 1y ago
I've been having fun exploring this actually: https://news.ycombinator.com/item?id=45333494 https://news.ycombinator.com/item?id=45333494 I've found it to be a fun way to build apps.
michaelsalim 1y ago
Agreed. I'm building a presentation software[1] so it needs to work locally (can't afford lost of connection). But I also want it to be accessible from anywhere. Unfortunately those two things don't mesh that easily. The tech is getting there though. With things like hole punching or webrtc, P2P is getting pretty easy to implement. Though it's still a challenge to implement it in an actual project. I do believe that we're going to start seeing quality local-first software w/ great networking pop up more and more soon. I'm working on that, but I'm sure there are plenty others who are doing the same. [1] Open-source, see my profile for info
- VikingCoder 1y ago
  Really, why not use Tailscale?
  - michaelsalim 1y ago
    Never said you shouldn't. Tailscale uses a bunch of different techniques including hole punching for it to work. If that's what you need, go ahead. I opted for Iroh for a few different reasons but Tailscale is an awesome choice too.
ChadNauseam 1y ago
To me, writing a local-first app using CRDTs is the only way I ever want to build apps from now on. It's by far the most fun approach I've found. And here's why: the CRDTs I work with require you to maintain an event log, AKA a complete history of everything that's happened which you then replay to compute the current state. This allows events from other devices to be inserted at their proper chronological point in the stream, so that when you replay everything you get the correct current state with that event included. In practice, it has an unexpected benefit. Whenever I hit a decision point where I'm not totally sure how something should behave, I can just ship it anyway without stressing about it. Later on, I can retroactively change how that action works by updating the function that processes events into state changes. It's hard to convey just how liberating this is, but trust me, this situation comes up way more often than you'd expect.

hasanhaja 1y ago

I've been having fun exploring this actually: https://news.ycombinator.com/item?id=45333494 https://news.ycombinator.com/item?id=45333494 I've found it to be a fun way to build apps.

michaelsalim 1y ago

Agreed. I'm building a presentation software[1] so it needs to work locally (can't afford lost of connection). But I also want it to be accessible from anywhere. Unfortunately those two things don't mesh that easily. The tech is getting there though. With things like hole punching or webrtc, P2P is getting pretty easy to implement. Though it's still a challenge to implement it in an actual project. I do believe that we're going to start seeing quality local-first software w/ great networking pop up more and more soon. I'm working on that, but I'm sure there are plenty others who are doing the same. [1] Open-source, see my profile for info

VikingCoder 1y ago
Really, why not use Tailscale?
- michaelsalim 1y ago
  Never said you shouldn't. Tailscale uses a bunch of different techniques including hole punching for it to work. If that's what you need, go ahead. I opted for Iroh for a few different reasons but Tailscale is an awesome choice too.

ChadNauseam 1y ago

To me, writing a local-first app using CRDTs is the only way I ever want to build apps from now on. It's by far the most fun approach I've found. And here's why: the CRDTs I work with require you to maintain an event log, AKA a complete history of everything that's happened which you then replay to compute the current state. This allows events from other devices to be inserted at their proper chronological point in the stream, so that when you replay everything you get the correct current state with that event included. In practice, it has an unexpected benefit. Whenever I hit a decision point where I'm not totally sure how something should behave, I can just ship it anyway without stressing about it. Later on, I can retroactively change how that action works by updating the function that processes events into state changes. It's hard to convey just how liberating this is, but trust me, this situation comes up way more often than you'd expect.