@strypey @toolbear @latelesley @raineer @socketwench Not exactly, instance/server-centrism is embedded pretty deeply in #ActivityPub's core, and that assumption on the #clearnet has some immediate monetary consequences that #p2p programs with #gossip-spreading & first-class support for relays and diverse #networking & messaging transports (#darknets, overlays, #AsynchronousNetworking, etc) don't.
Both relays and p2p can be hacked on to some degree... but the seams are very obvious & fragile.
#gossip #activitypub #clearnet #p2p #networking #darknets #asynchronousnetworking
@meko Have you heard of #NNCP? That's pretty much the best example of such a program that comes to mind.
https://www.complete.org/nncp/
https://nncp.mirrors.quux.org/
It doesn't require any connectivity at all in order to work.
#Briar is a bit different but also provides an off-grid messenger. https://briarproject.org/how-it-works/
Even #email tolerates disruption fairly well (https://www.complete.org/asynchronous-communication/).
#AsynchronousNetworking #Offline #Sneakernet #P2P #Resilient #Encryption #Meshnet
#email #asynchronousnetworking #offline #sneakernet #p2p #resilient #encryption #meshnet #NNCP #briar
@ijatz_La_Hojita Techncially speaking, nothing in #ActivityPub proper /does/ explicitly require low-latency... except that in practice every single server uses off-the-shelf HTTP libraries that expect conventional low-latency TCP/UDP to work as expected.
If you modified the software to cache the session in DB and made for example some #NNCP adapter for carrying the HTTP requests by #sneakernet, you could have a janky but fully compliant ActivityPub server supporting #AsynchronousNetworking.
#activitypub #NNCP #sneakernet #asynchronousnetworking