[guardian-dev] GilgaMesh (was Re: FireChat moved off iOS proprietary mesh to their own xp mesh protocol?)

Thu Oct 2 16:07:17 EDT 2014

There is absolutely no way to interface with Wifi, or non-LE Bluetooth on
iOS. Our *only* option for interoperability is BLE. It looks like support
for BLE on Android is getting better by the day, and hopefully in the next
few weeks we should have a cross platform BLE demo figured out.

However, I think it would be beneficial to utilize other transports for
Android<-->Android and iOS<-->iOS for increased overall range / mesh
quality. The iOS MultipeerConnectivity framework uses Wifi / Bluetooth in a
proprietary/closed way and will never interoperate with Android (by
design). Android supports Wifi Direct in a more open fashion, but it will
never interoperate with iOS because Apple likes to be stubborn.

On Thu, Oct 2, 2014 at 12:16 PM, Nathan of Guardian <
nathan at guardianproject.info> wrote:

>
>
>
> On Thu, Oct 2, 2014, at 03:09 PM, David Brodsky wrote:
>
> From my most humble understanding Gilgamesh (super cool!) currently uses:
>
> Bluetooth SDP (high power) to advertise and RFCOMM (high power) to
> exchange data.
>
>
> The data exchange is actually done in the discovery mode mostly. This is
> the key to the hack. Using the broadcast device name as the message
> transport.
>
> The RFCOMM connection is only when you want to send a direct, semi-secured
> message device to device.
>
>
>
>
> We could use Bluetooth LE GATT (low power) to advertise in a cross
> platform way (and save energy). However GATT is intended for
> "characteristic" reading/writing @ ~20 bytes per packet (1 Mbit/s)
> <https://bluegiga.zendesk.com/entries/22400867--HOW-TO-Maximize-throughput-with-the-BLE112-BLED112>
> and not significant data transfer (that's where Bluetooth Classic's RFCOMM
> comes in).
>
>
> Right, but we are talking about small amounts of data. Short Twitter or
> SMS broadcast messages, so it may be viable.
>
>
>
> I think the challenge ahead is finding a creative way to negotiate a
> cross-platform data exchange channel once iOS and Android clients discover
> each over BLE GATT.
>
>
> I need to get a BluetoothLE equipped Android device! However, from my
> early reading, it seems the Android APIs for this are pretty limited.
>
> What does iOS offer on the wifi / wifi direct side of things? Any way to
> scan for SSIDs?
>
>
>
> Please correct me if I'm wrong. All the above is based on my preliminary
> reading and tinkering.
>
>
> Mostly right, i think!
>
>
>
> On Thu, Oct 2, 2014 at 11:05 AM, Chris Ballinger <chrisballinger at gmail.com
> > wrote:
>
> Pretty neat! Unfortunately you can't do the same on iOS unless you use
> Bluetooth 4.0 LE. Would this be possible using BLE instead of RFComm?
>
> On Wed, Oct 1, 2014 at 11:57 AM, Nathan of Guardian <
> nathan at guardianproject.info> wrote:
>
> https://github.com/n8fr8/gilgamesh/blob/master/README.md
>
> Some notes on the implementation, aka the glorious hack of Bluetooth
> Device Names. This application was original based on the Android SDK
> BluetoothChat sample. It used insecure (unpaired) and secure (paired)
> Bluetooth RFComm sockets to allow for short messages to be sent between
> devices. The primary modification that this project has made has been to
> add support for a "Broadcast" mode, that uses the Bluetooth device name,
> that is public visible during the Discovery process, as the message
> transport itself.
>
> The design goals of this project are:
>
> A truly decentralised application that requires only Bluetooth
> connectivity and has no central user registry
> Incredible ease of use that ensures all "mesh" connectivity happens with
> as little user involvment as possible
> Ability to enable trust or reputation for specific users or devices you
> message with
> A very transient app that stores no data permanently
> Ability to share the app easily between devices
> A "fire and forget" mode, where the user can enter a message, put the
> phone in their pocket, and walk around and area and have it broadcast to
> all devices it encounters
> The key innovations/hacks/revelations that led us to this point were:
>
> As of recent Android versions, you can call an API to set your the
> device's Bluetooth visibility to a very long time ~1 hour
> You can dynamically change the Bluetooth device name, and it can be long
> - up to 248 bytes encoded as UTF-8
> That the first two things above could be wrapped mostly in API calls the
> user did not have to see or worry about
> Finally, some thoughts on security, privacy and reputation:
>
> This app supports both a public broadcast mode, and a private, direct
> message mode. It is easy to use to both. The direct message mode is
> optionally secured and encrypted at the Bluetooth level if you have
> paired with the device/user you are connected with.
> Impersonation is combatted by simplified user id's to a short (6
> character alphanumeric) value, based on the device's unique Bluetooth
> ID. This makes them speakable and easy to remember. If someone says
> "trust messages from A1BC99" then likely you will be able to rememember
> that.
> If you pair with a user (using standard Bluetooth pairing settings),
> their userid will be appended with a *, to make it even easier to know
> this is someone you should trust
> The app ONLY works in Bluetooth mode, so though is no confusion when it
> might be using 3G/4G, Wifi or some other mode, and possibly go through a
> centralised server
> The code is open-source, very small, and the entire app is only 28kb
> making it easy to audit, test and share
> We make it easy to "retweet" a message by long pressing on it, which
> enables reputation for something to be built up by multiple people
> resharing it. If the user has paired with the user, you will also see
> the * next to the name to further indicate trust.
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>          Or visit:
> https://lists.mayfirst.org/mailman/options/guardian-dev/chrisballinger%40gmail.com
>
> You are subscribed as: chrisballinger at gmail.com
>
>
>
> _______________________________________________
> Guardian-dev mailing list
>
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit:
> https://lists.mayfirst.org/mailman/options/guardian-dev/davidpbrodsky%40gmail.com
>
> You are subscribed as: davidpbrodsky at gmail.com
>
>
>
>
>
> --
> Nathan of Guardian
> nathan at guardianproject.info
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20141002/870fae74/attachment.html>