[Mesh] Scuttlebutt

[Mitar]

Hi!

> Hm yes, but you _will_ need servers somewhere in the network for most types
> of applications. Mostly the servers just need to be there so your data is
> available to others when your browser isn't open.

Yes, but depending on the application. One I have in mind is more a
distributed real-time chat application which could be used in the case
that Internet uplink is severed to allow users in the network to help
each other. For example, telling what is the IP of some central server
somebody deploys and so on.

So it is more a backup communication channel what I have in mind.

> Serving up the initial html/js for the website only needs to happen
> once btw, since substack's hyperboot allows infinite offline caching
> of a web app after initial load and could easily be modified to fetch
> signed web app updates from other clients via WebRTC (something I'm
> planning to add soon).

Yes. hyperboot is really amazing work!

> The whole ICE/STUN/TURN stack shouldn't really be needed on a mesh
> but unfortunately it seems like there is no way to get the IP of the
> machine running the browser other than "ask someone else".

Yes, that would be the only thing which would run on nodes, but it is
pretty easy for a node to have that information.

Although, I am not familiar with details of the protocol. Does client
only needs to know IP and port (which could be part of JSON feed or
something), or is there some negotiation protocol involved so you need
some binary on the node?

Also, for smaller mesh networks (IPv4-based) maybe simply scanning the
whole subnet could work? If port would be fixed?

> This might be a nice thing to petition for adding to the web
> standards as it's really the only thing missing for full
> decentralized operation (after initial "installation").

Good luck with that. But on the other hand, a motivated person could
join a mailing list or two of standardized bodies and start nagging
about that. It requires time and dedication, but it does work. (The only
issue is that there are full-time people employed to nag into the other
direction.)

So yea, maybe we should do spend some time on standardization processes.
But this is then like 5 years in the future. Also, for standardization
is often important that you can first show a working example, a use
case, which might use some workaround. (At least for JavaScript things
it is often like that that you show implementation in JavaScript, and
then you can claim that standardizing that would improve performance and
behavior.)

> Another nice thing would be multicast WebRTC, but that's almost
> certainly never going to happen. The best we can do is probably
> running multiple WebRTC to multicast gateways on our meshes.

Heh, with multicast you would almost not even need routing protocols
anymore. ;-)


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m