Well you will need to tag your content for preferences. On account creation
you do a questionnaire. So that is now in a database. The you tie your app
into the location services. That would ping back and everything in "range"
would be tagged and made available in the apps offer screen. With a single
notification of offers in your area. I would not suggest using another
service as your transport as that can get your Data banned.
On Jul 30, 2014 12:29 AM, "David Schwartz" <newsletters@thetoolwiz.com>
wrote:

> I realize this is totally OT, but I thought folks might have fun
> discussing it, and I'm guessing you'll have some great insights to share.
>
> Basically, I have an idea for something that is a real-time notification
> system that takes advantage of geo-tagged messages that are intended for
> people "near-by", meaning within a 10-mile radius or so.
>
> People will send out short geo-tagged messages using our mobile app, and
> if the app is running on your mobile device, then it will pick up the
> messages and determine whether to alert you or not based on your location
> and some other criteria.
>
> For something tangible, think of a system where a business would announce,
> say, free pizza at their Rural and University location for the next 20
> minutes. (Again, over-simplified, but that's the essence of the messaging,
> and how low-bandwidth it would be.)
>
> It NEEDS to be a dedicated app, not a plugin for something like FB or some
> other social media platform.
>
> How would you approach the messaging for this?  Note that if the idea
> takes off, we're talking about O(6) to O(8) numbers of apps running,
> anywhere in the world.
>
> One thing that comes to mind for me is to use Twitter as a transport
> mechanism and implement a simple messaging protocol on it that uses
> hashtags. It could be overkill, and possibly also not consistent with
> Twitter's TOS. Just a thought.
>
> How else might you construct some way to broadcast short messages that are
> received by a large number of users in fairly short order? (ie., less than
> a minute).
>
> Also, as I mentioned, there is a "locality" effect that's implicit in this
> application, as well as "timeliness".  So the further someone is from where
> a message originates, the less relevant it is. At some point, say, over 10
> miles, they're likely to be 100% irrelevant and be filtered out.
>
> (Using the above "free pizza" announcement, if you're at the Scottsdale
> Air Park, you really don't care. But a wine-tasting at a bar near the Air
> Park would definitely get delivered to you.)
>
> So we could broadcast each announcement message to everybody (all current
> listeners) in real-time (like what Twitter would do) and let the
> client-side filter out the irrelevant messages (around 99.99%).
>
> Or we could reduce that bandwidth by having clients update the server
> periodically (eg., every 5 minutes) with their location, then for each
> announcement, a server would locate clients within a reasonable radius
> based on their last reported position and only notify them directly through
> a push notification of some sort; the clients would still do some
> filtering, but this would reduce incoming traffic considerably.
>
> I'm not sure which is worse: a server updating a huge number of clients in
> near real-time, or a huge number of clients updating the server with their
> geographical location every 5 minutes or so.
>
> Or, an alternative is for the clients to poll the server every 15-30
> seconds, but this seems even worse in terms of traffic. (Althought this
> approach is probably ok if we used an existing platform like Twitter.)
>
> Any thoughts?
>
> -David
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>