Of course, Google had to lock up peer to peer communication by tying it to their online store. It's also unencrypted and unauthenticated, so you don't want to use this for home control.

I refuse to Play. I don't really miss the app store, but I'm sore I can't cast media at my friend's house (Chromecast requires Google Play, of course). This is another brick in that wall.

This is more unethical and monopolistic than anything Micro$oft ever did, back when they earned that moniker.

It could've been an app. Or more than one. And then there could've been competition. Instead it's baked into a monster install that does who-knows-what when it invisibly updates itself.

I'm inclined to think this is an all or nothing here, but since we don't have access to the source, I won't know how Google has implemented Play Services.

Can you kindly give an example of which APIs shouldn't be tied to Play though? I've never thought about it.

https://microg.org/

They are an open source re implementation of play store APIs that work with play store apps, without all the bloated tracking and spy... sorry "telemetry", and without giving Google remote root on your phone, with the ability to selectively install and do whatever the hell they want to your device silently (sounds like a targeted intelligence operation dream to me).

Removing gapps stuff and using microg instead saved a large amount of ram, and more than doubled my battery life.

Its a great way to make old devices suck less.

No implementation of this API yet, but it seems rather trivial to do, and will likely see implementation.

On the one hand, the people who can reverse engineer stuff got too good: either they got tired of it, or they're getting paid big bucks to do it professionally. On the other, (perhaps this is jaded) new programmers are just learning scripting/web technologies and never peel back the covers of how the system actually works.

Perhaps reverse engineering proprietary products should be a mandatory tour of duty for young programmers, like military service in some countries. :)

Google play store APIs and protocols ARE being reverse engineered and re implemented.

I run microG with store apps with no issues with everything I have tried.

Doing it to a chat-app has an obvious benefit: you can use your own application with your custom UX, and connect it with multiple networks at once, or multiple accounts at the same time on the same network.

Doing it with something like Airdrop is kind of a nebulous proposal. If you want to share files with someone next to you, and for some reason you hate Airdrop, then there's lots of other alternatives. Reverse engineering Airdrop gets you nothing special.

"Note: The Nearby Connections API does not require the user to authenticate, which means that it can be used even when the user does not want to sign in or sign-in has failed."

"Warning: Messages sent through the Nearby Connections API are not encrypted. Do not send sensitive data through this API."[1]

[1] https://developers.google.com/games/services/cpp/nearby

The blog post links to this documentation page:

https://developers.google.com/nearby/connections/overview

Game API (C++):

    void SendReliableMessage(
      std::vector< std::string > const & remote_endpoint_ids,
      std::vector< uint8_t > const & payload
    )

    public abstract void sendReliableMessage
      (GoogleApiClient apiClient, 
       List<String> remoteEndpointIds, 
       byte[] payload)

So this is what we get.

100% agreed though. IMO is poison and a major regression from where things stood- barely working wifi p2p- since it doesn't make any interoperability affordances/offerings.

Nearby isn't using WiFi Aware. We want it to work on all existing Android devices.

Internally, it's using a mix of WiFi, WiFi Direct, Bluetooth LE & Classic Bluetooth.

Getting proximity-based P2P messaging to work correctly across all devices is complicated. With Nearby Connections, we're trying to provide an abstraction layer that makes it easy.

So now we have Nearby Communications for Android and AirDrop for iOS and we still can't send stuff to friends in the same room, without sending the data through a remote third party service. The only standard supported mechanism for sharing without an app is via email!

[0] https://openconnectivity.org

The shelves in the grocery store calling out to me because they know I like potato chips! Can't wait!

I really can't help but cringe. Please let that never be my future, where I broadcast out personal information to the entire room everywhere I go.

Seriously though, totally agree with a few commenters (pat2man, mataug), open standards will win the day; any day...including future days.

The classroom examples also ring true to real world experiences. My wife is a teacher and has used several different proprietary "voting" devices in the past to great effect. However, they all used different hardware/protocols and didn't integrate with their current environment at all. This year they are moving to Chromebooks and my hope is that Nearby Connections might provide an "open" foundation on which a new breed of apps can be built.

As @pat2man mentions, It would've been great if Apple and Google made this an open standard instead of having their own proprietary solutions.

The new Apple era has strayed considerably from "it just works," except for AirDrop, which has been nothing but a pleasure to work with.

And I assume you are all using Mac?

Because In Cooperate World it is pretty much Windows Only.

The last two companies I worked for — a creative agency with ~50 people, and a larger more anonymous company with ~2,000 employees in 10 states — both were 100% Mac. The first one, because that's how creative agencies have always been. The second for security. The IT dept's policy was no Microsoft hardware or software allowed other than Office: Mac.

As for the workflow, it's like this:

- See file on desktop. - Right-click and select "Airdrop" - Choose destination computer - Notification appears on target computer stating that someone wants to send a file - Destination user clicks "Accept" - File transmits super-duper fast in the background and lands in the destination computer's download folder

Or if you're sending a file to yourself (both devices have the same iCloud/.mac/.me ID) skip everything after the third step.

1: https://news.ycombinator.com/item?id=14859602