Fluid Nexus -- mobile messaging without the mobile phone network

[nkn...@gmail.com]

I'm happy to announce my project Fluid Nexus, an application that is
primarily designed to enable activists and relief workers to send
messages and data amongst themselves independent of a centralized
cellular network. The idea is to provide a means of communication
between people when the centralized network has been shut down, either
by the government during a time of unrest, or by nature due to a
massive disaster. It uses Bluetooth to create short-term, short-range
network connections between people, thus using the phones as part of a
"sneaker-net".

This was a particularly difficult project to write for the ADC given
that Bluetooth is not supported in the emulator :-) However, I wrote
a basic Bluetooth simulator that fires off simulated events (at least
those that are relevant for my application). As well, I wrote a
bridge that sits between the emulator and the host's Bluetooth
adapter; the bridge transfers data between the two via TCP sockets, as
others have done here for cameras.

I've released the source code under GPLv3; it's really poorly
documented right now, but that will hopefully change soon.

Website: http://fluidnexus.net
Project video: http://vimeo.com/899706
Application: http://fluidnexus.net/media/code/FluidNexusAndroid.apk
Source code (licensed under the GPLv3): http://fluidnexus.net/media/code/FluidNexusAndroid-0.01.tar.gz
Subversion repository: https://svn.zeitkunst.org/viewvc/FluidNexusAndroid

I'm excited to hear what people think!

Good luck to everyone in the challenge, and especially those who, like
me, just submitted their application :-)

nick

[nkn...@gmail.com]

Forgot to add a link to the project documentation:
http://fluidnexus.net/media/pdf/FluidNexusAndroid.pdf

nick

[Muthuselvam Ramadoss]

Very nice. Imaging actually using your cell phone, when the networks are off. Great utility. Good luck on your submission.

--
take care,
Muthu Ramadoss.

http://mobeegal.in
find stuff closer.

[Muthuselvam Ramadoss]

Very nice. Imagine actually using your cell phone, when the networks are off. Great utility. Good luck on your submission.

*typo fixed.

[Hielko]

Cool idea, but I think it will be hard to make the concept work. You
will need a lot of people with your application to make it work, but
to get a lot of people using it it has to be usefull from day one.

On Apr 15, 9:15 am, "Muthuselvam Ramadoss" <muthu.ramad...@gmail.com>
wrote:

> find stuff closer.- Hide quoted text -
>
> - Show quoted text -

[Muthuselvam Ramadoss]

If its useful, you'll get people from day one. As it gets popular it'll make more and more people use them.

[whitemice]

Hi Nick, I enjoyed your video and think you have some great ideas.

Technology wise, I implemented something like this in 2002, but was
frustrated by industry fragmentation and lockdown.

Android for me was an opportunity to rebuild the idea as an advanced
geographically intelligent peer-to-peer network (using Bluetooth, Wi-
Fi and Cellular connectivity) so I could offer commercial products and
services from day one.

It will take a few days to get the project information online (once I
catch up on some sleep), but I will post it here as soon as I am done.

Good luck in the ADC.
Mark

[nick]

Thanks for your comments! It does require a lot of people to use, but
one use case is that you get a group, like a set of relief workers or
activists, to agree to use it beforehand. They can potentially
recruit others to use to program as well.

In a way the project is also conceptual, hopefully suggesting how we
can rethink networking from the ground up, since all of our devices
already have a number of different networking technologies (like
Bluetooth and WiFi) that can be used without having to go through the
mobile phone provider's network.

nick

[nick]

Thanks, and good luck with your project as well! I look forward to
seeing it.

And I agree with your point about android; my hope is that it pushes
other providers to open up their networks and their development
environments, as Verizon is moving to do. Having an open development
environment and (future) open-source system was key to me; I wanted to
make sure that what I wrote would have the potential to be used and
modified by as many people as possible. It's a shame that mobile
development has been so hampered so far, given the power that we all
have in our pockets, and given that mobile devices are pretty much
ubiquitous throughout the world.

nick

[whitemice]

As promised I have got my project website and videos online.

Snowball is a revolutionary platform for getting location sensitive
content (and advertisements) onto your mobile. Its based around a
peer-to-peer network and provides a local area search API to your
Android Applications:
http://www.zedray.com/snowball/

