I can already imagine a few ways that can go wrong. This would be a awesome way to do it though but there are many issues that would have to be addressed for that.

[–] manitcor@lemmy.intai.tech 3 points 1 year ago (1 children)

same, but its not like its something that hasent been worked on intensely for the past 15 years or anything, using mechanisms that require a level of consensus we dont need the overhead of meaning higher throughput. We also dont have the read only write-forward problems that those systems have so we can simply leverage the very well refined P2P mechanisms they use, i bet if we go looking, we find one that has its p2p protocol implementation in its own github even.

the thrust here is rather than diy, lets leverage work where billions have already been sunk.

[–] RGB@lemmy.world 2 points 1 year ago (1 children)

p2p makes sense in this situation. It can end up being a massive battery drainer if we are talking smartphone implementation. (coming from torrenting reference point and how it eats battery on phones)

[–] manitcor@lemmy.intai.tech 2 points 1 year ago

so the way these work usually is 2 piece like old IRC away daemons. You have a headless instance that syncs what you care about on "someone elses computer" or just online all the time. That does the job of keeping up-to-date. Your phone and other devices do a secure connection to that device to get updates. what's interesting about building it to just be the same kind of server is you can simplify deployment and apps (its all the rage anyway just look at a react app).

so your device does not need to be online, you could run things like bots and have schedules and get just the deltas when you come online. This is also how private signing works today so the design and deploy pattern is well documented.