@silverpill@mitra.social Ah, I think I sorta get what you mean -- similar to how WebTorrent in the browser can't talk to normal BitTorrent peers, but WebTorrent peers running on node.js can talk to both...?

Basically a p2p extension could be developed for ActivityPub so that any ActivityPub server which both supports that extension AND is TCP-dialable could act as a relay for all the servers which support that extension but are NOT dial-able.

I might be ignorant of ActivityPub and how it works but I suspect this would run into issues because most implementations will want to hear about activity on Server A coming directly from the URL they have for Server A -- Every entity in ActivityPub has an ID and as far as I can tell that ID always starts with `https://<domainname>/

Surely there is a way to make it work, but at least from my (admittedly somewhat ignorant) understanding, it feels like trying to shoe-horn p2p into a protocol which was hard locked into requiring TCP dial-able servers very early on in its design. I have seen some p2p activitypub extensions in a similar vein like https://trustbloc.github.io/activityanchors/ but how many implementations are actually going to support things like that ? I suspect most of the activitypub developers would push back against such specs, calling them bloated and too burdensome to implement correctly.

But also, such a p2p activitypub project could also include a TCP reverse tunnel gateway feature similar to greenhouse, ngrok, or pagekite. This way the ActivityPub application layer protocol can stay as-is and keep its precious ubiquitous `https://` URLs, but at the same time someone might be able to host a homeserver in their dorm room where they can't configure port forwarding.

IDK. at least thats how I see it. The application protocols (specifically web browsers) have too much inertia and wont move, so we have to move the network for them.