We REALLY need this!

[marcoscaceres]

As I argued over in the Mozilla positions repository, it seems that Apple has been able to provide this functionality without requiring an API: https://github.com/mozilla/standards-positions/issues/153#issuecomment-486481303

It simply uses existing HTML autocomplete, and implicit grants similar to file API to allow one to both pick and autofill a contact. Further, it doesn't have significant privacy issues, because it never leaks the contacts to the site. The user has to explicitly select a contact to autofill.

[beverloo]

I do like the auto fill approach, but I think it has some important limitations that make the two features complementary. Some initial thoughts, @rayankans will likely have more ideas -

• It doesn't scale very well when you need to select more than a single contact. This reflects use-cases we hear from quite a few developers, ranging from group messaging to social network bootstrapping.
• It doesn't scale very well when contacts have multiple e-mail addresses or phone numbers, for instance private and public ones. User controls would allow selecting which to share, rather than multiple.
• It might be insufficient for data types beyond text, unless we treat them as a file upload of sorts? (#13)

Another difference between the approaches is that auto fill relies on form input. While it's a great way for visualizing to the user what will be shared, the API does this through the picker UI without mandating the site's interface or behaviour—usage may not necessarily be form based. (I'm aware you can hide the form fields an all of that, which certainly is less elegant.)

[rayankans]

Thanks @beverloo, you pretty much covered all the points I wanted to make :)

The HTML autocomplete method definitely has its advantages, but only for a limited set of use-cases (if you want to upload a few contact fields). The proposed API offers more flexibility in terms of the website's UI, as well as an easier flow for more complicated use-cases (multiple contacts, icon uploads...).

@marcoscaceres, do you mind expanding a bit further on what you mean by the significant privacy issues? With HTML autocomplete the site still has access to the shared contacts. The Contact API gives one-off access only to the explicitly selected contacts, so nothing is leaked.

Do we REALLY need this? Well do we REALLY need any API? I think this API offers a simple, privacy-conscious solution to a very requested web feature. It's also powerful enough to cover all use-cases, without having to use workarounds. That's not to say that autocomplete doesn't have its place. I agree that they can be complementary as @beverloo said.

[aarongustafson]

Agree with @beverloo and @rayankans here. Also, for whatever it's worth, without knowing that @beverloo was working on this, I began designing a Contacts API predicated on privacy (I lived through the Path debacle all those years ago) and on protecting users from oversharing other people's information. Funny enough, it was pretty much identical in it's approach. It's a very transparent (to users) design, controllable without being overwhelming from a UI perspective, scalable, and follows an explicit request model that's demonstrated success, both as a technology and in terms of developer excitement (e.g., SOAP, GraphQL).

[marcoscaceres]

The Contact API gives one-off access only to the explicitly selected contacts, so nothing is leaked.

Ah, I'd missed that bit. Thanks for clarifying (as well as the additional use cases). Thanks also @aarongustafson.

I'm still on the fence on this, but keenly watching to see where it goes.

[marcoscaceres]

As an aside, there may be some overlap with: https://www.w3.org/TR/payment-request/#paymentaddress-interface

That is, it may be possible to somehow use PaymentAddress to provide the contact address information (despite the crappy Payment* name :)).

[rayankans]

Thanks @marcoscaceres, I suggested re-using PaymentAddress here, but yeah we should be able to rename it to something more general since it's not constructable :)

[marcoscaceres]

Agree... we can subclass it and add a constructor for it. Something like:

[Constructor(AddressInit)]
interface ContactAddress extends PaymentAddress {};

I'd like to eventually move "PaymentAddress" to its own spec... if we can enhance PaymentAddress to make it more universal, that would would be great.

[cedvdb]

@marcoscaceres

I need clarification. Will this contact API be used for, for example selecting a user in the contacts of an user and get his information ( tel / email ) ? Because your contact input seems to be for sending the current user information.

This would be really helpful for invitations in a PWA application

[marcoscaceres]

Deferring to @rayankans...

[rayankans]

@cedvdb it could be used for either, which is why returning a ContactInfo object works better as it can account for both cases (uploading to a server / using the info within the client).

[cedvdb]

What would generally be the timeline for something like to go from proposal to an actual implementation ? Can I vote somewhere ?

[marcoscaceres]

Votes don’t help (in this case) - but review of the actual API and helping us refine it sure do. As per implementation, that’s a harder one, specially across two browsers.

[marcoscaceres]

Closing, as there is nothing actionable here.