Let me know what you think.
Marl

[Muthu Ramadoss]

This was very appealing when you had the emergency use case example. Not sure why you changed it to a trivial ice cream example. Now the wow factor has definitely come down in my mind. Any reasons, why the emergency use case is not highlighted?

[nick]

Looks interesting, especially the combination of all of the varied
services. Are you going to provide the API/library? I assume you
simulated things for the video, since I don't think those services are
available in the current SDK?

nick

[GodsMoon]

Any reason you are using bluetooth instead of wifi? If I remember
correctly wifiArmy is using wifi for this kind of interaction. Can
anyone speculate on how many googlePhones will have wifi vs bluetooth?

[nick]

The reason I used bluetooth is because of the original target
platform, which was Nokia Series 60. The idea was to use whatever
networking technologies were available, and for a lot of those phones
it's bluetooth. If WiFi is available, then great, as long as you can
have enough access to the stack in order to do ad-hoc style
connections. With bluetooth, that's fairly easy to do. But yeah, I
definitely want to support WiFi in the next version; it's just that
this android SDK didn't even have an outline of a WiFi API, when it at
least had the rudiments of a bluetooth one.

nick

[Muthu Ramadoss]

Peer to Peer on bluetooth if possible.

Get on to WiFi if available.

Get on to the Cell network if neither bluetooth or wifi available.

Interesting combo.. any thoughts?

[nick]

Yes to the first two, but at least for my project I'm wary of sending
things over the cell network for reasons of security. It would also
remove the ad-hoc, mesh nature of the data transmission.

nick

[Ted (Hsiang-Tai) Chien]

Your project might be useful for people who lives in some countries
that its government censored networks.

Wish you luck with the submission. :)

Regards,
Ted

[nick]

Thanks! Your suggestion is one of the primary motivations for the
project.

nick


On Apr 19, 6:07 am, "Ted (Hsiang-Tai) Chien"

[Shane Isbell]

Hi Guys,

 

Nick submitted Fluid Nexus to SlideME last Tuesday: http://slideme.org/content/fluid-nexus . You can register and post comments there, as well. Its a bit easier to track down comments later, for new users and the developer.

 

Thanks,

Shane

[whitemice]

Just back from a well deserved weekend off. :-)

>>This was very appealing when you had the emergency use case example. Not sure why you changed it to a trivial ice cream example. Now the wow factor has definitely come down in my mind. Any reasons, why the emergency use case is not highlighted?<<

99.9% of the people using the Snowball platform would do so for
location based search and advertising (search for Pizza, social
networking, dating, etc). However if someone wrote a messaging
application using this platform, they could highlight the emergency
use case as part of their design. The ice cream example is just an
easy way to get the concept across to people.

Everybody likes ice cream. ;-)

>>Any reason you are using bluetooth instead of wifi? If I remember correctly wifiArmy is using wifi for this kind of interaction. Can anyone speculate on how many googlePhones will have wifi vs bluetooth?<<

Currently (i.e. on existing hardware) having Wi-Fi switched on uses
significantly more power than Bluetooth, hence it is a bit of a
problem for always-on-ad-hoc-networking, although I look forward to
tackling these problems when the hardware and APIs become available
for Android.

Using cellular (via a server and cell id tags) is like putting an ad
hoc network on steroids, i.e. it does a lot of useful things like
improving the user experience on first use and reduces propagation
delay.

Also, I have put a lot of work into protecting user privacy, so unlike
other LBS technologies this does in no way compromise the user and
their location to the “government”.

>>Looks interesting, especially the combination of all of the varied services. Are you going to provide the API/library? I assume you simulated things for the video, since I don't think those services are available in the current SDK?<<

If you look at the architecture, you’ll see that I was able to
implement a lot of the technology already:
http://blog.zedray.com/snowball/technical-details/
Snowball is just missing Bluetooth, Wi-Fi and actual handsets.

Hence the Snowball applications will work as soon as Google installs
them on an actual Android device - although they say they won’t be
doing this!

