Daniel Quinn

I’m afraid I have no idea what an RCS is, but maybe that’s a network/region specific thing? I’m in the UK using GiffGaff (O₂) and the phone, SMS, and data works exactly as well as everyone else’s… which is to say perfectly in most places and sporadically on the train due to the dead zones on the route.

I’m using a Fairphone 4, which is 4 years old at this point (October 2021) and I’m still quite happy with it, but I owned the Fairphone 1 and 2 as well.

In terms of software atrophy, they do offer support for your device for 5 years, which is better than most, and because of its open nature, it’s generally well supported by alternatives like Lineage or Calyx, but yeah, I’m still on Android 13. While I still get regular security patches and haven’t really had a need for an upgrade, there’s no denying that the FP4 is behind.

Of course, it’s also easily repairable, supports an SD card and replaceable battery, so that’s a tradeoff I’m happy with.

I’d rather see a stable OS and ecosystem for good, Free apps that we can flash onto existing devices. I’m quite happy with my Fairphone (repairable! modular! ethical!) and we know that building and marketing a device is painfully expensive.

Let’s make Debian or Arch just work on most phones instead of trying to compete in a saturated market.

I hadn’t considered Syncthing. One could for example bake the syncthing protocol into an SSB-based app such that whenever a paired device comes online it automatically syncs data over so to the user things are seemingly centralised. The only risk I can see there is a case where Device A is turned off before Device B is turned on, so the sync wouldn’t carry over. That’s a small price to pay though I think, and something people could learn to work around.

It’s funny, I do exactly what you describe, but with Joplin, though it never occurred to me to reach for Syncthing in this case. Thanks!

No, I was wanting to go the step further and target “offline first” to avoid the need for too many “always on” services. From a philosophical perspective, I think our internet should be able to function without the resources required to run something 24hrs/day.

You can absolutely build a LinkedIn clone on top of something like ActivityPub for example, but I’m not sure how one might do that from an “offline first” perspective though.

Edit: I just remembered my primary objection to this argument: most people aren’t nerds. You can’t have a properly distributed web if federating requires access to (a) an always on server, and (b) the skills to maintain it yourself. I’d argue that this is precisely why the fediverse is so dominated by Free software nerds like me. No, it has to be easy: install an app on my phone, start writing. Let the app figure out how to connect everything, and if I get on a boat/plane/train or my phone runs out of battery, connectivity should Just Work™. This is what I love about SSB: whatever we build on top of it, the protocol was already designed on this assumption.

I had exactly this thought just over a month ago. After mulling it over for a few days, I decided that the only reasonable way to build it would be on top of Scuttlebutt. Alice shares her CV, makes it available via a pub, Bob shares a job description at the same pub, and the two can connect through there, etc.

The advantage of SSB is the absence of the need for an always-on, big data cloud service. The project instead is managed by a swarm of phones all connecting intermittently. It’s very solarpunk.

The big problem for me was the multiple device question. If Alice wants to interact with “FreeLinkedIn” both on her phone and her laptop sporadically over many days, you still need a cloud device to hold state, negating all the benefits granted from SSB. I couldn’t figure a way around this, and then got distracted.

Ooh, I’ll steal that!

has shifted from an MIT open source license

This is what happens when you contribute to MIT-licenced projects. They steal your work out from under you.