My application is for a phone that's running a WebNFC-enabled browser to tap another phone to pass it a URL to which to browse.

When I joined the development group for WebNFC more than three years ago, I expected peer-to-peer to be its main focus, since it's used so much for payments, and passive tags a secondary implementation. I've been astonished that it's been the other way around, and that implementation of peer-to-peer has been delayed, and now possibly dropped. I've had to patch in QR Code support in my app to tide me over.

The alternative of the Web Share API triggering Android Beam is inadequate:

1. It only shares the URL of the invoking page. The URL set in the share call is ignored, so arbitrary URLs can't be shared,
2. It requires the user make the extra step of choosing NFC delivery,
3. The share must be triggered by a user action, and
4. The share must be from an SSL page, which is annoying for development.

Is there an alternative?

Is it really that difficult to implement peer-to-peer WebNFC on Chrome on Android, or are there security concerns, or just a belief that there's no demand? I know an implementation has been substantially written, and that the Chrome team planned to fully implement this "after we ship Generic Sensor APIs", which I believe happened in March or April. Has this now been abandoned?

Here is the original WebNFC Issue discussing peer-to-peer support: #139

And here is the Chromium bug for WebNFC issues, where I've asked about peer-to-peer: https://bugs.chromium.org/p/chromium/issues/detail?id=520391

Payments solutions are not using peer to peer, but "card emulation" which is different. It allows a device to emulate being a tag and additionally gains access to the "secure element" on the device.

The problem with peer-to-peer is how to implement it. On Android this is basically handled by the platform and we would need platform native UI and UX for this, which is really what has been blocking this.

The idea of "dropping" peer, is in order to actually ship something (Minimal viable product - MVP), now there is renewed interest from Google in doing so (Project Fugu).

It should be possible to add back peer support after that

Maybe we need the input from @slightlyoff @ThomasTheDane

Ken, whatever the implementation detail, tap payments are still a device talking to a device. I would actually prefer WebNFC peer-to-peer to be implemented as tag emulation so it would trigger URL browsing just as smoothly.

Could you explain further what makes Android implementation hard. Does it require new functionality in Android so that an app can activate the NFC chip? Can Chromium implement WebNFC peer-to-peer by doing what payment apps do and emulate a tag, just without the secure element?

I'm keen to get some form of peer-to-peer working soon, otherwise it'll likely be a wait of several more years if it's dropped from the shipped MVP.

I've now implemented a way to share my URLs by NFC without use of WebNFC, so I'm no longer as insistent about early peer-to-peer support.

Because the URLs being shared are within my website, and because a peer-to-peer tap when Chrome is being used will activate Android Beam to send the URL of the current page, I can set a cookie on the sending browser and then open the URL to be shared in a new window. The cookie allows my website to distinguish sender from receiver and either show tap instructions or process the share.

I still don't understand why it's hard for WebNFC to use Android Beam in the same way, just with an arbitrary URL rather than the URL of the current page.

Are there any peer use cases in the use cases doc? It seemed to me like those were reader/writer, but I don't know this area well.

We have one here but not a very relevant one. In general, I would like to support the peer to peer use cases (like @mrj mentioned) if possible & feasible & the underlying platform exposes the interaction.

Let's drop this for now