When run in the emulator, some of my ADC submissions rely on the
server being injected with canned data (e.g. Pizzeria #1, User #2),
although Snowball Date users can publish their own profiles and watch
them appear on other devices. As the current Android emulator lacks
proper cell id simulation, there is no location sensitivity to this
information.

Right now I am looking to partner with people who can make marketable
end user applications, so I can get feedback on the API and
concentrate my energies on getting the networking right.

In time I will publish the Snowball for Android client and make its
API available for general use.

[Muthu Ramadoss]

Hi,

Which platform is snowball server running? Do you broadcast more than the location from the server?

What kind of end user applications are possible using snowball? Do you have any specific kind of end user applications that might be the killer app for snowball?

[Muthu Ramadoss]

Got confused by FluidNexus and Snowball. They have similar goals, but
they are 2 completely different projects. Guess FluidNexus had the
emergency use case and Snowball has the ice cream example. Cool,
finally got clarified myself.

On Apr 17, 11:49 pm, "Muthu Ramadoss" <muthu.ramad...@gmail.com>
wrote:

> This was very appealing when you had the emergency use case example. Not
> sure why you changed it to a trivial ice cream example. Now the wow factor
> has definitely come down in my mind. Any reasons, why the emergency use case
> is not highlighted?
>

[whitemice]

>>Which platform is snowball server running?<<

The original plan was to implement it in PHP, but because Android
supports a lot of the Apache specification I found that if I used a
Java host I could reuse a lot of the client code on the server (the
benefits of peer-to-peer and all that).

Currently it is running as a JSP web service on a virtual Apache
Tomcat server with a MySQL backend. Although each Cell-id-node-
instance is atomic, so I can scale it up and make it distributed if
necessary. The idea being that I can just add computing resources to
it as needed.

>>Do you broadcast more than the location from the server? <<

The server turns each Cell tower into a Snowball node. This means it
doesn’t actually broadcast location information (not yet anyway), but
instead allows Snowball Ads to be stored as if on the cell tower.

Say you write a multiplayer game, which is running on 10 handsets in
your area. Snowball will detect and rank these handsets by closest
first, but will not be able to tell you exactly where they are.

Detecting actual location is better handled by the application using
GPS etc (i.e. with user approval), and is not suitable for all
applications, e.g. dating.

>>What kind of end user applications are possible using snowball? Do you have any specific kind of end user applications that might be the killer app for snowball?<<

Different people will find different applications useful at different
times. I have listed the vague categories and use cases that can be
easily implemented on top of Snowball here:
http://blog.zedray.com/snowball/why-is-this-useful/
(Location-based services, Social networking, Gaming, News and
information, Logistics)

But everyone I talk to about this tends to come up with new stuff by
themselves.

>>Got confused by FluidNexus and Snowball. They have similar goals, but they are 2 completely different projects. Guess FluidNexus had the emergency use case and Snowball has the ice cream example. Cool, finally got clarified myself<<

Excellent
I can’t wait to see this “mobeegal” LBS search engine that you’ve been
working on.

Regards
Mark

[Muthu Ramadoss]

Thanks for the details. Checked out your website, looks great.

Mobile Social Networking is an exciting space to be on currently, and am sure lot of folks working on it right now.

May be we can start a group, and start collaborating on the ideas, technologies etc., related to the mobile social networking space.

Any thoughts?

[zero]

maybe as a sub-group of dataportability ?
*just my two cents*

> > (Location-based<http://blog.zedray.com/snowball/why-is-this-useful/%28Location-based>services, Social networking, Gaming, News and

[whitemice]

>>Mobile Social Networking is an exciting space to be on currently, and am sure lot of folks working on it right now.<<

LBS and social networking on your mobile have both been “just around
the corner” or “the next big thing” for some time now. The problem is
that there are still some very real technical and business hurdles to
overcome before we get the kind of mass adoption we have seen with web
based applications.

Android addresses some of these problems, while Snowball solves some
of the others. ;-)

>>May be we can start a group, and start collaborating on the ideas, technologies etc., related to the mobile social networking space.<<

Sure, put a forum together using your favour app and invite me.

If you are shy about your product perhaps you can email me directly
with some details, just so I can get a handle on from which direction
you are coming from on this.

Regards
Mark

[Muthu Ramadoss]

Hi Zero,

Can you pass on the link for dataportablity? Thanks.

[Muthu Ramadoss]

We do mobile search engine as advertised in our site. The v1.0 release is scheduled for Jun 30. The core objective of finding stuff on your mobile is very similar to, for example

Snowball
Commandro
etc.,

If you look at our mobeegal.in website, mobeegal will help you find things in various categories like dating, shopping etc., which is exactly what you are looking for to build on top of your Snowball server.

I'll say we have a lot of similarities on the whole mobile search concept, which is not at all surprising given the mobile social networking space. One difference is mobeegal will use LBS while Snowball seems to avoid this. The other major difference of course would be on how our servers are built, and what they do exactly.

If your API becomes public, we might also consider using mobeegal to talk to Snowball for location sensitive information and perform the search.

On top of the domain specifc software that is getting build, I'm also seeing developers doing the same location, social networking related code again and again. May be, this is one area where people in the mobile social networking can work together and probably help each other out.

Collaboration is possible among products of similar interests. We just need to figure out how.

[whitemice]

>>Mobile Social Networking is an exciting space to be on currently, and am sure lot of folks working on it right now. <<

LBS and Social networking on your mobile have both been the “next big
thing” and “just around the corner” for a while now. However there
are still a number of technical and business hurdles which must be
overcome before we can start to expect the wide take-up which we have
seen for services delivered over the web.

Snowball will solve some of these problems, while I think Android
solves the rest.

>>May be we can start a group, and start collaborating on the ideas, technologies etc., related to the mobile social networking space. <<

Good idea, go put something together and invite me. ;-)
Although if you are shy about your product, perhaps you could email me
direct with some details so I can get an idea of what direction you
are coming from.

