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.
This is the first time I’ve heard of Scuttlebutt. Thank you for the introduction.
For your multiple-device problem, I would suggest trying Syncthing. It allows you keep folders synced between devices over a local network. I use it for a very similar application to what you are describing:
Logsec is a journal/note-taking software that stores each entry as it’s own markdown file. I use it on my phone, laptop and desktop, and want to have all my notes synced between devices. I could put the folder of markdown files on a cloud server, but choose not to. Instead, I setup a link between each device’s Logsec folder through Syncthing.
Now I can add or update notes on my phone when out in public, and when I return home and reconnect to my WiFi it automatically updates the other devices on the network. Also, when editing the markdown files on my desktop, the updates are synced to my phone nearly instantaneously.
I expect this method would work very well with Scuttlebutt due to it’s similar offline nature.
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.
This is the first time I’ve heard of Scuttlebutt. Thank you for the introduction.
For your multiple-device problem, I would suggest trying Syncthing. It allows you keep folders synced between devices over a local network. I use it for a very similar application to what you are describing:
Logsec is a journal/note-taking software that stores each entry as it’s own markdown file. I use it on my phone, laptop and desktop, and want to have all my notes synced between devices. I could put the folder of markdown files on a cloud server, but choose not to. Instead, I setup a link between each device’s Logsec folder through Syncthing.
Now I can add or update notes on my phone when out in public, and when I return home and reconnect to my WiFi it automatically updates the other devices on the network. Also, when editing the markdown files on my desktop, the updates are synced to my phone nearly instantaneously.
I expect this method would work very well with Scuttlebutt due to it’s similar offline nature.
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!
Decentralized doesn’t mean cloud. You can have an instance in a computer you own that it’s always on.
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.
Sync needs 24/7