retro.social is part of the decentralized social network powered by Mastodon.
A social network for the 19A0s.

Server stats:

24
active users

Learn more

Charles U. Farley

Is there any way we might be able to make work on ? I.e. something that doesn't depend on a durable domain name, like over or something. Does support and on iOS?

I'm assuming we'd need to get something into the . Even a local proxy would be fine.

@freakazoid Been looking at various ways to get a Kubo-compatible implementation working on Android myself. It's a hack and you'd have to write bindings, but Helia might be the best bet. Same idea on iOS since it's a web library.

@Arlodottxt I suspect the reason there's only Odin probably has to do with power consumption and the general difficulty of keeping a p2p app running on Android. Even Veilid Chat is not yet able to receive messages when it's not open. Or, at least, it doesn't for me.

But I don't really mind needing a tier of full nodes that mobile apps can use as long as there's some way to select one or more automatically. I think "2-tier" p2p is the way to go for mobile.

But in the iOS case I wasn't thinking about the technology but their rules against executing downloaded code. Only Safari is allowed to do it, AFAIK. You can have a browser that embeds Safari, but I don't know how much you can hook into the network stuff to implement a decentralized network with heavy caching that is then able to use WebRTC and hopefully WASM.

@freakazoid Service Workers have come along far enough to allow Helia to run a single node per-domain in the background. It enables experiments like inbrowser.link.

The main issue is the cold boot on first use, but that's a general issue on the Amino DHT.

Techniques like swarming a user with their own devices and with a dev-run node still work to speed things up. Mobile nodes should be thinner than desktop nodes either way.

IPFS Service Worker Gateway | production@7b0ebf3inbrowser.link