I read and re-checked the Explainer, and frankly given the repeated past Contacts API failures and zero mention of them in the Explainer, I’m going to deem this proposal not worth taking the time to thoroughly evaluate until the Explainer at a minimum: 1. Documents previous Contacts API standards attempts (see https://tantek.com/2020/026/t2/ for some links to start) 2. Provides summary explanations for their failures 3. Describes how the current proposal is different from previous proposals in such a way as to at least avoid those failures (i.e. there should be a logical chain of reasoning from identifying key differences and how those either cause or prevent different outcomes from prior attempts). I think we should go ahead and publish a position of "defer", since a similar request to number 3 was made a whole year ago (https://github.com/w3ctag/design-reviews/issues/337#issuecomment-460555385) without any subsequent respective additions to the Explainer. Also given the critical comments in that discussion, especially from https://github.com/torgo, and knowing how much more abusive social network/media "apps" have become with aggressive sign-up, spam, user-acquisition tactics in recent years, I’m leaning towards expecting an eventual "harmful" evaluation. If the purely markup-only approaches were separated out into another proposal, I’d be more optimistic of more quickly evaluating those, and expecting browsers could implement those simpler (fewer ways to use/abuse) feature(s) in such a way that could be "worth prototyping".

I read and re-checked the Explainer, and frankly given the repeated past
Contacts API failures and zero mention of them in the Explainer, I’m going to deem this proposal not worth taking the time to thoroughly evaluate until the Explainer at a minimum:

1. Documents previous Contacts API standards attempts (see https://tantek.com/2020/026/t2/ for some links to start)
2. Provides summary explanations for their failures
3. Describes how the current proposal is different from previous proposals in such a way as to at least avoid those failures (i.e. there should be a logical chain of reasoning from identifying key differences and how those either cause or prevent different outcomes from prior attempts).

I think we should go ahead and publish a position of "defer", since a similar request to number 3 was made a whole year ago (https://github.com/w3ctag/design-reviews/issues/337#issuecomment-460555385) without any subsequent respective additions to the Explainer.

Also given the critical comments in that discussion, especially from https://github.com/torgo, and knowing how much more abusive social network/media "apps" have become with aggressive sign-up, spam, user-acquisition tactics in recent years, I’m leaning towards expecting an eventual "harmful" evaluation.

If the purely markup-only approaches were separated out into another proposal, I’d be more optimistic of more quickly evaluating those, and expecting browsers could implement those simpler (fewer ways to use/abuse) feature(s) in such a way that could be "worth prototyping".