Would it be possible to roll our own protocol that would mimic the way SSB works? Or achieve the same goal using babel somehow? Mind you, my understanding of SSB/PW is limited, but this reminds of a discussion we had a few sundays ago regarding the possibility of "nodemail."

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 mattsenate(a)gmail.com> identify the -- http://mitar.tnode.com/ https://twitter.com/mitar_m _______________________________________________ mesh mailing list mesh(a)lists.sudoroom.org https://sudoroom.org/lists/listinfo/mesh

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 mattsenate(a)gmail.com> identify the -- http://mitar.tnode.com/ https://twitter.com/mitar_m

Hi! If log storage is done on client-side only, then it works while at least one client is connected. We could have one "heavy" node with more store to allow history to work while clients are disconnected.

Mitar and cheap. network. -- http://mitar.tnode.com/ https://twitter.com/mitar_m

Why not just use IP multicast and limit it to just the UDP port numbers needed for this application?

Weird. I seem to remember they used mdns a few years ago. Might be worth asking why they switched? Also, isn't multicast routing just a network flood?

-Jehan On Wed, Apr 12, 2017 at 9:24 PM, Marc Juul <juul(a)labitat.dk> wrote:

Hi, Just to clear up routing/bridging of multicast: for routing, it's where you have multiple IPv4/IPv6 interfaces you are routing, and you want to watch for multicast group requests and pass them on, then forward traffic as appropriate between interfaces for a given multicast group /only/ if someone is subscribed to it. Otherwise you have to forward all multicast traffic, and it's unfun. By default noone routes multicast because, well, reasons. I've forgotten about multicast and TTL stuff, and whether multicast routing requires a star/acyclic graph to ensure you don't get broadcast storms/loops. for multicast switching, it's mostly just "sniff multicast group requests (IGMP snooping)" and don't forward multicast for other groups. Except for certain circumstances, it's pretty useful in cutting down massive amounts of multicast traffic that by default you'd have to flood to each port like any other broadcast. Now, for wifi, it's /totally/ possible to do intelligent things with multicast snooping, but I hope that this is just using broadcast/multicast for discovery, rather than passing real data. (You can do multicast-to-unicast, then only forward streams that clients request.) broadcast/multicast is spendy on wifi and double-spendy on 11s because of how traffic gets replicated. So as long as it's for peer discovery, cool. Final dotpoint - if it's using UDP broadcast instead of multicast, you may find mrouted doesn't help - but then writing a little application to 'route' those announcements between subnets may not be /that/ hard. So, is it using multicast to do peer discovery, or is it doing broadcasts? Has anyone spun it up and done some packet dumps to see?

-adrian

Hi, Hm, maybe make it use mDNS and run an mDNS relay to go between multiple subnets (for a subset of mDNS, or hilarity ensues.)

On 13 April 2017 at 15:11, Marc Juul <juul(a)labitat.dk> wrote: wrote: You can try both! heh. mrouted +kernel multicast should be fine on linux these days, it's just more moving parts versus just broadcast sockets and UDP. :-) A lot of old timer-y people are leery of multicast and mrouted because, well, it's not exactly been a path well traveled. So give it a go and see what happens. -adrian