[nick]

If either of you are interested in input on these areas from a
perspective that it allied with, but somewhat outside of, the social
networking space, then count me in. While I'm less interested in the
social networking and commercial applications of this work, I'm
definitely interested in the sea-change that can happen if local,
short-range networking takes off. I'd be delighted to talk more about
some of the technical issues that are involved in making this work on
the ground.

nick

[zero]

ah, oopsy. i thought that to be well-known already ;)
http://dataportability.org/
http://groups.google.com/group/dataportability-public
myself is currently only a reader there.
but they do some interesting things that relate to social networking.
maybe we can build an open api that inter-operates between all
that services. as far as i can see now, there are three approaches to
location aware services:
p2p (like snowball)
server-centric ( i guess mobeegal, but i'm just guessing)
something in-between (like myself )
combining all those datasets could be interessting.

[Muthu Ramadoss]

Nick,

It would be great if you can participate. Zero had already suggested the dataportability group. Do we join dataportability or create a new group?

The group's objectives would be to discuss:

1. Mobile Communication
P2P, Short Range, Long Range networking capabilities with Android
Bluetooth, Wifi, Cell carrier connectivity for Android

2. LBS - Search & Discovery

3. Social Networking  - Messaging and Chatting

[Muthu Ramadoss]

Thanks, will check out.

[whitemice]

>>If you look at our mobeegal.in website, mobeegal will help you find things in various categories like dating, shopping etc., which is exactly what you are looking for to build on top of your Snowball server.<<

Your website seems pretty sparse on the specifics, I need to
understand the technology you are using so can I take a guess?

You are using GPS to locate the user, and then performing a search
using a back end server to return information relevant to nearby
locations. You have produced an Android front end, but would like to
brand it to specific Mobile Carriers or OEMs?

Am I close?

>>If your API becomes public, we might also consider using mobeegal to talk to Snowball for location sensitive information and perform the search.<<

Snowball will become public as soon as I find the time to put a
developer program together, although that’s not the same as saying
“soon”.

>>On top of the domain specifc software that is getting build, I'm also seeing developers doing the same location, social networking related code again and again. May be, this is one area where people in the mobile social networking can work together and probably help each other out. Collaboration is possible among products of similar interests. We just need to figure out how.<<

We are now clearly in the “consolidation” phase the Android, where
“battle tested” developers raise their weary heads from the contest
and start looking for comrades. Getting ready to tool up for stage 2,
where the competition will be much tougher.

Collaboration sounds good. Hence I am taking an interest in your
product and trying to figure out where it belongs in the LBS
landscape.

>>If either of you are interested in input on these areas from a perspective that it allied with, but somewhat outside of, the social networking space, then count me in. While I'm less interested in the social networking and commercial applications of this work, I'm definitely interested in the sea-change that can happen if local, short-range networking takes off. I'd be delighted to talk more about some of the technical issues that are involved in making this work on the ground.<<

You sound like someone I should be in contact with when implementing
the Snowball Wi-Fi and Bluetooth channels. :-)

