Today we're announcing the availability of this API across all Android devices running Google Play services 11.0 and up.
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.
Play services is more than just the online store; it's a Faustian bargain of useful services in exchange for giving Google root control over "your" computer.
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.
Well, tough. As an app developer, I don't bother with users who don't use Play. I prefer worrying about Play versions instead of Android versions. There are a lot of useful features which we would otherwise wait for new OS releases to be able to use.
The vast majority of which have no reason to be tied to Play, they're just (ab)using Play to auto-install and auto-update it everywhere. An effective way around carrier update delays, to be sure, but far from the only option.
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.
That's fair criticism, but "we" are likely to complain that "Google is installing many apps, and I don't know what they're doing". What also happens when I install "Core" v11.0.4, and then "Cast" doesn't install? Or the user stumbles upon "PubSub", and removes updates?
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.
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.
It used to be that these kinds of protocols would be reversed and reimplemented pretty quickly. See Pidgin (GAIM) and countless other instant messengers. I wonder what's happened - I see a lot less reverse engineering going on these days.
Having done a fair share of reverse engineering in my time, I think the reason is that it's boring. Sure, at first it's fun: it's all about constantly solving new puzzles. But eventually you realize you're in a maze of twisty passages, all different. The challenges are artificial and meaningless and will continue forever as long as pointless incompatibility is incentivized.
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. :)
Did people used to widely reverse engineer protocols that weren't related to communications and chat?
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]
Just because the Nearby Connections API layer is neither authenticated nor encrypted, doesn't mean the developer isn't free to implement it. If I tell you an Ethernet cable requires neither authentication nor encryption, you aren't going to tell me it's impossible to authenticate or encrypt over Ethernet.
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.