>>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.
On Mon, Apr 21, 2008 at 7:15 PM, zero <zeroo...@googlemail.com> wrote:
> maybe as a sub-group of dataportability ? > *just my two cents*
> On Apr 21, 2:30 pm, "Muthu Ramadoss" <muthu.ramad...@gmail.com> wrote: > > 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?
> > On Mon, Apr 21, 2008 at 5:10 PM, whitemice <markbr...@zedray.co.uk> > wrote:
> > > >>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< > http://blog.zedray.com/snowball/why-is-this-useful/%28Location-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.
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.
On Mon, Apr 21, 2008 at 6:41 PM, whitemice <markbr...@zedray.co.uk> wrote:
> >>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.
>>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.
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
On Apr 21, 9:11 am, whitemice <markbr...@zedray.co.uk> wrote:
> 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.
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.
On Apr 21, 6:00 pm, nick <nkn...@gmail.com> wrote:
> 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
> On Apr 21, 9:11 am, whitemice <markbr...@zedray.co.uk> wrote:
> > 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.
On Mon, Apr 21, 2008 at 9:30 PM, nick <nkn...@gmail.com> wrote:
> 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
> On Apr 21, 9:11 am, whitemice <markbr...@zedray.co.uk> wrote: > > 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.
On Mon, Apr 21, 2008 at 9:52 PM, zero <zeroo...@googlemail.com> wrote:
> 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.
> On Apr 21, 6:00 pm, nick <nkn...@gmail.com> wrote: > > 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
> > On Apr 21, 9:11 am, whitemice <markbr...@zedray.co.uk> wrote:
> > > 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.
>>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.
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.
On Mon, Apr 21, 2008 at 11:23 PM, whitemice <markbr...@zedray.co.uk> wrote:
> >>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.
>>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.
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.
On Tue, Apr 22, 2008 at 3:09 PM, whitemice <markbr...@zedray.co.uk> wrote:
> >>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.
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
On Apr 22, 5:51 am, "Muthu Ramadoss" <muthu.ramad...@gmail.com> wrote:
> 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.
> On Tue, Apr 22, 2008 at 3:09 PM, whitemice <markbr...@zedray.co.uk> wrote:
> > >>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.
On Tue, Apr 22, 2008 at 8:55 PM, nick <nkn...@gmail.com> wrote:
> 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
> On Apr 22, 5:51 am, "Muthu Ramadoss" <muthu.ramad...@gmail.com> wrote: > > 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.
> > On Tue, Apr 22, 2008 at 3:09 PM, whitemice <markbr...@zedray.co.uk> > wrote:
> > > >>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.
> maybe as a sub-group of dataportability ?
> *just my two cents*
> On Apr 21, 2:30 pm, "Muthu Ramadoss" <muthu.ramad...@gmail.com> wrote:
> > 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?
> > On Mon, Apr 21, 2008 at 5:10 PM, whitemice <markbr...@zedray.co.uk> wrote:
> > > >>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<http://blog.zedray.com/snowball/why-is-this-useful/%28Location-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.
>>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.
> 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.
> > > 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?
> > > On Mon, Apr 21, 2008 at 5:10 PM, whitemice <markbr...@zedray.co.uk> wrote:
> > > > >>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<http://blog.zedray.com/snowball/why-is-this-useful/%28Location-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.
On Wed, Apr 23, 2008 at 9:23 PM, nick <nkn...@gmail.com> wrote:
> 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
> > Good luck.
> > On Apr 21, 6:45 am, zero <zeroo...@googlemail.com> wrote:
> > > maybe as a sub-group of dataportability ? > > > *just my two cents*
> > > > 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?
> > > > On Mon, Apr 21, 2008 at 5:10 PM, whitemice <markbr...@zedray.co.uk> > wrote:
> > > > > >>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< > http://blog.zedray.com/snowball/why-is-this-useful/%28Location-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
> > > > -- > > > > take care, > > > > Muthu Ramadoss.
>>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. ;-)
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.
On Fri, Apr 25, 2008 at 2:14 PM, whitemice <markbr...@zedray.co.uk> wrote:
> >>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. ;-)
