Local peer discovery

Dwolla and Square have a lovely service whereby it is possible to press a button marked "Pay someone nearby", and immediately get a list of people within 100 feet, ordered by estimated distance from you. Then simply tap one of them, enter an amount, and you're done.

I would like this feature to be in Hive as well.

CC @mattatgit

from Slack, possibly unrelated but perhaps indicative of a coming trend:

"Have you guys seen "Multipeer Connectivity APIs, introduced in iOS 7" ? Multipeer Connectivity is a framework that enables nearby devices to communicate over infrastructure Wi-Fi networks, peer-to-peer Wi-Fi, and Bluetooth personal area networks. Connected peers are able securely transmit messages, streams, or file resources to other devices without going through an intermediary web service.

It creates your own local network, without an internet connection on the wifi part. Think about a chat app in a club, or paying locally in a shop. Most of the time you are relying on a 3G+ connection, so the wifi in your phone is "free" and able to create a p2p connection."

[javgh]

I think it would be a cool feature. However, I wouldn't want my phone to constantly broadcast some kind of identifier wherever I go. It seems that the Dwolla and Square solutions (and also PayPal Beacon) work something like that and I find it hard to believe that this will find user acceptance in the long run.

Although, if both users have to go into "local peer discovery" mode, it isn't that convenient for repeated payments anymore, as you always need to ask the other person to get out their phone. Maybe the local peer discovery could only be used for initial contact information exchange and then later on you can always select the person from your address book instead.

[javgh]

Relevant Reddit discussion: https://www.reddit.com/r/Bitcoin/comments/23l56v/qr_codes_are_dead/

[mackuba]

I wouldn't want my phone to constantly broadcast some kind of identifier wherever I go

Definitely not, that sounds like a very bad idea. I imagine this like the Airdrop panel in OSX - as some page that you have to explicitly enter in order to broadcast your presence and see other people at the same time.

[mackuba]

Have you guys seen "Multipeer Connectivity APIs, introduced in iOS 7"

This would be cool, but as was mentioned on Slack, there's no way this will be made available to web apps anytime soon (not to mention it would not be multi-platform anyway).

[mackuba]

Also, for privacy reasons, I think it would be good to implement this in such a way that you can't request a list of people in a "sector" without also "checking in" in that sector yourself, + some kind of rate limit that makes sure you don't move around the world at the speed of light. I mean, we want anyone to be able to list other Hive/Bitcoin users within the same area, but we don't want them to be able to scan the whole world map and track where everyone is. This probably implies some kind of centralized database again if we want to have any kind of access control.

[haustraliaer]

Addressing @w-hive's questions on location services for web, we think that it is fairly conclusive that:

a) You can access the GPS location services from the web (eg: when google maps asks for your location), but all that gives you is your Longitude and Latitude coordinates.

b) i-Beacon style connections are not available to web most (if any) browsers. So I think we can rule this feature out for the short term.

Obviously if these services were opened up a later point in time we would want to implement them asap.

@javgh

"It seems that the Dwolla and Square solutions (and also PayPal Beacon) work something like that and I find it hard to believe that this will find user acceptance in the long run."

Sorry, but as usual Jan, I think you vastly over-estimate the concern normal people have about such things. :-) Not that I don't agree with the fact that it should be able to be disabled or selectively enabled, but the default setting should probably just be "Hey, it works", because most people never touch settings anyway.

@jsuder

That's a good point. I had a conversation with @petertodd about that earlier this year; I was asking him about a way to use hashed coordinate pairs to do location-based apps 100% peer-to-peer. The idea was, hash a GPS pair and that hash becomes the pointer for a BTSync-style DHT pointer. That said though, checking in -- or any additional steps to this just working -- pretty much ruins the magic. Maybe @mikehearn has some ideas?

@haustraliaer

a) Why is "only" getting a coordinate pair a problem? :-)
b) What is an i-Beacon-style connection? The peer-to-peer thing we discussed? I don't think it's necessary. It's certainly possible to do it well enough using current systems. At least for now.

[weilu]

We can a "pay someone nearby / get paid by someone nearby" feature. When user(Alice the customer) clicks on it, we open a map view where we use geolocation API to get user's current location, and upload the coordinates to server.

Meanwhile, the server also exposes an API to query known hive users for a given area -- we should limit it to a reasonable range(1km radius?), taking into account of GPS inaccuracy. Also the API access should be limited to users who just uploaded their coordinates in the area they query.

So the user's device can query the server for other hive users who are also on the map view page on their device. Say Bob the merchant also opens the map view. Alice finds him. Alice can then see Bob's public address and click it to make a payment. Or, if Bob finds Alice first, he can get paid through the "request for payment" feature.

When user leaves the map view page we erase user location data from the server.

Notes on HTML geolocation API

• A device's current location is obtained from either GPS or WiFi, depends on availability at the time of request. The implementation details are hidden by geolocation API so we don't have to worry about it.
• Looks like browser support is pretty good: http://caniuse.com/#search=geolocation. But take note of one of the known issues: "iOS6 has problems with returning high accuracy data."

Ah @weilu ... Always reaching for centralized services by default. :-)

Anyway while that may indeed be the best solution for now, IMHO actually showing a map is passé. That isn't really the point of this feature. It's about paying someone standing within 100 feet of you.

Re: iOS6: http://www.macobserver.com/tmo/article/ios-7-adoption-hits-80-percent

[mackuba]

Also the API access should be limited to users who just uploaded their coordinates in the area they query.

Yeah, that's what I mean by "you can't request a list of people in a "sector" without also "checking in" in that sector yourself" (by checking in I mean your app making a request stating that the device is in such and such location, not something like a user checking in on Foursquare).

IMHO actually showing a map is passé

I agree that the map is unnecessary, especially since in such a small area as we're interested in, the accuracy would be very low.

[mikehearn]

People do worry about things where they're uploading coordinates to a server all the time (even though their phone already does this). I lost track of how often I saw Latitude/Google Now be described as creepy when I was at the big G. Some users love it of course, but by no means all. If it's opt-in of course, then it's fine, but then it's also a feature you couldn't rely on. Things like Tinder make it work because you don't really care who you find, but when you want to pay someone in physical proximity, that's different.

Bluetooth LE is probably the right technology for this kind of thing, but it's not widely supported at the moment. Ad-hoc wifi and so on require constantly broadcasting "i'm here! i'm here!" which can be a battery suck.

I think the right first focus would be to make this work in the merchant setting, where they can easily have some small dedicated beacon device that is plugged in or that they recharge themselves. The beacon can be observed from the phone when it's unlocked and the wallet app can then fetch a payment request in the background and open to the "Pay Foo Coffee, Inc" screen instead of the default wallet view. So it's just one or two taps to get to the confirm payment screen.

[mackuba]

I think the right first focus would be to make this work in the merchant setting, where they can easily have some small dedicated beacon device that is plugged in or that they recharge themselves. The beacon can be observed from the phone when it's unlocked and the wallet app can then fetch a payment request in the background and open to the "Pay Foo Coffee, Inc" screen instead of the default wallet view. So it's just one or two taps to get to the confirm payment screen.

This is a completely different use case, we're talking about a way to easily connect with a person (other user) in the same room or area, without having to play with QR codes. A merchant will usually have some kind of device that will show a QR code automatically by default, so it's less of a problem.

So @jsuder what do you think, do we close these "issues" once we've built it? :-)