Like Android itself, people will only use this technology if there are
truly useful applications built on top of them.

[Muthu Ramadoss]

Yes, currently we use GPS for broadcasting location to the server and carry out the searches. A mobile search engine is something that every mobile user needs and so can be bundled along with a mobile phone by the mobile carriers. Hence we are looking at them as a potential buyers of our application.

[whitemice]

>>Yes, currently we use GPS for broadcasting location to the server and carry out the searches. A mobile search engine is something that every mobile user needs and so can be bundled along with a mobile phone by the mobile carriers. Hence we are looking at them as a potential buyers of our application.<<

There is a clear gap in the market as mobile operators have been
unable to widely deploy their systems over the years, mainly due to
technology limitations and fragmentation. However I have some
reservations about relying on mobile GPS for positioning in non-
automotive/navigation applications because the satellite signals are
so weak.

Although I may change my mind once I get my hands on a true assisted
GPS device.

Also, Google is investing heavily in this area and is leaning towards
cell id with (in my opinion) good reason:
http://www.youtube.com/watch?v=HhgNZ5wMz2A&feature=user

[Muthu Ramadoss]

Thanks for the link. Nice video explaining MyLocation from Google maps. The requirement for mobeegal client just like any other LBS clients are to transmit location. Currently we use GPS. But mobeegal will be looking to work with different location providers ex: My Location, to obtain the location information in future.

I agree that you cannot completely be dependent on GPS. And hence we are looking at Snowball, FluidNexus etc., to obtain the location information if possible.

[nick]

Okay, do the two of you, as well as anyone else reading this, want to
start a group/list to talk about how to implement some of these things
technically? There is work on these ideas of local, ad-hoc, mesh-
based networking, especially with the project Haggle ( http://www.haggleproject.org
), the OLPC, and Comm.unity ( http://community.mit.edu/ ), among many
others, I'm sure. We could start by looking at how these other
projects have tried to implement things, and whether or not their
implementations are trying to be too general for our own varied
purposes. Let me know by posting here, or by e-mail, if you're
interested.

nick

[Muthu Ramadoss]

We can start a group for this. Count me in.

[j]

Nice idea. Maybe it's just me but the music of the video is a bit
creepy. :)

What if I am an oppressive government's agent using Fluid Nexus to get
access to activist messages? Is that possible?

Good luck.

[whitemice]

>>I agree that you cannot completely be dependent on GPS. And hence we are looking at Snowball, FluidNexus etc., to obtain the location information if possible.<<

I am glad you are taking an interest, I will count you in when I get
round to starting the Snowball developer program.

>>Okay, do the two of you, as well as anyone else reading this, want to start a group/list to talk about how to implement some of these things technically? There is work on these ideas of local, ad-hoc, mesh- based networking, especially with the project Haggle (http://www.haggleproject.org), the OLPC, and Comm.unity ( http://community.mit.edu/ ), among many others, I'm sure. We could start by looking at how these other projects have tried to implement things, and whether or not their implementations are trying to be too general for our own varied purposes. Let me know by posting here, or by e-mail, if you're interested. Nick<<

Definitely count me in!

Thanks for the links.
It seems everyone is using similar sounding technologies to achieve
different aims.
I have a very definite idea as to how this should be implemented to
enable LBS, but have to wait for the technology to catch up ;-)

>>Nice idea. Maybe it's just me but the music of the video is a bit creepy. :) What if I am an oppressive government's agent using Fluid Nexus to get access to activist messages? Is that possible?<<

To protect secret messages, you use either public or private key
cryptography (or something more exotic if you think your network can
support it).

My focus is instead on how to protect the location (and identity) of
the sender. This is as much applicable to dating applications as it
is to the evil government scenario.

