On Tue, Apr 11, 2017 at 6:26 PM, Mitar <mitar@tnode.com> wrote:

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.

Yes or just connect a bunch of cheap single board computers. A nanopi is $8 + whatever a microsd card costs.

Alternatively a banana pi m1 is $35 and has sata + $200 for an 8 TB sata harddrive.

I'm switching all of the network gear to off-grid solar at my home right now, so we will have a place to host stuff like this.

So far only a single 255 watt panel but I'll probably go get another identical panel tomorrow.

Mitar

> The problem with SSB and similar systems is that they need log storage and
> our mesh nodes have only 8 MB of flash.
>
> They do have a USB port we're not using though, and 32 GB sticks are cheap.
>
> 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
>>
>

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

_______________________________________________
mesh mailing list
mesh@lists.sudoroom.org
https://sudoroom.org/lists/listinfo/mesh