Automattic / Automattic/gravatar

[Enhancement] Provide a way to verify a namespace of e-mail addresses.

Open
#309 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
TypeScript
Stars
361
Forks
125
PR merge metrics
No merged PRs in 30d

Description

# Feature Request

## Description / Use Case

As was originally explained at [`webapps.stackexchange.com/q/39813`](https://webapps.stackexchange.com/q/39813/237205), users of e-mail alias services, of which AnonAddy and Firefox Relay and pertinent examples, are nigh unable to utilise Gravatar, because they must add a new address for every service that they register for:

Image

Being able to have any e-mail address of the `beedellRoke.addy.IO` domain (and some additional [sub-]domains) be verified as owned by me would allow me to utilise Gravatar again.

## Proposed Solution

I propose that RegEx be permitted. It would require that services, like Firefox Relay and AnonAddy, provide a verification process that is compatible with Gravatar, likely bound to the user's sub-domain:

Image

However, Mastodon and MetaMask already demonstrate that this should be feasible. [^1]

[^1]: [`joinmastodon.org/verification`](https://joinmastodon.org/verification)

## Alternatives

An alternative would be to allow a user to solely verify their ownership of a domain, then allow any e-mail address of that domain to verify a specific user.

This is less versatile, not least because it would not be useful to any organisation that does not provide a subdomain per user (which is most). However, it would be more verifiable.

## Additional Information

This relates to what I have previously requested, at [`nextcloud/contacts/issues/353`](https://github.com/nextcloud/contacts/issues/3530#issue-1816825315).

Contributor guide

Open the contributing guide

Research direction

No source files, tests, or entry points are named in the issue. Start by asking maintainers which verification flow and service boundary should own namespace or domain verification; done would require an agreed design, implementation, and tests for the supported ownership model.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
authentication, backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.