Unlike “Fluid Nexus”, a Snowball network adds routeing information to
a message as it moves around. This gives the recipient an idea of how
far away the original sender was and addresses network capacity and
scalability issues.

To protect their privacy, a sender can alter (or randomise) their own
routing information to allow them to hide with a group of nodes (but
paying a penalty with message range). The question is: how much is
required to defend against different kinds of threats?

There is an unimplemented game called Snowball Fight, where players
(let’s call them agents) have to locate and challenge other players
(say activists) in their area. I intend arm the “Agents” with some
big brother style sniffing/tracking technology to simulate the tools
available to modern oppressive governments.

This would allow me to collect serious data (via game scoring) and
optimise algorithms to defeat various playing strategies that may
emerge from competitive play.

This idea has some similarities to WifiArmy, although the network
dynamics are very different.

[nick]

On Apr 22, 11:55 am, j <jac...@gmail.com> wrote:
> Nice idea. Maybe it's just me but the music of the video is a bit
> creepy. :)

Yes, it's from a very political track by the group A Silver Mt.
Zion :-)

> What if I am an oppressive government's agent using Fluid Nexus to get
> access to activist messages? Is that possible?

You raise a good and very common objection. The simple response is
this: all technologies can be re-appropriated by governments or other
groups for their own purposes. Witness groups using e-mail and
websites to spread hate messages and various nefarious calls to
action. So this is not something that can necessarily be built into
the technology in the first place to prevent this type of use. We can
always create pre-determined groups that have limited membership, with
the consequent decrease in efficacy of the network.

(Note that this is not an argument for the neutrality of technology,
but rather an acceptance that no matter what I, as the technology
developer does with the technology, it can always be re-appropriated
and re-purposed by others in ways I cannot predict. It's to
acknowledge my lack of agency and control once I release something
into the world.)

So a more direct response would be this: yes, indeed, governments
could use this technology in the same way. In a sense, though, all
activist use of technology is an implicit cat-and-mouse game. As
deficiencies are found within the current structure of the technology,
developers can change it to better deal with current threats. And in
a way what I'm doing here is related to two assumptions that could
both be true in different parts of the world: 1) it will take time for
a technology like this to catch on and for the government to find out
about it; and 2) the government already has this technology and by
developing it we are simply leveling the playing field.

What I am more worried about is the broadcast of cell phone
information even if the towers are "turned off". Because while a
government might turn off mobile towers for the purpose of making
calls, they could still use these towers for the purposes of
triangulating position. This is a much more difficult issue to
tackle. Tracking people and their location based on Bluetooth
broadcasting is also possible and is an inevitable consequence of the
technology. Whether this is a problem in practice remains to be seen,
and is something that can only be considered with a keen questioning
of the risks and benefits of use.

nick

[Muthu Ramadoss]

Avoiding the carriers entirely for exchanging data will be a big hit. The only issue is, can this be done?

[whitemice]

>>You raise a good and very common objection. The simple response is this: all technologies can be re-appropriated by governments or other groups for their own purposes.… <<
Actually I disagree with the question.

The current setup gives governments and intelligence agencies 100%
freedom to listen in and track users of cellular networks. As
cellular based tracking improves and becomes more wide spread, this
situation is only going to get worse.

The distributed approach at least gives the user some kind of choice,
and the Snowball implementation will let them benefit from propagation
over cellular networks even if they choose not to connect to them
directly.

>>Avoiding the carriers entirely for exchanging data will be a big hit. The only issue is, can this be done?<<

Today this simply can’t be done on a wide scale.

Not because of any limitations in the hardware, but because of the
tightly controlled and badly fragmented security regimes (code signing
certificates, etc) that currently exists on mobile handsets.

If Android is a open as promised, then I will be able to do all my
research and development here, and deploy on the more expensive-to-
develop-locked-down platforms in the future.

I also hope that Android gives the rest of the industry a good kick in
the teeth, and force them into opening up their platforms. ;-)

[Muthu Ramadoss]

The carriers should charge a monthly flat fee and open up the networks for voice and data. They can have various plans depending on the usage. Keeping a closed network and monopolizing it for SMS and charging users per SMS, MMS etc., tapping and tracking plus delivering junk ads is just opportunistic and would not last longer.

OPEN it up!