Libp2p or similar stack could be used to provide the phone instance an address, caching could be distributed among peers. Of course, as long as other servers also support libp2p.
What would be the up/downsides?
Libp2p or similar stack could be used to provide the phone instance an address, caching could be distributed among peers. Of course, as long as other servers also support libp2p.
What would be the up/downsides?
Its technically possible but not a great idea, lemmy instances take a good chunk of power and storage. And a phone will run out of battery very fast, so you’ll need to charge it permanently, wich will wear out the phone fast. A raspberry pi would be better suited for it.
You wouldn’t need to run the service 24/7, just whenever you’re using Lemmy and maybe a few minutes after so your interactions can propagate trough the p2p network. Also the existing servers could be used to cache and relay.
I run my own instance, and that’s not really how it works. While the instance is off, it isn’t receiving new posts. So when you turn it on and log in, there will be nothing new for you to view. Everything you will see will be the same stuff as when you logged off last time. On top of that, while your instance is off, all the other instances that are federated with you will constantly be trying to communicate with your instance, causing all the other instances to do more work. Recently a change went into lemmy to automatically block instances that have reliability issues. And if other instance admins are watching their logs, they will probably block your instance anyway (lemmy.world has done this occasionally).
Your lemmy instance needs to have at least 98% uptime imo. If it goes down for a few days rarely, it’s not a big deal. But shutting it down 80% of the time and only having it up while your using it will be bad for the lemmyverse and for you, the user.
A raspberry pi is inexpensive and is a much better solution, as it can be wired in all the time.
P2p enabled instances would have the option to reverse the communication flow, so besides the servers having to send updates to subscribed servers, the subscribers would have the option to ping peers/servers for updates.
This would help with sync issues when a post is made and the changes are not propagated to all subscribers.