I think you are misinterpreting the arrows. Pixel dungeon is the original game with SPD being the preferred fork
The arrows aren’t PD > (greater than) SPD
But rather PD -> (turned into) SPD
I think you are misinterpreting the arrows. Pixel dungeon is the original game with SPD being the preferred fork
The arrows aren’t PD > (greater than) SPD
But rather PD -> (turned into) SPD
Yeah but your pattern is to re use labels (eg: beetus-friends@port87.com). If you suggest users reuse the labels they lose their effectiveness in working as aliases.
You are designing for a different feature set, I see this, however I think you may have some blind spots with what other email inbox providers offer and what users are looking for.
Good luck on the journey, your product already seems quite feature rich :)
I think you are misconstruing spam in this context.
While you are right about “spam” mail not meeting valid header details or authentication, a lot of “spammy” content does - marketing emails.
fastmails aliased emails allow for users to generate unique email addresses for each individual service they sign up for. What this enables is that when that service inevitably sells that email address to another spammy, potentially legitimate, but still spammy provider. They can then unsubscribe from that alias email entirely.
What you are describing seems less focused on protecting one address from being sold and shared. I think you need to accommodate for the fact that businesses sell lists of email addresses against their users wishes. That use case doesn’t seem to be met yet
The feline investigation bureau?