@fdlamotte @marsik @tuga My big concern is that in public spaces you have to throttle or gate people accessing the thing. For broadcast (read) only that doesn’t matter but for writes I guess you’d need permissioning or throttling.

@fdlamotte @marsik @tuga I’m planning to prototype this next week just for fun, to see if it works. But curious if there have been any experiments in this model or if it’s a bad idea for known reasons. (I know iOS background BLE receiving is very very bad.)

@fdlamotte @marsik @tuga All of these projects seem to operate on a 1:1 PC/radio model. I think a better design would move the client logic to a PC/smartphone, but each radio device could support many clients — each with their own public key/identity. You’d have to use BLE advertisements to support many clients per radio.

Boston. #meshcore

@marsik I’m planning to code this up next week.

@marsik oh never mind, I understand what you’re saying. What I want is that but bigger: I want a single radio to be able to support 100 simultaneous smartphone clients via BLE advertisements. For protests and natural disasters.

@marsik I think that’s basically what this does. It’s a real MeshCore node with all the radio layers turned into stdio ports. A better design would define this explicitly as a HAL.

Right now it handles simulations that involve collisions, delays and other common events (in a very simple model). Each node is a simplified Meshcore node running as a process. #meshcore

Just to give some visuals. #meshcore