I don't think it really needs to be a whole lot more complicated than just spinning up a pub on some node on the mesh (or better yet, just putting a pub on the internet). I think the multicast DNS stuff is more to sync with peers who are in the same room. Multicasting to the entire mesh would defeat the entire purpose of routing and IP, technologically taking our network back to the 70's. People always feel the need to reinvent the wheel with this stuff (at least I did, when I started getting into it a couple years ago).

-Jehan

On Tue, Apr 11, 2017 at 12:13 AM, Mitar <mitar@tnode.com> wrote:
Hi!

Yes, you could adapt patchwork/ssb to run "natively" on the mesh network.

By "natively" I mean that it would use mesh nature of the network. Of
course you could run patchwork as in any other (local or global) network
but that is not as interesting.

So how could one run "natively" run patchwork on the mesh network,
especially when nodes are cheap devices with limited resources (so you
cannot simply run full patchwork daemon on them).

I would suggest that then we use WebRTC to create connections directly
between clients on the network. Each mesh node would have to run a
WebRTC handshake program, but even that can be a very simple one if mesh
network does not use any NAT and supports end-to-end connectivity inside
the network. Each JS client would POST to something like
/cgi-bin/webrtc/peers on its node, providing a WebRTC offer. And then
that would be distributed to all other nodes in one-hop radius using
some node-to-node mechanism (probably could be added to Babel, or use
simply link-level broadcast). And then all nodes would list on
/cgi-bin/webrtc/peers all WebRTC offers. Then client side would fetch
current list of offers from its node, and establish WebRTC connections.
Something like that.

And then it could normally send patchwork/ssb messages across those
connections and you would have decentralized "native" chat.

I think that such WebRTC handshake and peer discovery program using
babel routing for OpenWrt would be in general very useful for many many
applications. Any takers to implement it?

I am not sure if patchwork/ssb is already made so that it can run
directly/only in the browser.

Maybe it would be easier to port orbit which uses IPFS. IPFS already has
a client-side JavaScript implementation. So you could use IPFS in the
mesh, and then use orbit to have a chat application.

https://github.com/orbitdb/orbit

It is less developed than patchwork/ssb though. But I like that its
architecture is layered. Then if IPFS is supported "natively" in the
mesh, we automatically get orbit to work as well. I like that.


Mitar

> On Mon, Apr 10, 2017 at 9:28 AM, mattsenate@gmail.com <mattsenate@gmail.com>
> wrote:
>
>> I think the question is whether udp broadcast is supported by the mesh
>> firmware or by openwrt by default so that users of patchwork can identify
>> and address one another on the people's open net.
>>
>
> The mesh is not one big subnet. There is no simple way to broadcast to the
> entire mesh.
>
>
>
> _______________________________________________
> mesh mailing list
> mesh@lists.sudoroom.org
> https://sudoroom.org/lists/listinfo/mesh
>

--
http://mitar.tnode.com/
https://twitter.com/mitar_m
_______________________________________________
mesh mailing list
mesh@lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh