[guardian-dev] FireChat moved off iOS proprietary mesh to their own xp mesh protocol?

[Nathan of Guardian]

On Wed, Oct 1, 2014, at 10:46 AM, Hans-Christoph Steiner wrote:
> 
> 
> Nathan of Guardian wrote:
> > 
> > 
> > On Wed, Oct 1, 2014, at 09:42 AM, Nathan of Guardian wrote:
> >>
> >>
> >> On Wed, Oct 1, 2014, at 09:29 AM, Nathan of Guardian wrote:
> >>>
> >>>
> >>> On Wed, Oct 1, 2014, at 08:18 AM, Michael Rogers wrote:
> >>>> Interesting idea! With old school Bluetooth you can't make an Android
> >>>> device discoverable for more than 2 minutes, and it requires user
> >>>> confirmation each time. But maybe the situation's different with
> >>>> Bluetooth LE? I haven't looked at the API yet.
> >>>
> >>> Even without LE, it seems improved in recent APIs, up to 3600 seconds. 
> >>
> >> Confirmed, I just set my Moto E running 4.4.3 to be discoverable for 1
> >> hour. Interesting!
> > 
> > You can also dynamically change the Bluetooth device name within one
> > discoverable session, and that seems to be able to be the full 248 bytes
> > indicated in the API docs (at least testing between Moto E and Nexus 7). 
> > 
> > On the discoverer side, you can continuously trigger discover sessions
> > (which seems to be about 12 second long) without issue, and you will see
> > the updated names as they occur. 
> > 
> > All in all, it seems like using Bluetooth this way, while a total insane
> > hack, is viable and creates a very simple messaging system on top of
> > which we could easily run OTR or Axolotl. 
> > 
> > I am thinking of wrapping this up in the ChatSecure UI since we have the
> > pluggable protocol piece anyhow. Groupchats would be unencrypted
> > messages based on #topic but you could also init one-to-one chats with
> > specific devices as well, and OTR would work in that case.
> > 
> > +n
> 
> 
> Are you thinking that this useful to avoid pairing?  Sounds like it would
> be
> quite low bandwidth since it sounds like there wouldn't be an in-band way
> for
> the receiver to communicate that it received the message from the sender,
> unless both devices can be changing their bluetooth names in discoverable
> mode
> while discovering other devices.

You can apparently do just that.

There are three states we can work with:

1) This psuedo broadcast mode, where you use the bluetooth device name
to spam the airwaves to anyone who will listen.

2) The "insecure" Bluetooth connect mode that Android now supports,
where you can create a Bluetooth socket between two devices without
needing to pair.

3) The "secure" Bluetooth connect mode where you must pair before you
can create a socket.
 
> I think it could be useful as the first phase of a pairing procedure: if
> each
> side already have trusted OTR keys for each other, the sender encrypts
> the
> pairing code in an OTR message and sets its bluetooth name to that
> message.
> The receiver decrypts the message and kicks off pairing using that the
> code it
> just decrypted.  Then they can use full-bandwidth Bluetooth.

I think for most crowd/group/mesh apps, #1 and #2 can handle most
functions. #3 would only be used for a secure, verified, encrypted mode.

Ultimately, pairing is really annoying, and if we can avoid it we
should. By using OTR on top of #2 above, we can have  secure, verified
connection.

+n